Hub MCP tools

aipos-mcp is a stdio MCP (Model Context Protocol) server, spawned by the agent host through the workspace’s .mcp.json. The Claude CLI picks that file up and connects on its own; other vendors’ CLIs wire MCP up differently and need their own setup. Every call — including denied ones — is written to the ledger. One master switch (“Allow agents to reach the hub”) decides whether agents reach the hub at all — off, even the read tier is refused; everything below assumes it is on.

Read-only (no per-tool grant)

workspace_status · list_tasks · get_task · workflow_status · search_workspace · build_index · workspace_doctor · post_mortem_candidates · list_deliveries (teams module; brief clamps each cover note to its first line) · get_delivery (teams module) · list_specs (specs module) · get_spec (specs module) · validate_task_specs (specs module)

Write (authorised by you)

Authorised on the Tools page by capability group. Expanding a group gives per-tool control. The grouping is presentation only: authorisation is stored, and enforced, per tool.

New workspaces pre-authorise the everyday tools. These five stay off until you open them, because they are the checks themselves: set_task_verification, set_milestone_verified, advance_phase, publish_delivery, upgrade_workspace_assets. They are marked (off by default) below; everything unmarked is granted on day one.

• Task editing — create_task · update_task_status · set_task_verification (off by default)
• Collaboration (collaboration module) — claim_task (compare-and-set, cannot be stolen, requires an identity via --agent or AIPOS_AGENT) · assign_task (dispatch may override)
• Team delivery (teams module) — publish_delivery (off by default; packages a note plus attachments into the outbox — agents have no routing surface at all: a delivery leaves the outbox either because a human pressed send or because a human switched on auto-send for that edge in advance. Attachments are workspace-relative paths and keep that layout inside the envelope, so two capabilities can both deliver a specs/<name>/spec.md; supersedes marks an earlier, still-unsent envelope as replaced rather than deleting it)
• Knowledge records — record_decision · record_note · record_progress · record_rejected · record_lesson · record_lesson_fired · archive_stale_lessons
• Phases & milestones — advance_phase (off by default; no force) · add_milestone · set_milestone_done · set_milestone_verified (off by default)
• Handoff & maintenance — generate_handoff · upgrade_workspace_assets (off by default; engine curriculum sync — the operating guide and skills the engine shipped into the workspace; dryRun to preview)

Module-bound tools are only exposed where the module is on

In a workspace without the module enabled, these tools do not appear in the agent’s tool list at all, nor in the Tools page authorisation directory.

What agents can never do

There is no tool surface for forcing a gate, satisfying a manual confirmation, or writing across workspace boundaries. Those are structural, not permission settings you could turn on.