Postman has published a clear answer to a question every API team with an agent roadmap is asking. In SDK vs CLI vs MCP, a dev story, Anthony Viard builds a small GitHub release-readiness tool, four API calls and about 200 lines to answer one daily question, and finds that each surface served a different consumer. The SDK suited the scheduled job, because “an SDK is a build-time contract, so for the agent to use it, somebody has to have written the calling code already.” The CLI suited unattended agent work, with one condition: “A CLI that prints JSON is a different tool from one that prints tables.” And the MCP server suited interactive, multi-user work, where per-user auth and audit matter. The conclusion is the one that carries: “They’re projections of the same API aimed at different consumers, and the only sane way to have all of them is to generate them from one specification instead of writing and maintaining each by hand.”
The numbers are borrowed and labelled as such, which is the right way to use them. “Somebody measured the GitHub MCP server at roughly 42,000 tokens of schemas, argument types, and example payloads,” while “a survey of more than 3,000 servers put the median nearer 1,900, but medians aren’t what you install.” The advice that follows is concrete: scope the toolsets, turn on read-only mode, measure again. The tooling recommendation is candid about its limits too. Fern generates the SDK in nine languages and the CLI from an OpenAPI file, and “what Fern won’t do is generate an MCP server for your API,” so the post reaches for Postman’s own MCP Generator for the third surface, reading the same OpenAPI file. It is a Postman post that recommends a non-Postman tool for two of the three surfaces, and that makes it more credible, not less.
The catalog can check Postman against its own argument. The Postman provider page lists 43 API pages, and the one-spec workflow runs through them: the Postman Specs API holds the specification the post says everything should be generated from, the Postman Collections API holds the requests the MCP Generator builds from, and the Postman MCP Server is Postman taking its own advice on the third surface. The agentic access profile maps 286 operations, 155 of them acting and 1 flagged human-in-the-loop.
The Kin Score is 73.7, exemplar band, carried by discoverability at 83.3, access clarity at 76.3, and developer ergonomics at 73.1, with contract quality at 66.8 and contract governance at 27.3. The Agent Readiness score is 57.2, agent-ready, with the MCP server, agent skills, and the full identity layer lit: delegated identity, protected resource metadata, and dynamic client registration. The dimensions holding it below agent-native are idempotency and reversibility, both unlit. That matters for this post in particular, because the CLI the author hands to an unattended agent is only as safe as the retries behind it, and an API that does not describe idempotent writes leaves every generated surface, SDK, CLI, and MCP server alike, to guess. One spec is the right answer. The spec still needs to say what happens when a call runs twice.