WSO2 scores 83.0 on the Kin Score, exemplar band, flat at 0.1 below the last run. Its Agent Readiness is 35.4, agent-ready. That is one of the stronger records an API management vendor holds on the network. WSO2 API Manager is open source, and its management plane is itself a set of REST APIs. The catalog has the parts of the product that run APIs. It is missing the part that creates them.
What is in the surface
The provider record counts 9 published APIs, and they are the product APIs WSO2 documents: Publisher v4, DevPortal v3, Admin v4, Gateway v2, Service Catalog v1, DevOps v0 and Governance v1. Those were split into 90 OpenAPI contracts, with 142 JSON Schemas pulled out of them. None of the 90 is marked as derived, and the rubric counts all of them as callable.
Group the server entries in those contracts by product API (a few contracts declare two):
| Product API | Server entries |
|---|---|
| Admin v4 | 51 |
| DevPortal v3 | 29 |
| Gateway v2 | 10 |
| Governance v1 | 4 |
| DevOps v0, Service Catalog v1 | 2 each |
| Client Registration v0.17 | 1 |
| Publisher v4 | 0 |
Publisher v4 is the first documentation link in WSO2’s own pointer list. It is the API you use to create an API, version it, attach policies and push it to a gateway. It has no contract on apis.io. The word “publisher” appears in eight of the files, but no file is served from /api/am/publisher/v4. We dropped it somewhere in the split, so this is our defect, not WSO2’s.
Every one of the 90 servers is apis.wso2.com. That is the placeholder host WSO2’s own definitions ship with. API Manager is software you run yourself, and the examples inside the same contracts call https://localhost:9443. “Callable 100.0” here means the contracts declare a server, not that an agent outside your installation can reach one.
| Facet | Score |
|---|---|
| Access clarity | 92.1 |
| Operational transparency | 86.8 |
| Discoverability | 83.3 |
| Contract quality | 64.1 |
| Contract governance | 62.9 |
| Developer ergonomics | 57.7 |
What the agent record actually shows
The agentic-access file maps 268 operations, 122 of them acting and 6 human-in-the-loop. It is derived, and so are the Agent Skills, so neither counts as WSO2’s work. The scope file holds 51 scopes under the password grant.
The record also lists a “WSO2 MCP Server” at apis.wso2.com that requires OAuth. Read the source and it is not a server WSO2 runs. It comes from the DevPortal’s /mcp-servers endpoints, which list the MCP servers an API Manager installation publishes to its own developers. That capability is genuinely interesting, because WSO2 is turning a gateway into an MCP registry. But it describes a feature of the product, not an endpoint we probed, and the record should say so. That is also our defect.
Of the 103.3 rubric points this record earns, at least 42.0 come from artifacts WSO2 published itself.
Takeaway
Three things would move the number honestly. We need to restore Publisher v4 as a contract. We need to relabel the MCP entry as a product capability. And WSO2 could document idempotency on its write operations, which is one of the dimensions still dark in the Agent Readiness record, along with protected resource metadata, dynamic client registration and a well-known catalog. WSO2 has published a management plane most vendors keep private. The catalog should show all of it.
See the full profile at apis.io/providers/wso2/.