Ship and explain the MCP stdio client

A shippable lab artifact includes: how to run it, the metric result (discovery count; successful call; timeout on hung server), the failure you can still reproduce (calling a tool not in the discovered list, or hanging on stderr noise), the security gate for auto-approving every discovered tool including filesystem writes, and a rollback note. The user decision it supports remains: connect to a local MCP server, list tools, and invoke one allowlisted tool safely.

RUN_LIVE_EVALS=1 npm run test:live

Expected evidence: **The client discovers echo, calls it once, prints “hello”, and closes the transport.**. Store this beside the fixture version so scores remain meaningful after content changes in `mcp-in-code`.

State operating limits for the MCP stdio client in plain language: fixture size, offline vs live dependencies, and what would require a new eval set. Shipping mcp-in-code is honest scoping, not maximal confidence language.

Fill this table in your notes for the MCP stdio client:

• Proved on local stdio server exposing one read-only echo tool: …
• Unproved beyond the fixture: …
• Metric that blocks release: discovery count; successful call; timeout on hung server
• Failure still reproducible: calling a tool not in the discovered list, or hanging on stderr noise
• Security gate: auto-approving every discovered tool including filesystem writes
• Rollback: …

Ship the narrative only when the unproved list is honest. Reviewers trust narrow claims that support connect to a local MCP server, list tools, and invoke one allowlisted tool safely more than maximal language that collapses under the first production oddity.

Hand your ship note to a peer and ask them to recreate a proved/unproved ship note with rollback without watching you type. If they cannot, your evidence is still tribal knowledge. Tighten the run command and the metric line until a stranger can validate the MCP stdio client against local stdio server exposing one read-only echo tool.

At the mastery and shipping 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 a proved/unproved ship note with rollback 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