Expose the comment API as an MCP server so an AI agent can connect, pick up open threads, address them, and resolve them in place — closing the loop from "comment left" to "comment solved" without a human relay. Today a reviewer's comment lives only in the widget; acting on it is a human's job.
This is the inner-loop complement to the airside-agent automation, which works around GitHub (issue → branch → draft PR → review). Here the agent talks straight to the comment API and operates on the review threads themselves.
Status: parking lot — small–medium; mostly an MCP adapter over the existing contract, gated by the identity/auth question it shares with the auth-providers idea.
Shape: a thin tool layer over the HTTP contract already mounted at /api/airside — no new persistence, no new domain logic. Candidate package @airnauts/airside-mcp (or airside-integration-mcp per the integration-naming convention). Tools map 1:1 to existing use-cases/routes:
list_threads / get_thread — read open threads + comments + anchor context (zero-risk, ship first).reply_to_thread — post as the agent (needs a bot/service author identity).set_thread_status — resolve / reopen, mapping to set-thread-status.ts.
Decisions: transport/deployment (standalone process holding API base + token vs. host-mounted in-process); auth + agent author identity (depends on the auth-provider seam — first cut likely a static service token + configured agent author); gate writes behind explicit config so an agent can't silently close human threads. Warrants an ADR when picked up — it opens a new automated write path into the comment store.
Rationale in docs/ideas.md ("MCP server — let an agent read and resolve comments directly via the API").
Expose the comment API as an MCP server so an AI agent can connect, pick up open threads, address them, and resolve them in place — closing the loop from "comment left" to "comment solved" without a human relay. Today a reviewer's comment lives only in the widget; acting on it is a human's job.
This is the inner-loop complement to the
airside-agentautomation, which works around GitHub (issue → branch → draft PR → review). Here the agent talks straight to the comment API and operates on the review threads themselves.Status: parking lot — small–medium; mostly an MCP adapter over the existing contract, gated by the identity/auth question it shares with the auth-providers idea.
Shape: a thin tool layer over the HTTP contract already mounted at
/api/airside— no new persistence, no new domain logic. Candidate package@airnauts/airside-mcp(orairside-integration-mcpper the integration-naming convention). Tools map 1:1 to existing use-cases/routes:list_threads/get_thread— read open threads + comments + anchor context (zero-risk, ship first).reply_to_thread— post as the agent (needs a bot/service author identity).set_thread_status— resolve / reopen, mapping toset-thread-status.ts.Decisions: transport/deployment (standalone process holding API base + token vs. host-mounted in-process); auth + agent author identity (depends on the auth-provider seam — first cut likely a static service token + configured agent author); gate writes behind explicit config so an agent can't silently close human threads. Warrants an ADR when picked up — it opens a new automated write path into the comment store.
Rationale in
docs/ideas.md("MCP server — let an agent read and resolve comments directly via the API").