Set release boundaries for the MCP stdio client

Operational risks for the MCP stdio client calling one local tool center on auto-approving every discovered tool including filesystem writes, plus the earlier failure mode (calling a tool not in the discovered list, or hanging on stderr noise). Safety lives in executable gates, allowlists, redaction, and a named owner—not in a warning paragraph under an unsafe function.

function authorize(ctx: Context, action: Action) {
  if (!ctx.permissions.has(action.permission)) {
    throw new SafeError("forbidden");
  }
  if (action.risk === "write" && !ctx.approvalToken) {
    throw new SafeError("approval_required");
  }
}

Expected evidence: The client discovers echo, calls it once, prints “hello”, and closes the transport.. A failed assertion means stop, investigate, and do not publish the MCP stdio client.

Name who can disable the feature, what data is retained, and how to roll back to the last known good artifact. Pin the reviewed configuration (versions, thresholds, allowlists) so “what shipped” is reconstructable for mcp-in-code.

Write the release blocker as a predicate, not a feeling: “Do not ship the MCP stdio client if auto-approving every discovered tool including filesystem writes.” Pair it with a passing control that shows the reviewed configuration still works for local stdio server exposing one read-only echo tool. Name an owner and a rollback handle (git tag, docs_version, previous image).

Security pages must not paste the happy-path demo. If your gate code looks like the implementation page, replace it with a deny/allow check aimed at auto-approving every discovered tool including filesystem writes.

State the data retention rule in one line (what is stored, for how long, who can read it). Then state the kill switch (env flag, config pin, or feature owner). The MCP stdio client is not shippable without both, even when discovery count; successful call; timeout on hung server looks healthy.

At the safety and operations stage for mcp-in-code, the job is narrower than finishing a product demo. You are creating one progressive evidence piece about local stdio server exposing one read-only echo tool that later pages inherit without redefining success. Keep that fixture small enough to inspect by hand, keep outputs copy-pasteable as text, and refuse to narrate this baseline as if it were a production SLA: direct function call without MCP discovery.

For this page specifically, success looks like an executable deny gate for the lab-specific threat while still centering the user decision to connect to a local MCP server, list tools, and invoke one allowlisted tool safely. If you cannot point to a file, command, or assertion that proves that for the MCP stdio client, stay on this page instead of advancing.

Glossary: tool · Glossary: structured output · Cheatsheet: production ops signals

Previous · Next