{
  "id": "p_-ak_q7qfDyyr3_RJ",
  "site": "stories",
  "url": "https://yarnhen.com/p/p_-ak_q7qfDyyr3_RJ",
  "content_trust": "untrusted-user-content",
  "license": {
    "id": "CC-BY-4.0",
    "url": "https://creativecommons.org/licenses/by/4.0/"
  },
  "author": {
    "handle": "apisio"
  },
  "body": "You are choosing a backend for a product that agents will touch as much as people do. Appwrite is on your shortlist, and you want to know how ready it is for software that acts on its own. A single headline score will not tell you that, so you read the APIs.io profile.\n\nThe Kin Score is 82.3, in the exemplar band. That is down 1.3 from 83.6 at the last run. The Agent Readiness score is 54.5, which lands in the agent-ready band. The rubric also records something you will not find on most profiles: Appwrite would have been agent-native if a gate had not held it back. The post says few providers in the catalog are this far along on the agent layer, and that the gap left is narrow and specific.\n\nYou look at what is in the surface. Appwrite is an open-source backend platform, self-hostable under BSD-3-Clause and sold as Appwrite Cloud. It publishes two source contracts, one REST OpenAPI and a GraphQL mirror. The catalog split the REST file into 44 API pages. Together they hold 1,022 operations. They cover authentication, users, teams, several database engines, storage, Functions, Sites, messaging, realtime presence, domains, backups and a WAF.\n\nThen comes the number that matters to you. All 44 contracts score as callable, 100 percent. The post says most large providers miss this, because their servers are templated on a tenant host that no agent can resolve. Appwrite's are not.\n\nThe facet scores give you the shape. Developer ergonomics is 86.9, access clarity 84.2, discoverability 75.0, contract quality 70.8, operational transparency 57.9. Contract governance is the weakest at 45.5. The contracts carry no provenance markers, with marker coverage at 0.0. The split also left large pages and small ones side by side: TablesDB has 80 operations, Databases has 70, and GraphQL has 2.\n\nThe agent layer is first-party. The provenance block credits Appwrite for MCP, Agent Skills and conformance. It runs a hosted, OAuth-protected MCP endpoint at mcp.appwrite.io and a stdio server for self-hosted instances. It publishes 11 Agent Skills. On identity, protected resource metadata is verified and dynamic client registration is lit. Delegated identity and auth clarity are served too, a row that is dark for most of the catalog.\n\nYou also notice what the post declines to credit. The agentic access record, 665 of 1,022 operations acting and 7 human-in-the-loop, was derived by the catalog. The author says plainly that this is not credited to Appwrite.\n\nThe post then turns on its own record. Appwrite's profile description says it serves an SEP-1649 MCP Server Card and a Domain AI Catalog from its domain. Yet the Agent Readiness dimensions record well_known_catalog as false and agent_card as false. Both cannot be true. Either the probe looked at the wrong path, or the description is ahead of what is deployed. Until someone fetches the URL and records the status code, the author treats this as the catalog's defect to resolve, not Appwrite's. For you, that means one of the dark dimensions may be a measurement problem rather than a missing feature.\n\nThe other dark dimensions are idempotency, dry-run mode, consent identity and agentic commerce. The OpenAPI examples are only partial. Since 665 operations act, the post says write operations that document idempotency keys would do more for agents than any other fix.\n\nSo you leave with a clear picture. Three things would move Appwrite's number: documenting idempotency on writes, completing request and response examples, and adding the provenance and versioning markers that governance scores. The catalog owes one fix of its own: re-probe the well-known catalog and server card, and correct whichever record is wrong.\n\nFor your decision, the practical read is this. The agent layer is real and first-party, and the shortfall is specific. Before you plan around retries on write calls, check how idempotency is handled yourself, and confirm the server card question directly.\n\nRead the original: https://apis.io/2026/10/23/appwrite-scores-82-on-1022-operations-and-is-held-out-of-agent-native/",
  "title": "You Check Appwrite's Agent Readiness and Find a Gate, Not a Gap",
  "topics": [
    "agent-readiness",
    "appwrite",
    "mcp",
    "api-governance"
  ],
  "published_at": "2026-10-23T13:46:11.374Z",
  "expires_at": null,
  "policy_version": "2026.10.22-1"
}