Limits

The named tools are the whole MCP surface.

The complete list, with each tool's role floor, is in the helpdesk under Settings → MCP, generated from the running server.

Source: _TOOLS in services/runtime/src/runtime/mcp/tools.py.

The REST API is not available through MCP

This is the point most worth being clear about. The tools are not a window onto the REST API. They are named operations, each with its own fixed input schema, and there is no tool that takes a path or a method and calls something else.

So none of the following can be done over MCP, regardless of your role:

• Changing a member's role, or removing one. invite_teammate can invite someone at the admin floor, and inviting is the whole of it.
• Minting or revoking API keys.
• Reading the audit log.
• Billing and budget settings.
• Channel, email or widget configuration.
• Workspace settings and provider keys.
• Creating, editing or publishing knowledge base articles. search_knowledge_base reads, and only reads. The help centre is a different store and several of the tools do write to it — create and update articles, create collections, draft Markdown, export — at the editor and admin floors.
• Deleting a ticket, or changing many tickets in one call. Status, priority, assignee and tags can be changed one ticket at a time, by update_ticket and by apply_macro, and reply_to_ticket can move status as part of posting a message — all three at the editor floor. Source: _update_ticket, _apply_macro and _reply_to_ticket in services/runtime/src/runtime/mcp/tools.py.
• Exporting tickets or customers.
• Automation settings: a macro created over MCP is always manual, and triggers cannot be set.

Merging takes two calls, and that is not a human approval. merge_tickets called on its own changes nothing: it shows both tickets and any warnings, and returns a confirmation that lasts ten minutes and only works for the same person, workspace and pair of tickets. The merge happens when the call is repeated with that confirmation. The confirmation goes back to the assistant app, not to you, so the app can make both calls one after the other. It guards against an accidental or mistyped merge. It does not prove a person looked. The human check is your assistant app's own prompt before it runs an action: keep that prompt on for merge_tickets, and read the preview before you allow it. A merge cannot be undone. Source: _merge_tickets in services/runtime/src/runtime/mcp/tools.py.

Text your customers wrote is marked as untrusted. Ticket subjects, survey comments and answers, ticket summaries, customer metadata, attachment file names and attachment text all come back wrapped as {"untrusted_text": ...}, or {"untrusted_data": ...} for an object. Each tool that returns such content says so in its description. Anyone who can email you or use your chat widget can write that text, so it can contain instructions aimed at your assistant. The wrapper tells the assistant app it is data, not instructions. It does not stop a model from following it, so review any action the assistant proposes after reading customer content. Names, ids, statuses and the helpdesk's own fields are not wrapped. The older tools, get_ticket among them, return customer text unwrapped. Source: UntrustedEnvelope in services/runtime/src/runtime/mcp/tools.py.

Every one of those is an ordinary API operation. If you need one, use the API.

Long answers are trimmed

An assistant app pays for every byte a tool returns, and some answers (a long customer history, a big company, a full Insights page) would be very large. So most of the newer tools have a size cap, and an answer over it is cut down rather than sent whole. A cut answer always says it was cut.

The caps. Measured on the wire: both copies of the answer the protocol sends, plus its envelope. Here 1 KB is 1,000 bytes.

Every other tool has no answer-size cap and returns its answer whole. get_attachment has its own per-file limits instead; see Attachments and sharing.

How an answer is cut, in this order, until it fits:

1. A single piece of customer-written text too big to fit even on its own is replaced by {"omitted": true, "size_bytes": n}.
2. The largest list is shortened, then the next, until the answer fits or no list is left. Beside each, <list>_omitted says how many rows were dropped. A list that is the answer itself, such as the Insights figures, is shortened only after every other list. On a tool that pages (list_companies), the page is cut short instead and next_offset says where to carry on.
3. Custom field values are dropped whole, largest first, and their keys are listed in values_omitted.
4. The largest remaining piece of customer-written text is replaced by the omitted marker, one at a time.

Any cut sets truncated: true at the top of the answer.

When even that is not enough, the answer falls back to what identifies the records: ids, references, statuses, a merge confirmation_token and its expires_at, with the counts and flags beside them. It carries detail_omitted: true, and on a write read_with names the tool that shows the full result.

A saved change never reports a size failure. A write has already been saved by the time its answer is measured. If even its identifying fields do not fit, it answers with detail_omitted and read_with alone. Only a read can be refused for size, and only when nothing is left to shorten. The refusal says the result is available in the helpdesk.

Some lists also stop at a fixed number of rows, whatever their size: list_members at 500, and list_todos, list_time_logs and list_saved_views at 200. The first three return a total beside the rows, so a total larger than the rows tells you the list was cut. list_saved_views does not.

Source: _within_wire_cap, _WireFit, _identity_fields, the _*_WIRE_CAP_BYTES constants and each tool's wire_cap in _TOOLS, and _MEMBERS_MAX, _TODOS_MAX, _TIME_LOGS_MAX and _SAVED_VIEWS_MAX, all in services/runtime/src/runtime/mcp/tools.py.

Other limits worth knowing

A tool call cannot exceed what you can do yourself. Each tool applies the same role floor as the equivalent HTTP route, using the same guard, and the database sees the same identity and workspace it would see for a request you made in the product. A viewer driving create_ticket through a client is refused exactly as a viewer would be.

Source: services/runtime/src/runtime/mcp/tools.py:1-10 and services/runtime/src/runtime/api/authz.py:131-132.

One workspace per call. There is no tool that reads across workspaces, and no way to ask for several at once. A call acts in one workspace and is checked against your membership of it.

Source: services/runtime/src/runtime/mcp/tools.py:132-166.

Failures are opaque on purpose. An unanticipated failure returns one generic message and nothing else, with the detail in the server logs. You cannot get the underlying error out of a tool call, and that is intentional: a database error can carry the query that produced it.

Source: services/runtime/src/runtime/mcp/tools.py:566-574.

search_knowledge_base is the least proven of them. It has never been observed returning a result end to end. See its page.

The connection URL belongs to the deployment. There is no single address for this product; each deployment publishes its own and a deployment with MCP off publishes none. Settings → MCP in the helpdesk shows it. See Connect Claude, Connect ChatGPT or Connect Gemini.