airtable-user-mcp

manage_daemon

Idempotent

Inspect and control the Airtable MCP daemon: check status, diagnose failing tools, and start, restart, stop, or manage tunnel and token operations.

Instructions

Inspect and control the MCP daemon this server runs in. action="status" is the diagnostic to reach for FIRST when tools start failing: it reports whether a daemon is running and whether YOU are it, the transport, uptime, version/provenance, the tunnel URL, and — the part nothing else exposes — the live session state (sessionDead, the last circuit-breaker trip INCLUDING Airtable's own response body, and the browser/auth busy queue). That is how you tell "daemon gone" from "session dead" from "browser busy" instead of guessing. Control actions: start (idempotent; attaches to a healthy daemon rather than starting a second one), restart, stop (writes a sentinel so the VS Code extension does not silently respawn it), tunnel_enable, tunnel_disable, token_rotate. stop/restart answer first and exit afterwards, so this call returns normally and the daemon goes away a moment later. token_rotate and tunnel_* are loopback-only and are refused for callers arriving through the tunnel; status is returned to them with host-identifying fields blanked. The bearer token is never returned to anyone. Interactive tunnel setup (cloudflared login, creating a named tunnel) is deliberately NOT here — use the CLI or the VS Code dashboard.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "manage_daemon"
  }
}

Input Schema

Name	Required	Description
`action`	Yes	What to do. Start with "status" — it is read-only and never launches a browser or touches the lockfile.
`domain`	No	Used only by action="tunnel_enable": optional custom hostname for providers that support one.
`reason`	No	Used only by action="stop": a short note recorded in the stop sentinel, so a human reading ~/.airtable-user-mcp/daemon.stopped later knows why the daemon is down.
`provider`	No	Used only by action="tunnel_enable": which tunnel provider to start. Defaults to the persisted preference (usually "cf-quick"). "ngrok" is not available here — its authtoken lives in VS Code SecretStorage and never reaches the daemon.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.0.9Nov 7, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial context beyond the annotations: start is idempotent and attaches rather than spawning a duplicate; stop writes a sentinel so the VS Code extension does not respawn; stop/restart return before the daemon exits; tunnel_* and token_rotate are loopback-only and refused to tunnel callers; status has host-identifying fields blanked for those callers; the bearer token is never returned. These are exactly the side effects, ordering guarantees, and auth constraints annotations cannot express.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the highest-value action and organized into diagnostic-then-control blocks, which suits a seven-action tool. It is dense rather than padded, though the ALL-CAPS emphasis and rhetorical asides ("instead of guessing", "the part nothing else exposes") add length that a tighter phrasing could shed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description must convey what `status` returns, and it does: running state, whether the caller is the daemon, transport, uptime, version/provenance, tunnel URL, sessionDead, last circuit-breaker trip with Airtable's response body, and the browser/auth busy queue. Combined with the coverage of every action's side effects, an agent has enough to call this correctly without further probing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds rationale the schema cannot: why `reason` exists (it lands in ~/.airtable-user-mcp/daemon.stopped for a human later), that `provider` defaults to a persisted preference, and that ngrok is unavailable because its authtoken lives in VS Code SecretStorage. Some overlap with the schema remains, keeping it below 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb pair and resource: "Inspect and control the MCP daemon this server runs in", then enumerates the exact action set (status, start, restart, stop, tunnel_enable/disable, token_rotate). An agent can immediately tell this is a daemon-lifecycle meta-tool, distinct from every Airtable data sibling in the list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the entry point ("action=\"status\" is the diagnostic to reach for FIRST when tools start failing") and the triage logic it enables (distinguishing daemon-gone from session-dead from browser-busy). It also names what is out of scope and where to go instead: interactive tunnel setup belongs to the CLI or VS Code dashboard.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server