MCP

Use the hosted RobotRock MCP server to add human-in-the-loop approvals to any MCP-native agent runtime.

Endpoint: https://mcp.robotrock.io/mcp

Tools

Optional send_to_human fields include priority (low, normal, high, urgent) for thread-scoped inbox ordering — see Priority.

get_feedback_analysis

Call this before improving agent code that uses send_to_human. It returns the same analysis shown in the RobotRock dashboard under Statistics for the selected app and task type.

Arguments:

Response fields (when found: true):

• status — pending, running, completed, or failed
• taskCount, periodStart, periodEnd — analysis window (last 30 days of handled tasks)
• summary, recommendation — markdown insights from human feedback
• agentInstructions — enriched prompt for a coding agent (use when status is completed and isHealthy is false)
• isHealthy — when true, no changes are recommended
• message — human-readable hint (not found, in progress, healthy, etc.)

Trigger new analyses from the dashboard (Statistics → Analyze feedback); the MCP tool is read-only.

When improving agent code, call get_feedback_analysis with the same app and type as send_to_human. Pass optional version on send_to_human (agent release) so feedback analysis can compare human feedback over deploys.

Authentication (per customer)

Every customer uses their own API key from the RobotRock dashboard (Settings → API Keys). The hosted server validates the key and routes tasks to that customer's tenant.

{
  "mcpServers": {
    "robotrock": {
      "url": "https://mcp.robotrock.io/mcp",
      "headers": {
        "X-Api-Key": "ll_your_api_key"
      }
    }
  }
}

You can also pass Authorization: Bearer ll_your_api_key.

There is no shared server API key — each customer's key identifies their workspace.

Waiting for a human response

Polling (default)

By default, send_to_human creates a task without webhook handlers and returns { taskId, delivery: "poll" }. Poll get_task every few seconds until status is handled. This is the right path for chat-based MCP clients (e.g. Cursor) that do not surface SSE notifications to the agent.

When handled.actionId is robotrock:mark-done or robotrock:reject-request, stop the agent — the human closed or rejected the request outside your task actions (reject includes handled.data.feedback). These are not your approve / reject action ids.

SSE push (opt-in)

Pass delivery: "sse" on send_to_human only if your MCP client keeps the HTTP session open and handles robotrock/task_handled logging notifications. This registers the MCP server's webhook on each action so results can be pushed over SSE:

1. Call send_to_human with delivery: "sse" → receive { taskId, delivery: "sse" }
2. Keep the MCP SSE connection open
3. When a human handles the task, the server pushes a notification:

{
  "type": "robotrock/task_handled",
  "taskId": "task_abc",
  "action": { "id": "approve", "title": "Approve", "data": {} },
  "handledBy": "alice@acme.com",
  "handledAt": "2026-06-07T12:00:00.000Z"
}

Custom webhook

Pass callbackUrl to receive an HTTP POST on your own backend when the task is handled (delivery: "callback").

Webhook verification (hosted MCP)

When delivery: "sse" registers the MCP webhook URL, RobotRock signs each callback with that tenant's webhook signing secret (Settings → Webhooks). The hosted MCP server does not use a single global secret — it looks up the tenant secret by taskId via Convex.

Set the same ROBOTROCK_MCP_INTERNAL_TOKEN on:

1. The MCP Vercel project (apps/mcp)
2. The Convex deployment (apps/app)

Generate a long random string (not a customer webhook secret). Convex exposes mcpWebhooks:getWebhookSigningSecretByPublicTaskId to the MCP server when the token matches.

Self-hosting (monorepo)

Deploy apps/mcp to Vercel. Required environment variables:

Routes:

• GET/POST/DELETE /mcp — MCP Streamable HTTP
• POST /webhooks/robotrock — RobotRock task handled webhooks
• GET /health — health check

When to use MCP vs other integrations

Related

• Send to human
• Webhooks