Dynatrace is the software intelligence platform behind Davis AI and the Grail data lakehouse. Its Kin Score is 85.7, exemplar, up 2.0 from 83.7 on the last run. The catalog holds 48 API pages, one AsyncAPI for problem notifications and 15 Arazzo workflows. The company publishes a remote MCP server and 17 agent skills itself, and the provenance record marks both first-party.
Then there is the number the composite does not show. Of the 23 OpenAPI contracts behind those pages, 9 declare a server and 14 declare none at all. The provenance line reads callable: 39.1. As we hold them, only two in five of an exemplar provider’s contracts can be called as written.
Why the servers are missing
The contracts that do declare a server show the reason. Five of them point at https://{environmentId}.live.dynatrace.com/api/v2, and four at https://api.dynatrace.com. Dynatrace is tenant-per-customer: the Entities, Events, Logs, Metrics and Problems APIs run inside each customer’s environment, and account-level APIs on a shared host. The 14 with no server are mostly the account-management family: audits, limits, groups, permissions, policies, platform tokens, service users and more.
The MCP server works the same way. It is hosted inside each customer’s SaaS environment, so the agent-readiness record grades it templated. An agent that finds it knows it exists but still needs a tenant ID before it can connect.
That is a legitimate architecture. A contract that does not record the architecture leaves the agent to work it out. A templated server with an environmentId variable tells a client what to substitute. An empty servers array tells it nothing.
We have to be straight about where those 14 came from. Our own refine report flags every one of them as output that no archived source document covers. The account-management source we do hold declares https://api.dynatrace.com, so the empty arrays may be our loss, not a Dynatrace omission, until a fresh harvest shows otherwise.
The facets
| Facet | Score |
|---|---|
| Access clarity | 100.0 |
| Operational transparency | 94.7 |
| Developer ergonomics | 88.7 |
| Contract quality | 69.8 |
| Discoverability | 68.3 |
| Contract governance | 45.5 |
Dynatrace sells observability and holds itself to it: operational transparency is 94.7. Contract governance at 45.5 is the weak facet.
Agent readiness, gated
Agent Readiness is 48.7. That score would put Dynatrace in the agent-native band, but the band is agent-ready, gated down one step. The gate for agent-native requires both idempotency and error semantics. Error semantics is verified. Idempotency is unlit: across 133 mapped operations, 62 of them acting, there is no documented way to retry a write safely. That operation map is our derivation and earns Dynatrace nothing.
Delegated identity and auth clarity are served. Protected resource metadata, dynamic client registration and a well-known catalog are unlit, and for a per-tenant MCP server those are how an agent finds it unaided.
What would move it
The first fix is ours: re-harvest the account-management contracts from Dynatrace’s own source so all 23 declare servers, templated where the host depends on the tenant. The other two belong to Dynatrace. Document an idempotency key or a safe-retry rule for writes, which removes the agent-native gate. Publish protected resource metadata so the per-tenant MCP server can be discovered. The platform is built well. The record of how it is deployed is not yet complete.
See the full profile at apis.io/providers/dynatrace/.