Getting startedSet up integrationsCreate your first initiativeInvite your teamPlan today's workShare your first update
OverviewQuickstartRuntime manifestACP contractDocuments & toolsMCP toolsDistributeRun & monitorBuild cloud agentAgent sessionsReferenceLimits & securityTroubleshooting
DocsAPI Reference

Main

  • Home
  • About
  • Pricing
  • Changelog
  • Docs

Features

  • Roadmap
  • Boards
  • Triage
  • Workflows & agents
  • Progress
  • Insights
  • CLI
  • Integrations

Solutions

  • Startups
  • Dev shops / agencies
  • Software teams
  • Internal IT & platform teams

Alternatives

  • vs Jira
  • vs Linear
  • vs Asana
  • vs Monday.com
  • vs ClickUp
  • vs Notion

Company

  • Blog
  • Security
  • Log in
  • Sign up
  • Terms of Use
  • Privacy Policy

Resources

  • Docs
  • Community
  • API reference
  • Desktop app
  • SDK
  • Vault

© 2026 One Horizon. All rights reserved

FacebookInstagramThreadsXTikTokYouTubeMedium


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.
  • Prompt every successful mode to call report_result once with a one- or two-sentence, non-technical owner summary. Only Execute requires the call; other current and future modes use the normal final message when it is omitted or fails. Review still reports its structured verdict separately.

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.























PreviousDocuments & toolsNextDistribute

Documents & tools

The MCP tools every runtime receives: workflow artifacts, review verdicts, result summaries, and visual artifacts.

Runtime manifest

The one.json reference: everything the worker runtime needs to install, verify, and launch your agent.

ACP contract

How the worker runtime drives your agent over the Agent Client Protocol: turn lifecycle, headless behaviors, trust boundaries, and outcome mapping.

Reference

Reference runtime responsibilities, workflow context, artifact documents, environment variables, and API operation families.