Geoapify publishes 34 OpenAPI specs, and scores 0 on governance

Geoapify publishes 34 OpenAPI specs, and scores 0 on governance

Geoapify has written the guide every API provider should publish this year. In How to Use Geoapify OpenAPI Specifications with AI Coding Tools and API Clients, the team explains that “for an AI coding tool, a specification works as a contract. Without it, the model relies on training data, which may be outdated or mix up similar APIs.” Geoapify publishes OpenAPI 3.1.0 specifications for its location APIs and its MCP tools, 34 in all, listed in an index.json catalog with an id, category, description and spec URL for each, MIT-licensed on GitHub with Spectral lint rules and a hosted Swagger UI. The division of labour is stated cleanly: “OpenAPI for building, MCP for runtime.”

The figures are Geoapify’s own measurements of its own files, and the most useful one is about waste. Forward Geocoding is about 60 KB; Routing and Batch are about 245 to 250 KB. In the Routing spec, “about 58% of its minified size was two worked examples, and 38 of its 60 schemas were not referenced by the /routing operation.” Hence the four rules the repository gives agents: match the task to a catalog entry, “load only the selected specification,” treat it as the source of truth, and “never invent an endpoint or parameter that is absent from the specification.” The excerpt the post prints shows why: a limit from 1 to 100, a format that defaults to geojson, a text field not to be combined with structured address fields, and a key that can go in the query or a header.

The catalog holds a smaller version of what the post describes. The Geoapify provider page lists 10 API pages, including the Routing API, the Places API, the Reverse Geocoding API and the Isoline API, against the 34 specifications the index publishes. Spec presence, agentic access, the MCP server and the rate limit signal are lit on the Agent Readiness score. The agentic access profile maps a single operation, and auth clarity is unlit, although the post’s own excerpt declares two API key schemes.

The Kin Score is 23.5, emerging band, with discoverability at 58.3 and contract quality at 45.9 against contract governance at 0.0 and developer ergonomics at 2.4. The Agent Readiness score is 30.0, higher than the composite. Those numbers do not describe the provider in this post. A company with a machine-readable index of 34 linted, licensed, versioned specifications is doing contract governance; the record has simply not read the index. That is a harvest gap, the first thing the index.json should fix, and it is the post’s own rule applied to us: treat the specification as the source of truth. Geoapify has published the catalog an agent needs. The next pass of ours needs to start from it.

← AWS says a skill's description decides whether the agent ever reads it
Jenkins says a passing build is the evidence an agent cannot reason its way to →