MCP support has quietly become a buying criterion

When we designed our scoring axes we gave API and MCP access five percent, on the reasoning that few buyers would exercise it. The community reviews arriving since launch suggest we may have called that slightly low.

The pattern in the feedback is consistent. Buyers who write any code at all want to drive the platform from outside it: seed data from a script, run a schema change in CI, let their own agent read and write the data model. Four of the eleven tools in our index make that straightforward. Three offer nothing at all.

The spread is unusually wide

Our top score on this axis is 4.5 and the bottom is 2.5, which is one of the widest ranges of any axis we measure. On most axes the leaders and the laggards are separated by about a star. Here it is closer to two, and the gap is structural rather than a roadmap item.

The tools that score well tend to have been built by teams who use their own product programmatically. The tools that score badly tend to be the ones where the chat window is the only interface, by design.

Why it matters more than five percent suggests

The argument our reviewers make is that a platform without programmable access cannot be part of a larger system. It can be a product but not a component. As more teams run their own agents against their own infrastructure, a builder that cannot be scripted becomes a dead end regardless of how good its generation quality is.

We are not changing the weighting mid-quarter, because a published weighting that moves whenever we get feedback is not a methodology. It is on the agenda for the next review of the axes, and if it changes we will publish the before and after.

What to test

Ask for the API documentation link before you buy. If the answer is a support ticket, you have learned something. Then check whether there is an MCP server, and whether schema changes are available through it or only through the interface.