Truto published an architecture guide to generating MCP tools from OpenAPI specs, and it opens by refusing the obvious framing. “The two are not the same shape.” An OpenAPI document describes an API’s surface; an MCP tool list describes an agent’s choices, and a mechanical translation between them produces something that technically works and practically does not. Their number for it is concrete: a typical 200-endpoint spec becomes roughly 200 tools and 40,000 to 80,000 tokens of schema, against a hard cap of 40 total tools in Cursor across every installed server and 128 tools per chat request in GitHub Copilot. So the pipeline is four steps, and only the first is the naive one — parse and dereference every $ref, rewrite schemas with descriptions an LLM can act on, filter by tag and method so a server is scoped to a domain rather than a whole API, then execute behind a proxy that owns auth and rate limits.
The measurement that should travel furthest is about spec quality rather than tooling: “fixing just 19 lines of spec inconsistencies per API improved out-of-the-box MCP tool success from 76.5% to 99.9%.” That is a claim about the cheapest available intervention in this entire field, and it reframes MCP adoption as a documentation problem. Their other statistic is a useful corrective to the hype — fewer than 5% of 22,000-plus MCP-tagged repositories created in six months contained an actual server. The failure modes they name are specific enough to design against: context rot as tool counts climb, flat-namespace collisions where a path id and a body id become the same parameter, pagination hallucinations where a model treats an opaque cursor as a page number, and silent payload corruption when a schema is copied verbatim into a tool definition. Passing a 429 straight to the caller rather than absorbing it in transport is the right default too, keeping the retry decision where someone can see it.
The catalog carries 18 API pages for Truto, and the guide is essentially a description of one of them. The Truto MCP Servers API is the pipeline itself; the Integrated Accounts API and Link Tokens API are the tenancy and auth model the proxy layer resolves against; and the unified resource surfaces — Employees, Candidates, Jobs — are what the generated tools actually reach.
Truto scores 44.0, developing on the Kin Score, with discoverability at 81.5 and contract quality at 63.4 against operational transparency at 10.5. Agent Readiness is 26.8, agent-aware, and the lit row agrees with the post where it counts: mcp_server, agent_skills and rate_limit_signal, the last of which is exactly the IETF header normalisation the guide describes. The unlit column is the awkward part for a company in this particular business. openapi_examples is dark, error_semantics is dark, and idempotency is dark — while the guide itself recommends idempotency keys for POST and PATCH deduplication. An organisation that measured nineteen lines of specification moving tool success from 76.5% to 99.9% has a few of those lines available in its own contract, and nobody is better placed to know which ones.