hdls Support
hdls Support is a full helpdesk your assistant runs end to end — tickets, the back-and-forth conversation on each one, a searchable knowledge base, and the requesters (your customers) who raise them. No agent console to log into: your assistant creates tickets, drafts replies, and closes them out.
The headline entity is the ticket. Requesters are first-class external parties, so a ticket always knows who it's for. suggest_reply and search_kb lean on the knowledge base to answer faster, and semantic_search_tickets finds similar past issues by meaning, not just keywords.
Common workflows
- Handle an incoming issue:
create_ticket→search_kb/suggest_reply→add_message→set_status. - Deflect with knowledge:
search_kbbefore replying; reuse the best article. - Find precedent:
semantic_search_ticketsto surface how similar tickets were resolved.
hdls Support is a headless, MCP-native helpdesk & ticketing backend. It manages tickets, conversations, and a knowledge base, operated entirely through named tools your AI assistant calls. It stands in for tools like Zendesk, Intercom — same job, no UI to run.
💬 Just ask
"Open a ticket for Jane about a failed login, then show me all open tickets."
You don't call these tools yourself — just tell your assistant in plain English. Everything below is the reference for when you (or your assistant) want the exact details.
How Support is organized
The headline entity is the ticket — start there, then attach the rest to it. Records connect by reference: a requester links to an org. The message table is an append-only timeline — every change and note lands there and is never edited or deleted.
| Entity | Purpose | Relates to |
|---|---|---|
ticket | A support request tracked from open through resolution. | requester, org, sla_policy |
org | Customer organization (account) that requesters belong to. | — |
requester | End user (customer contact) who submits and follows support tickets. | org |
sla_policy | Service-level targets (first response / resolution) applied to tickets by priority. | — |
kb_article | Knowledge-base article surfaced to agents/requesters; semantically searchable for suggested replies. | — |
macro | Reusable canned reply plus optional field actions applied to a ticket in one step. | — |
message | Append-only conversation timeline for a ticket (public replies and internal notes). | ticket |
Tools
Call these at https://hdls.ai/api/mcp/support. Required fields you must supply; optional fields refine the call. You never pass tenant_id — it is stamped server-side.
Create
| Tool | What it does | Required | Optional |
|---|---|---|---|
create_ticket | Create a new ticket. | subject | requester_id, org_id, sla_policy_id, body, status, priority |
Update & advance
| Tool | What it does | Required | Optional |
|---|---|---|---|
set_status | Set the status. | id | status |
suggest_reply | Draft a suggested reply. | id | — |
Find & read
| Tool | What it does | Required | Optional |
|---|---|---|---|
search_kb | Search KB by free-text and/or column filters (tenant-scoped, paginated). | — | search, filters, limit, orderBy |
semantic_search_tickets | Find search tickets by meaning, not just keywords. | — | search, filters, limit, orderBy |
Timeline
| Tool | What it does | Required | Optional |
|---|---|---|---|
add_message | Add a message. | ticket_id, body | author_type, author, is_public |
Field lists come from the product's live schema and are embedded in each tool's own description — read the tool description for the exact, current fields.
Field reference
Every field you can set on each record. Custom fields you add live alongside these in data.
ticket
| Field | Type | Required | Notes |
|---|---|---|---|
requester_id | id | Links to a requester. | |
org_id | id | Links to an org. | |
sla_policy_id | id | Links to a sla_policy. | |
subject | text | Yes | |
body | text | ||
status | text | Lifecycle state. | |
priority | text | ||
channel | text | ||
assignee | text | ||
tags | list | Free-form labels. | |
due_at | timestamp | ||
solved_at | timestamp | ||
data | json | Free-form JSON — custom fields live here. |
org
| Field | Type | Required | Notes |
|---|---|---|---|
name | text | Yes | Display name. |
domain | text | ||
notes | text | ||
data | json | Free-form JSON — custom fields live here. |
requester
| Field | Type | Required | Notes |
|---|---|---|---|
org_id | id | Links to an org. | |
name | text | Yes | Display name. |
email | text | ||
phone | text | ||
data | json | Free-form JSON — custom fields live here. |
sla_policy
| Field | Type | Required | Notes |
|---|---|---|---|
name | text | Yes | Display name. |
priority | text | ||
first_response_mins | number | ||
resolution_mins | number | ||
is_active | true / false | ||
data | json | Free-form JSON — custom fields live here. |
kb_article
| Field | Type | Required | Notes |
|---|---|---|---|
title | text | Yes | Display name. |
body | text | ||
status | text | Lifecycle state. | |
tags | list | Free-form labels. | |
author | text | ||
data | json | Free-form JSON — custom fields live here. |
macro
| Field | Type | Required | Notes |
|---|---|---|---|
name | text | Yes | Display name. |
body | text | ||
actions | json | ||
is_active | true / false | ||
data | json | Free-form JSON — custom fields live here. |
Tailor it with custom fields
Add fields without a schema change. add_custom_field defines one, list_custom_fields shows what's defined, and promote_custom_field (admin) shares a personal field with the whole workspace. The value lives in each row's data (JSON) and is set and read through the normal record tools. See Products, tools & custom fields for the full model.
Roles & safety
- Tenant isolation is automatic. Your credential is pinned to one workspace; you never pass
tenant_id, and you can only ever see your own data (enforced by Postgres row-level security). - Role-gated. Permissions run
reader < member < admin < owner. Installing a product and promoting a custom field workspace-wide need admin/owner. - History is append-only. The
messagetimeline is never edited or deleted — it's your audit trail.
Connect
On the concierge (https://hdls.ai/api/mcp), run install_product({ slug: "support" }) (admin/owner) to enable it for your workspace, then add https://hdls.ai/api/mcp/support as a connector in your assistant — see Connect your assistant.
A worked example
The literal call your assistant makes when you ask it to create the headline record:
Tool: create_ticket
Arguments: {
"subject": "example"
}