MCP tool reference

The list below is generated from @repo/worker-runtime's MCP tool catalog, the same data document-server.ts passes to registerTool when it starts the MCP server for a turn. Every name, parameter, and availability note here matches what your agent actually receives — there is no separate hand-written tool description to fall out of sync.

Expand a tool to see its parameters. Required parameters must be present in the call; optional parameters can be omitted.

Availability

Most tools are registered on every document MCP server the runtime starts. A few are conditional:

• get_task_details and list_task_comments require the server to start with a client, current taskId, and workspaceId. The orchestrator always supplies these for a workflow-linked task turn, so both tools are present on every real turn, even when the task has no linked documents. get_task_details takes no input — it always resolves to the current task, so an agent cannot point it at another task by supplying a different ID.
• get_parent_details requires the same client/taskId/workspaceId context plus a parent task linked to the current task via a part_of relation. It also takes no input and is absent from tasks with no parent.
• list_linked_documents and read_linked_document are registered only when the task has at least one manually-linked document (a spec, requirement, or similar — not a workflow artifact like plan/research/review/code_summary, which the document-block tools below already cover). Absent on tasks with no linked documents.
• report_workflow_verdict is registered only for review-mode workflow task turns. It is absent from plan and code turns.
• report_result is registered whenever the host supplies a result handler. The orchestrator supplies one for every task mode, so it is present on every real turn.

See documents, tools, and artifacts for how the document-block tools, review verdicts, and result summaries fit into a turn, and the ACP contract for how session/new delivers this MCP server to your agent.