Announcing MCP Events: your agent hears about changes in your Appwrite project

retained text

Announcing MCP Events: your agent hears about changes in your Appwrite project_
The Appwrite MCP server now supports MCP Events. Agents can subscribe to new users, failed function executions, finished deployments, new rows, and uploaded files, and react the moment they happen.
Until now, an AI agent connected to the Appwrite MCP server could only act when you asked it to. It could create a user, deploy a function, or read a table, but it had no way of knowing that something had changed in your project since the last time it looked. If a function started failing at 2 AM, the agent found out when you did.
Today, we are announcing MCP Events for the Appwrite MCP server. Your agent can now subscribe to events in your Appwrite project, such as a new user signing up, a function execution failing, or a deployment finishing, and react the moment they happen.
In this demo, Pi subscribes to new users in an Appwrite project and goes idle. In a second terminal, Codex creates a user through the Appwrite MCP server. The event reaches Pi in about a second and wakes it up without a new prompt. Pi looks up the new user, reports back, and then unsubscribes.
What are MCP Events
MCP Events is an extension to the Model Context Protocol that lets a client subscribe to things that happen on a server. The proposal is tracked as SEP-3415 in the MCP specification repository, and the Appwrite MCP server implements it today.
An MCP server that supports events adds three things to the protocol:
- Catalog: events/list tells the client which events exist and which arguments each one takes.
- Subscriptions: The client asks for an event with specific arguments, such as "new users in project X".
- Delivery: The server sends each matching event to the client as it happens, without the client asking again.
The change sounds small, but it turns the agent from something you have to prompt into something that can keep watching your project for you. You can ask it to "tell me when the deployment finishes", "investigate any failed execution of the checkout function", or "welcome every new user in our Slack", and walk away.
On the Appwrite MCP server, each subscription is an Appwrite webhook in the project you subscribe to, created with your OAuth token, so the server keeps no database of subscriptions. The Events documentation covers how subscriptions work, their permissions, and their limits.
Two ways to receive events
Agents run in very different places, so the Appwrite MCP server supports both delivery modes from the proposal:
- Push (events/stream): for agents that run on your machine, such as Pi, which have no public URL that a server could call. The agent holds one request open, and the server streams each event back on it, with a heartbeat every 25 seconds to keep the connection alive.
- Webhook (events/subscribe): for clients with a public HTTPS endpoint, such as hosted agents. The server verifies the endpoint with a challenge, then sends a signed POST to it for every event.
Events you can subscribe to
The Appwrite MCP server launches with six events. Every event takes a required project_id, and payloads carry IDs and metadata only.
Each subscription is scoped to the exact resource you name. These six events are a starting point, and we plan to add more based on what you want your agents to watch.
Try it with Pi
Pi supports push delivery today through the pi-mcp-events extension.
- Install the MCP adapter and the events extension: Bashpi install npm:pi-mcp-adapter@^5.1.0
pi install npm:@realmikekelly/pi-mcp-events@^0.2.0
- Add the Appwrite MCP server to ~/.pi/agent/mcp-adapter.json:
JSON{
  "mcpServers": {
    "appwrite": {
      "url": "https://mcp.appwrite.io/",
      "auth": "oauth"
    }
  }
}
- Start Pi with pi and sign in to Appwrite when your browser opens.
- Ask Pi to subscribe: Subscribe with mcp_events to users.user.created on the appwrite server for project_id <PROJECT_ID>, then finish your turn and wait. Whenever an event arrives, look up that user and tell me their name and email.
Create a user in the Appwrite Console, or have another agent do it. Pi wakes up without a new prompt, looks up the user with the Appwrite tools, and reports their name and email.
When you are done, ask Pi to unsubscribe. The server closes the stream and deletes the webhook it created for the subscription, so nothing is left behind in your project.
What's next
MCP Events is still a proposal, and client support is just getting started. We will keep the Appwrite MCP server in step with the specification as it evolves.
Tell us which events you need on Discord or in the MCP server repository.
Resources
MCP Events is an extension to the Model Context Protocol that lets a client subscribe to things that happen on a server and hear about them when they occur. Instead of the agent polling with tool calls, the server pushes each event to the agent. The proposal is tracked as SEP-3415 in the MCP specification repository.
Six events at launch: users.user.created, functions.execution.failed, functions.deployment.completed, sites.deployment.completed, tablesdb.row.created, and storage.file.created. Every event takes a project_id, and most also take the ID of the function, site, table, or bucket to watch.
Push delivery (events/stream) is for agents running on your machine, such as Pi with the pi-mcp-events extension. The agent holds a request open and events arrive on it. Webhook delivery (events/subscribe) is for clients that have a public HTTPS endpoint: the server sends a signed POST to that endpoint for every event.
No. Each subscription is one Appwrite webhook in your own project, created with your OAuth token. The subscription details are encrypted and stored on that webhook, so the MCP server keeps no database of subscriptions. You can see these webhooks in the Appwrite Console, and they are deleted when you unsubscribe or close the stream.
Only IDs and metadata, such as user_id and created_at for a new user. Event payloads never contain row contents, emails, phone numbers, or execution logs. The agent fetches any details it needs with a normal tool call, using the same permissions you granted at sign in.
Each active subscription or open stream uses one webhook in the project. The Free plan allows 2 webhooks per project, and Pro allows unlimited webhooks. If you reach the limit, the server returns a clear error so the agent can tell you to upgrade or unsubscribe from another event.

document fetched 2026-10-24 11:26