MCP tool catalogue

Overview

This system speaks MCP: an AI client can do the same things a human does in the user interface, with the same permissions and the same trail. The server runs as its own process over stdio and has neither kernel nor database; it calls the REST interface like any other client.

This release exposes 2168 operations, and every one of them is also a tool. The catalogue is derived from the OpenAPI document — there is no second list that could go stale.

What a client actually sees

Not 2168 tools. That would be unusable for any client: hundreds of schemas fill the context window before the first question is asked. The default set therefore has three layers.

1. Curated tools (22). For the paths taken every day — search, customers, work items, tickets, projects, quotes, contracts, time tracking and knowledge (Pages). They carry narrow schemas and short descriptions so a model hits them without looking anything up.

2. Three generic tools. list_operations finds an operation, describe_operation returns its exact signature, invoke_operation runs it. That makes every one of the 2168 operations reachable without a single extra schema in the context.

3. One tool per operation, on request. With the environment variable MCP_EXPOSE_ALL_OPERATIONS=1 the server announces every operation separately. The name of such a tool is the operationId, reduced to [A-Za-z0-9_-] and truncated to 120 characters. tools/list then pages in blocks of 200; nextCursor is the base64-encoded offset.

The curated tools

• create_ticket_reply
• create_time_entry
• create_work_item
• get_customer
• get_project
• get_quote
• get_work_item
• list_contracts
• list_customers
• list_projects
• list_quotes
• list_tickets
• list_time_entries
• list_work_items
• pages_append_blocks
• pages_ask
• pages_create_page
• pages_get_page
• pages_query_database
• pages_upsert_row
• search
• update_work_item_status

Plus the three generic ones: list_operations, describe_operation, invoke_operation.

What a tool may do

• Never more than the human. Permissions, brand scope and audit trail bind in the API, not in

the tool. An MCP call can do nothing that the identity it runs under could not do itself.

• Writing calls ask first. Every writing tool carries a confirmation guardrail; without explicit

confirmation it does not execute.

• Disabled modules are invisible. When a module is off, the server hides its tools from

tools/list — the same rule as in the user interface. It fetches that state via GET /api/v1/me and holds it for 45 seconds.

• Hiding is not a security boundary. If the state cannot be fetched, the server deliberately

keeps listing unfiltered. The boundary is drawn by the server: operations of disabled modules answer with 404, not with a message that would reveal their existence.

Protocol

The server answers initialize, ping, tools/list and tools/call. There is no HTTP endpoint: the connection runs over stdio.

The tool catalogue is produced by app:mcp:export-operations and written to mcp/var/operations.json next to the server.

Next

• Connecting the MCP server — own identity, token, start over stdio.
• API and MCP reference — every one of the 2168 operations with permission,

path and parameters. Every row there is also a tool.

referenz.mcp · Available from version 0.5.4