Appwrite scores 82.3 on the Kin Score, exemplar band, down 1.3 from 83.6 at the last run. Its Agent Readiness is 54.5, agent-ready, and the rubric records that it would have been agent-native if a gate had not held it back. Few providers in the catalog are this far along on the agent layer. The gap that remains is narrow and specific.
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. We split the REST file into the 44 API pages the catalog lists. Together they hold 1,022 operations across authentication, users, teams, four database engines (TablesDB, DocumentsDB, VectorsDB, plus managed PostgreSQL, MySQL and MongoDB), storage, Functions, Sites, messaging, realtime presence, domains, backups and a WAF.
What is in the surface
All 44 contracts score as callable, 100 percent. That is the number most large providers miss: their servers are templated on a tenant host no agent can resolve. Appwrite’s are not.
| Facet | Score |
|---|---|
| Developer ergonomics | 86.9 |
| Access clarity | 84.2 |
| Discoverability | 75.0 |
| Contract quality | 70.8 |
| Operational transparency | 57.9 |
| Contract governance | 45.5 |
The open-source check scores a full 100. The Horizontal regulatory regime scores 45.1 and upsert scores 33.3. Governance is the weakest facet. The contracts carry no provenance markers (marker coverage is 0.0), and the split we made left the catalog with large pages and small ones side by side: TablesDB has 80 operations, Databases has 70, and GraphQL has 2.
The agent layer is first-party
The provenance block credits Appwrite for MCP, Agent Skills and conformance as first-party work. 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 the identity side, protected resource metadata is verified, dynamic client registration is lit, and delegated identity and auth clarity are served. That row is dark for most of the catalog.
The agentic access record (665 of 1,022 operations acting, 7 human-in-the-loop) is one we derived, so I do not credit Appwrite for it.
Where the record disagrees with itself
Appwrite’s own profile description says it serves an SEP-1649 MCP Server Card and a Domain AI Catalog from its domain. The Agent Readiness dimensions record well_known_catalog: false and agent_card: false. Both statements cannot be true. Either the probe is looking at the wrong path or the description is ahead of what is deployed. Until someone fetches the URL and records the status code, I treat this as our defect to resolve, not Appwrite’s.
The other dark dimensions are idempotency, dry-run mode, consent identity and agentic commerce, and the OpenAPI examples are only partial. For a platform where 665 operations act, write operations that document idempotency keys would do more for agents than any of the others.
Takeaway
Three things would move the number. Appwrite could document idempotency on its write operations. It could complete the request and response examples in the contract. And it could add the provenance and versioning markers that governance scores. We owe one fix on our side: re-probe the well-known catalog and server card, and correct whichever record is wrong.
See the full profile at apis.io/providers/appwrite/.