Appwrite MCP server

What it does

This server gives an MCP client access to the Appwrite API: tables and documents, users and teams, storage buckets, functions, messaging, sites and, on Appwrite Cloud, the console side such as projects and organizations. Appwrite publishes it in its own GitHub organization.

You don't get one tool per API method. The client sees a handful of tools instead. appwrite_get_context summarises the workspace and appwrite_search_tools looks up methods in an internal catalog. Reads (list and get) run through appwrite_call_tool. Everything else, from create to delete, goes through appwrite_call_write_tool, which wants confirm_write=true plus a one-line reason of up to 256 characters. Appwrite stores that reason in the project's audit log, so the Activity tab shows why each change was made. A reason that is blank, too long or has line breaks is rejected before any request goes out.

On Appwrite Cloud each call can also take an environment_id, for example staging, together with the project_id the environment belongs to. A local run has its environment fixed by APPWRITE_ENVIRONMENT_ID and refuses calls that name a different one.

What the catalog holds depends on how you connect. The hosted server at https://mcp.appwrite.io/ signs in through the browser with OAuth and registers 1029 methods across 41 services. A local stdio run with a project API key gets 689 methods across 27 services, since project keys can't reach console routes. The local run is aimed at self-hosted instances, though without APPWRITE_ENDPOINT it talks to https://cloud.appwrite.io/v1.

Results longer than 4000 characters come back as a preview plus an MCP resource address. The server keeps the last 50 of them. A docs tool, appwrite_search_docs, only shows up when OPENAI_API_KEY is set, and each query costs one OpenAI embedding call. Setting MCP_APPS=1 adds appwrite_show, an interactive view of tables, deployments, files, users or usage for clients that can render MCP Apps.

What it needs

Hosted: a client that can do OAuth sign-in. Codex also needs `codex mcp login appwrite`. Claude Desktop custom connectors need a Pro or Max plan, or an owner on Team and Enterprise plans. Otherwise bridge with `npx -y mcp-remote https://mcp.appwrite.io/`, which needs Node.js, as do JetBrains and Cline. Local: create a project API key in the Appwrite Console and set APPWRITE_ENDPOINT to your instance's API base ending in /v1, not the Console URL.

Limits

• Not covered The local API-key run hides console services such as organizations, projects, domains, billing, migrations, dedicated databases, usage, VCS and WAF administration
• Not covered Each call is still limited by the API key's scopes or the scopes approved at OAuth sign-in
• Limit Writes are refused without confirm_write=true and a one-line reason of at most 256 characters
• Limit A local run works in one environment, set by APPWRITE_ENVIRONMENT_ID; run one server per environment
• Not covered Environments exist on Appwrite Cloud only; self-hosted Appwrite has none, and older self-hosted versions ignore the reason header
• Limit appwrite_search_docs is absent unless OPENAI_API_KEY is set; each search is one paid OpenAI embedding call
• Size cap Catalog search returns 8 matches by default, up to 20; docs search 5 pages by default, up to 10
• Size cap Results over 4000 characters are stored as resources, and only the latest 50 are kept
• Early release MCP Events (webhook subscriptions to project changes) are described as in development and not available yet
• Limit The local process exits at start if endpoint, project ID or key is wrong, or the key can read none of the services it probes

The local API-key run cannot reach console services (organizations, projects, domains, billing, migrations, dedicated databases, usage, VCS and WAF administration); those are on the hosted server only. Even on the hosted server, each call is limited by the scopes granted at sign-in. Documentation search is absent unless OPENAI_API_KEY is set. MCP Events (webhook subscriptions to project changes) are described in its docs as in development and not available yet. The local process exits at start if the endpoint, project ID or key is wrong, or the key has no readable scope among those it probes.

Who it suits

A good fit for Appwrite Cloud users who want an assistant to look at and change their projects without handling keys. The hosted endpoint signs in through the browser, reaches the full catalog and can work in environments such as staging. Self-hosted Appwrite users get a local stdio run tied to one project and one key. Since the write tool can create and delete data, grant the key or OAuth consent only the scopes you need, and use the audit log reasons to review what changed. If you only want documentation answers, note that the docs tool needs your own OpenAI key.