Introducing MCP1: the gateway we built for ourselves

Every company runs on more systems than one person can keep in their head. Appwrite is 100% remote, with Appwriters in more than 15 countries, so almost everything we know lives in those systems and not in hallway conversations. When you need an answer, you go and dig for it.

MCP1 started as our way to stop digging: one URL that every Appwriter connects their agent to, with the systems we run on behind it and each person’s access checked on every call.

How it started#

This year agents stopped being only a coding tool. At Appwrite they now answer support questions, check on deploys and pull numbers for planning, and MCP is how they reach the systems we run on. We started the way most teams do, connecting agents to the servers we needed one person and one client at a time.

That worked for the first few people and then stopped working. Everyone configured every server in every client, Claude Code on one machine and Cursor on another. API tokens ended up in local config files, usually with more access than the task needed. Support had no way to see a deploy, engineering didn’t see the customer conversations, and nobody could tell me which agent had called what, or as whom.

So we put a gateway in front of everything. Each Appwriter connects to one URL and signs in with their Appwrite account, and groups decide what each team can reach. The tokens stay in the gateway and nobody needs to see them. Every call is checked against our rules and written to an audit log.

What sits behind our gateway#

Appwrite Cloud runs on Kubernetes clusters on DigitalOcean, with more infrastructure on AWS and Google Cloud and traffic going through Cloudflare and Fastly. Argo CD deploys it. Prometheus, Loki, Pyroscope and Alertmanager watch it, with Grafana on top, and Sentry collects the errors. Customer conversations are in Help Scout, product data is in Metabase, transactional email goes out through Resend, and the code is on GitHub.

Our groups follow the way we work: engineering, success and devrel, plus an everyone group that every Appwriter is in. A group decides which of those systems its people reach and which tools they can call there. When someone joins, adding them to their group is the whole setup.

The answers live between systems#

We expected the gateway to save us setup time, and it did, but the bigger change was that people started asking questions no single system could answer.

Each system knows one piece of a story. The customer who writes in to Help Scout has a project in Metabase. Their errors are in Sentry, their builds ran on workers Prometheus watches, and the rollout that touched their region is in Argo CD. Putting those pieces together used to take a support engineer, an on-call engineer and a couple of Slack threads. With all of it behind one URL, the person who got the ticket asks their agent, and the agent does the matching.

With one system behind it, an agent is a nicer search box. With ten behind one URL, it can connect a ticket to a deploy, an error and a customer, under the permissions of the person asking, and that’s what kept us investing in the gateway after the setup problem was solved.

What we learned running it#

A few things surprised us along the way, and two of them became MCP1 features.

Read-only tokens do most of the safety work

Almost every token behind our internal gateway is read-only. When an agent tries to change something in Cloudflare, DigitalOcean or Fastly, the vendor refuses it, whatever our code decided. The gateway’s rules are the first line and the token’s own scopes are the second, and the second line doesn’t have any bugs we wrote. In MCP1 this is the read-only secret: a server can hold a second token with read scopes only, and anyone with read-only access calls with it.

Agents should use your definitions

Ask an agent for last month’s active projects and it will happily write its own SQL, with its own idea of what active means. Our Metabase tools point the agent at saved questions first, because those carry the definitions of revenue and active projects that the team already agreed on, so the agent’s answer matches the dashboard people already trust.

Big answers make agents worse

A tool that returns a few megabytes of logs fills the model’s context and buries the answer. We cut oversized answers and tell the model to ask for less, with a filter or a smaller time range. MCP1 does the same in every workspace, at 1 MB by default, and in our experience a smaller limit gives better answers.

Summaries beat raw APIs for the common question

For most of our systems the agent gets two kinds of tools. A summary answers the question people ask every day, like what’s firing right now or which deploys aren’t healthy, in a single call. A read-only API covers everything else, for the unusual question. When you pick MCP servers for your team, look for both.

What changed for us#

The clearest change is in support. A reply used to wait for an engineer to look up the customer’s project, its errors and the deploys in its region. Now the person on the ticket gets that in one answer, with links to where each piece came from, and writes back with it. On-call changed the same way: an alert comes with the dashboard behind it, the last rollout and the errors around it already gathered.

For me, it changed how I prepare for almost every conversation. I ask questions that cross the whole company, like how a launch is landing, where support load comes from or what an infrastructure change will cost, and then I go to the people involved with better questions.

Why we’re opening it#

Every team we talk to has its own version of our stack and the same problem. The knowledge is spread across tools that don’t talk to each other, and an agent sees one of them at a time. So we turned our internal tool into a product any team can set up in a few minutes.

MCP1 is built on Appwrite, the way we’d want any team to build: Appwrite’s OAuth2 server authenticates every MCP client, Teams hold workspaces and roles, TablesDB holds the audit log and Sites runs all of it. I wrote about the details in How we built MCP1 on Appwrite.

What’s in MCP1 today#

• Shared gateways granted to groups with full or read-only access, and personal gateways for your own servers and tokens.
• A catalog of 154 remote MCP servers, many with one-click OAuth, and any other server by URL over Streamable HTTP or SSE.
• Claude, Claude Code, Cursor, VS Code, ChatGPT, Codex, Windsurf, Gemini and any other client that speaks remote MCP, plus API keys for CI.
• Tool rules by role and group, rules by name like *__delete_*, Ask first rules that confirm a call with the human, and the whole policy as a YAML file.
• An audit log of every call, authentication and change, and usage by person, group, server and tool.
• SOC 2, GDPR, HIPAA and CCPA compliance, with workspace data hosted in Frankfurt.

MCP1 is free for individuals, with 3 gateways and 15 servers. Team is $12 per member a month, with groups, shared gateways and usage analytics. Enterprise is $29 per member a month for up to 1,000 members, with IP allowlists and invoiced billing. The pricing section has the details.

Trade-offs worth knowing#

• MCP1 talks to remote MCP servers over Streamable HTTP or SSE. A server that only runs locally over stdio has to be hosted somewhere first.
• Read-only access trusts each server’s tool annotations. A tool without readOnlyHint counts as a write, so a read-only group won’t see it, and a server that labels a write as a read is believed. Where it matters, a read-only token is the stronger guarantee.
• Ask first depends on the client. Clients that support MCP elicitation ask the human in the chat, and clients that don’t are refused for Ask first rules.
• A call times out after 25 seconds by default and 28 at most, so long-running tools need to start a job and report back on it.

What’s next#

Create a workspace, add your servers and share a gateway with a group. If you’re rolling it out across a company, start with the 10 steps we’d follow again from our own rollout. If you build MCP servers, you can submit yours to the catalog.

I’d like to hear what you connect first and what didn’t work. You can find me on X at @eldadfux.