Vespa has published one of the few MCP posts with a control group. In Deploy, Discover, Inspect, Observe: A Summer Spent Making a Public Vespa MCP Server, four interns, Eivin Bingen, Øystein Berntzen, Viktor Myrland, and Max Felix Storteig, describe building a standalone, publicly hosted Model Context Protocol server for Vespa Cloud, then running the same deployment tasks through an agent holding the MCP tools and an agent holding only the Vespa CLI. The MCP agent passed 97% of the deterministic assertions against the CLI agent’s 95%, and “agents using the MCP server averaged less than half the number of attempts before deploying successfully.” The sentence that carries the post is the one they land on: “Tools don’t make the model smarter; they make it wrong less often.”
The 97 against 95 is a vendor measurement on a vendor benchmark, and two points is inside the noise of a small assertion set. What survives is the attempt count, because it is the mechanism rather than the outcome: a tool with a typed schema gets called correctly on fewer tries than a CLI the model has to guess at. The design lessons are the portable part. Relative time expressions like “now-1h” worked where epoch milliseconds did not, because that is what the model has seen in training data. Log tools got a concise and a detailed mode so the assistant could choose its context budget. And the team stopped short of wrapping the CLI, instead surfacing Grafana metrics directly, “giving the assistant real observability data with no current CLI equivalent.” The worked example is a restarted content node that the assistant diagnosed after 17 tool calls across metrics, deployments, and logs.
The catalog already holds the surface those tools sit on. The Vespa provider page lists 9 API pages, and the post’s four verbs map onto them. Deploy is the Vespa Deploy API and the Vespa Tenant and Application API. Observe is the Vespa Metrics API, which is the surface the Grafana panels read from, and Inspect is the Vespa State API, where a restarted node shows up. The agentic access profile maps 18 operations, 8 of them acting, which is the same read-heavy shape the interns ended up building.
The Kin Score is 52.6, developing band. Discoverability carries it at 72.2, operational transparency at 60.5, contract quality at 56.0. Contract governance is 28.8 and access clarity is 50.0. The Agent Readiness score is 24.5, agent-aware, and the dimension that matters is the MCP server, which is unlit. Vespa has just published a public MCP server, benchmarked it, and written up the design, and the catalog record does not yet know it exists, which is a discovery gap on our side as much as a publication gap on theirs. Error semantics and OpenAPI examples are unlit too, and those are the two things a tool schema is built from. The interns proved that a typed tool makes the model wrong less often. The next step is publishing the types where a catalog can find them.