Files
PaperClipAI/doc/MCP-RUNTIME-OPERATIONS.md
T
3935e300dd fix(acpx): bound Claude MCP tool calls when runtime MCP servers attach (#16360)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work
> - Hosted `claude_local` runs use the ACPX engine. Paperclip gives each
run its runtime MCP servers (for example the `paperclip-assigned` tool
gateway) as ACP `mcpServers` entries.
> - Claude's default MCP tool timeout is far longer than a run. ACP
`mcpServers` entries have no per-server timeout field. So the agent
waits on an MCP call until the call answers.
> - Hosted error reports show runs that end with "Run exceeded the
adapter execution timeout (sandbox)". The stop-time diagnostics from
#15962 show the problem: the agent went silent about 50 seconds into the
run, three tool calls of ACP kind `other` stayed pending, and nothing
ended them until the 4h sandbox backstop.
> - The gateway bounds the remote provider call (10s default, 60s max).
But other steps on the gateway `tools/call` path have no deadline: DB
queries, row locks and pool acquisition, the credential steps before the
provider timer starts, and the stdio child exit wait. One stuck step
holds the agent turn for hours.
> - This pull request gives the agent's MCP client a deadline:
`MCP_TOOL_TIMEOUT` for ACP Claude runs that receive runtime MCP servers.
> - The benefit is that a stalled gateway call becomes an MCP error that
the model can see. The turn continues and does not spend the full 4h
execution budget.

## Linked Issues or Issue Description

- Refs #15962 (diagnostics that identified the silent turn with pending
tools)
- Refs #15448, #15456, #15850 (related gateway timeout and
connection-health work; this PR does not overlap with them)

**What happened?**

A hosted `claude_local` run sent parallel MCP tool calls. No call
answered. The run stayed silent for about 4 hours. Then the sandbox
execution timeout ended it with "Run exceeded the adapter execution
timeout (sandbox)".

**Expected behavior**

A stalled MCP call ends with an error after a bounded time. The agent
sees the error and continues.

**Steps to reproduce**

1. Start an ACP `claude_local` run that has runtime MCP servers.
2. Make the gateway `tools/call` request stall (for example, hold a lock
that the request needs).
3. See that the run stays silent until the adapter execution timeout.

**Paperclip version or commit**

`master` at 976cdc7.

## What Changed

- Add `ACPX_CLAUDE_MCP_TOOL_TIMEOUT_MS` (15 minutes) in
`acpx-engine/constants.ts`. The value has wide headroom over the
gateway's longest legitimate wait (60s provider calls, 2 minutes of
approval preparation, and the 10-minute connection cap proposed in
#15850).
- The ACPX engine sets `MCP_TOOL_TIMEOUT` in the agent env for Claude
when the run has runtime MCP servers. If the adapter `env` already sets
`MCP_TOOL_TIMEOUT`, the engine keeps that value. Other agents and runs
without MCP servers do not change.
- Add an engine test for the bound, the no-server case, the user
override, and a non-Claude agent.
- Document the client-side deadline in `doc/MCP-RUNTIME-OPERATIONS.md`.

## Verification

- `npx vitest run src/acpx-engine/` in `packages/adapter-utils`: 21
files, 423 tests pass.
- The new test fails without the env assignment (`expected undefined to
be '900000'`), and passes with it.
- `npx tsc --noEmit -p packages/adapter-utils`: passes.
- The env reaches Claude through the same per-session env path as
`ANTHROPIC_MODEL`. `claude-agent-acp` merges this env into the Claude
SDK env.

## Risks

- A legitimate MCP call that takes longer than 15 minutes now fails. No
gateway path is designed to wait that long. Operators can set
`MCP_TOOL_TIMEOUT` in the adapter `env` to change the value.
- The value also applies to other MCP servers in the same Claude
session, for example servers in user settings. The same override is
available.
- Warm sessions get the env when the agent process starts again. The env
is not part of the session fingerprint, so this change does not reset
resumable sessions.
- This PR does not fix the server-side step that stalls. It bounds the
effect on the run. Server-side deadlines on the gateway `tools/call`
path (DB lock and statement timeouts, a request-level deadline, SIGKILL
escalation for stdio children) are possible follow-ups.

## Model Used

- Claude Opus 5.5 (`claude-opus-5-5`) through Claude Code, with tool use
and code execution. It read the repository, traced the gateway path,
edited the code, and ran the tests.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [ ] All Paperclip CI gates are green
- [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: devinfoley <devinfoley@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-14 19:01:42 -07:00

10 KiB

MCP Runtime Operations

This runbook covers Paperclip Tools & Access runtime slots for MCP connections. It is written for board and CloudOps operators responding to stuck local stdio slots, degraded remote HTTP connections, capacity deferrals, restart storms, and secret-resolution failures.

Do not print raw bearer tokens, gateway session tokens, credential headers, environment variables, or secret values while following this runbook. The APIs below return redacted state and audit metadata; keep shell tracing disabled when exporting credentials.

Tool action approvals require PAPERCLIP_TOOL_ACTION_SIGNING_SECRET to be set independently from auth/JWT secrets. paperclipai onboard generates it for local instances, and worktree setup propagates or generates an independent value in the worktree .env; operator-managed deployments must set it explicitly. Rotate it deliberately: changing it invalidates outstanding signed tool-action approvals, so drain or reject pending approvals before rotation.

Support Matrix

Transport Local trusted Hosted cloud / public authenticated Notes
remote_http Supported Supported Preferred production path. Paperclip proxies calls through the gateway with policy, audit, timeout, and redaction controls.
local_stdio Supported through approved templates and supervised runtime slots Supported only when an explicitly trusted MCP runtime worker/host is configured Set PAPERCLIP_TRUSTED_MCP_RUNTIME_HOST or PAPERCLIP_TOOL_RUNTIME_TRUSTED_HOST only for a worker that is allowed to supervise local processes. Do not enable arbitrary agent-supplied commands.

Native runtime gateway ownership

Paperclip Runner creates an immutable MCP assignment for one agent. Its gateway stores the owner in agentId and the agent context scope. Authentication checks that the run belongs to that owner and that the gateway and profile metadata refer to the same assignment. Invalid ownership or assignment metadata rejects the token with gateway_token_run_context_invalid.

The reserved native: profile key also identifies a native assignment if its gateway metadata is cleared. Clearing metadata cannot turn the assignment into a shared gateway. Invalid JSON metadata, including JSON null, returns the same authentication rejection. Use an ordinary profile for an explicit shared gateway.

Older native gateways can have a null agentId. Authentication still checks their metadata owner. When the owner reuses the assignment, Paperclip validates the gateway and profile before it binds the gateway to that agent. A conflicting owner is never overwritten.

Native assignments enter the run configuration once through the runtime MCP delivery path. Managed gateway discovery excludes historical native assignments. Their stored rows remain available for existing runs. Explicit company gateways continue to use their configured scopes.

Client-side tool-call deadline

The gateway bounds each provider call, but the agent's MCP client also needs a bound. Without one, a gateway request that never answers holds the agent turn until the adapter execution timeout ends the run. Claude's default MCP tool timeout is far longer than a run, and ACP mcpServers entries have no per-server timeout field. So when an ACP Claude run receives runtime MCP servers, the ACPX engine sets MCP_TOOL_TIMEOUT to 15 minutes. A call that passes this deadline returns an MCP error to the model, and the turn continues. An MCP_TOOL_TIMEOUT value in the adapter env configuration takes priority.

Metrics

The board runtime health API summarizes one-hour event windows plus current durable slot state:

curl -fsS \
  -H "Authorization: Bearer $BOARD_API_KEY" \
  "$PAPERCLIP_URL/api/companies/$COMPANY_ID/tools/runtime-health" | jq .

Metrics surfaced there include:

  • Current slot counts: active, starting, running, idle, failed, stopped.
  • Stuck slot counts: starting/running slots without progress for 5 minutes.
  • Runtime events: capacity deferrals, restart attempts, restart suppression, idle evictions.
  • Tool-call health: call count, timeout count/rate, failure count/rate, average latency, p95 latency.
  • Connection health: active, disabled, degraded, remote_http, and local_stdio connection counts.
  • Secret failures: missing-secret failures in the last hour.
  • Audit write failures: durable audit_write_failed counter increments whenever MCP audit-event persistence fails.

Alerts

Alert Severity Suggested threshold First responder action
mcp_runtime_stuck_starting_slot Critical Any starting slot older than 5 minutes Inspect slot health/logs, stop the slot, restart it once, then disable the connection if it sticks again.
mcp_runtime_stuck_running_slot Critical Any running slot with no progress for 5 minutes Inspect recent audit events and active calls; restart only after confirming no healthy call is still in progress.
mcp_runtime_high_timeout_rate Warning/Critical Warning at >=3 timeouts and >=10% in 1 hour; critical at >=10 timeouts or >=25% Check upstream MCP health, runtime capacity, and gateway audit failures before retrying workloads.
mcp_runtime_high_error_rate Warning/Critical Warning at >=5 failures and >=10% in 1 hour; critical at >=10 failures or >=25% Group audit failures by reasonCode, then fix credentials/config or disable the affected connection.
mcp_runtime_capacity_deferrals_repeated Warning/Critical Warning at >=3 capacity deferrals in 1 hour; critical at >=10 Stop idle/stale slots, reduce noisy workloads, or raise slot caps only after confirming host capacity.
mcp_runtime_restart_storm Warning/Critical Warning at >=3 restarts in 1 hour; critical on any restart suppression Stop the slot, inspect stderr/audit reason codes, and keep the connection disabled until the template/upstream is fixed.
mcp_runtime_connection_health_degraded Warning/Critical Any active enabled connection with degraded/failed/missing-secret health, or any disabled enabled-path connection Run health check, refresh catalog after recovery, or keep the connection disabled and route agents to alternatives.
mcp_runtime_missing_secret_failures Warning/Critical Warning on any missing-secret failure; critical at >=3 in 1 hour Check secret bindings and provider health without revealing secret values; rotate or rebind missing secrets.
mcp_runtime_audit_write_failures Critical Any audit write failure Treat as a control-plane incident; restore DB/audit durability before retrying tool workloads.

Diagnose A Stuck Slot

  1. Read the health summary and note firing alert names:

    curl -fsS \
      -H "Authorization: Bearer $BOARD_API_KEY" \
      "$PAPERCLIP_URL/api/companies/$COMPANY_ID/tools/runtime-health" | jq '{status, metrics, alerts}'
    
  2. List durable runtime slots:

    curl -fsS \
      -H "Authorization: Bearer $BOARD_API_KEY" \
      "$PAPERCLIP_URL/api/companies/$COMPANY_ID/tools/runtime-slots" | jq .
    
  3. Inspect recent gateway audit events without printing secrets:

    curl -fsS \
      -H "Authorization: Bearer $BOARD_API_KEY" \
      "$PAPERCLIP_URL/api/tool-gateway/audit?companyId=$COMPANY_ID&limit=100" \
      | jq '[.[] | {createdAt, action, entityType, entityId, reasonCode: .details.reasonCode, tool: .details.tool, durationMs: .details.durationMs}]'
    
  4. Identify the affected slotId, connectionId, reasonCode, and whether the slot is starting, running, idle, failed, or stopped.

Clear A Stuck Slot

Stop the slot first when it is stale, idle, failed, or confirmed not to be serving a healthy active call:

curl -fsS -X POST \
  -H "Authorization: Bearer $BOARD_API_KEY" \
  -H "Content-Type: application/json" \
  "$PAPERCLIP_URL/api/companies/$COMPANY_ID/tools/runtime-slots/$SLOT_ID/stop" \
  -d '{}' | jq .

Restart once when the template/config is expected to recover:

curl -fsS -X POST \
  -H "Authorization: Bearer $BOARD_API_KEY" \
  -H "Content-Type: application/json" \
  "$PAPERCLIP_URL/api/companies/$COMPANY_ID/tools/runtime-slots/$SLOT_ID/restart" \
  -d '{}' | jq .

If restart suppression fires, do not keep retrying. Disable the connection:

curl -fsS -X PATCH \
  -H "Authorization: Bearer $BOARD_API_KEY" \
  -H "Content-Type: application/json" \
  "$PAPERCLIP_URL/api/tool-connections/$CONNECTION_ID" \
  -d '{"enabled":false,"status":"disabled"}' | jq '{id, name, enabled, status, healthStatus}'

Verify Recovery

  1. Run the connection health check:

    curl -fsS -X POST \
      -H "Authorization: Bearer $BOARD_API_KEY" \
      -H "Content-Type: application/json" \
      "$PAPERCLIP_URL/api/tool-connections/$CONNECTION_ID/health-check" \
      -d '{}' | jq '{connection: {id: .connection.id, healthStatus: .connection.healthStatus, healthMessage: .connection.healthMessage}, runtimeSlot}'
    
  2. Refresh the catalog after a remote endpoint or stdio template recovers:

    curl -fsS -X POST \
      -H "Authorization: Bearer $BOARD_API_KEY" \
      -H "Content-Type: application/json" \
      "$PAPERCLIP_URL/api/tool-connections/$CONNECTION_ID/catalog/refresh" \
      -d '{}' | jq '{discoveredCount, quarantinedCount}'
    
  3. Re-read runtime health:

    curl -fsS \
      -H "Authorization: Bearer $BOARD_API_KEY" \
      "$PAPERCLIP_URL/api/companies/$COMPANY_ID/tools/runtime-health" | jq '{status, metrics, alerts}'
    

Recovery is complete when stuck-slot alerts clear, timeout/error rates return below threshold, the connection is healthy or intentionally disabled, and audit events show no new restart suppression or capacity deferrals.

Verification Coverage

Automated coverage includes:

  • A synthetic degraded runtime-health scenario in server/src/__tests__/tool-access-service.test.ts that creates a stale running slot, degraded connection, timeout event, capacity deferral, and restart suppression.
  • A durable audit-write failure scenario in server/src/__tests__/tool-access-service.test.ts that verifies mcp_runtime_audit_write_failures fires from the counter path.
  • A gateway runtime recovery scenario in server/src/__tests__/tool-gateway.test.ts that recovers a stuck local stdio slot before reuse.