Veeva scores 72.8 on the Kin Score, exemplar band, down 2.9 from 75.7 at the last run. Its Agent Readiness is 41.5, agent-ready, and the rubric notes it would have been agent-native if a gate had not held it back. That is a strong record for the company that calls itself the leading cloud software provider to life sciences. It is also a record built mostly on documentation, not on contracts.
Veeva describes Vault as one platform whose REST API covers documents, binders, configurable objects, workflows, users, groups, SCIM provisioning, sandbox management and the Direct Data API for bulk export, all queryable with VQL. The catalog lists 9 API pages for it. The machine-readable part of that is much smaller.
What is in the surface
The six OpenAPI contracts (Authentication, Documents, Objects, Query, Users, Workflows) hold 16 operations between them. Documents has 7, Objects has 5, and the other four have one each. All six were split from a single 15-operation “Veeva Vault REST API” file at version 25.3 that we harvested without recording where it came from. Veeva’s own API reference, meanwhile, is now at 26.2.
None of the six contracts scores as callable. Every server is templated on {vaultDomain}, defaulting to myvault.veevavault.com, because each customer runs on its own Vault host. That is how Vault is built, and a contract for it has to say so. But from outside a tenant, an agent reading these contracts has no endpoint it can actually call.
| Facet | Score |
|---|---|
| Developer ergonomics | 82.7 |
| Contract quality | 77.0 |
| Operational transparency | 76.3 |
| Discoverability | 75.0 |
| Access clarity | 65.8 |
| Contract governance | 45.5 |
Ergonomics and transparency carry the score: a developer portal, versioned release notes, the open-source Java SDK (VAPIL) on GitHub, a VQL reference, published rate limits, and a Spark Messaging event surface. Veeva also carries the Health regulatory regime, and it scores 23.4 there.
The MCP story is the interesting part
Veeva ships two first-party MCP servers, and they cover the two things an agent needs. The Vault Documentation MCP at docs.veevavault.dev/mcp is public and anonymous, and it exposes one search_documentation tool over the developer portal, API reference, SDK javadocs and Vault Help. The Vault MCP Server lives at https://{host}/api/ai/mcp on the customer’s own tenant. It needs a Bearer Vault API token and the Vault AI entitlement, and it exposes each Vault AI agent action the signed-in user is allowed to run as a tool.
That is a sensible design for regulated data: anyone can read the docs, and actions only happen inside the tenant under the user’s own permissions. The identity row of the Agent Readiness record is dark, though. Protected resource metadata, delegated identity, dynamic client registration, consent identity and idempotency are all unlit. Two of the dimensions that are lit, agentic access (15 operations, 8 acting) and Agent Skills, rest on artifacts we derived rather than ones Veeva published, so I do not credit Veeva for them.
Takeaway
Three things would move the number. Veeva could publish its own OpenAPI at the current 26.2 version to replace our 16-operation split. The tenant MCP server could advertise protected resource metadata. And the write operations could document idempotency, which matters when the records are regulated. Veeva has done the documentation work and has more of the agent work done than most. The contract work is the part still missing.
See the full profile at apis.io/providers/veeva/.