Blog

Announcement6 min read

Introducing MCP1: the gateway we built for ourselves

MCP1 started as an internal tool at Appwrite. Joining every system we run behind one URL changed how fast we work, so we’re opening it to every team.

Eldad FuxFounder and CEO, Appwrite
mcp1.com/mcp/appwrite

MCP1 didn’t start as a product. It started as a fix for something that slowed down every team at Appwrite: the answers we needed were spread across more systems than anyone could keep open at once.

So we built a gateway for ourselves, put every system we run behind it, and gave every teammate’s agent one URL. It changed how fast we work more than any tool we’ve adopted in years. Today we’re making it available to every team, as MCP1.

Our knowledge lived everywhere

Appwrite is a cloud platform, and a cloud platform runs on a lot of systems. Metrics live in Prometheus and Grafana, logs in Loki, profiles in Pyroscope, alerts in Alertmanager and errors in Sentry. Deploys go out through Argo CD to clusters on AWS, Google Cloud and DigitalOcean, with traffic through Cloudflare and Fastly. Customer conversations are in Help Scout, product data is in Metabase, email goes out through Resend, and our code lives on GitHub.

Each of these is good at its job. None of them knows what the others know.

And the questions that matter most live between them. Why did this customer’s builds start failing? The conversation is in Help Scout, the error is in Sentry, the log lines are in Loki, the rollout that changed things is in Argo CD, and the customer’s project and region are in Metabase. Answering it meant five tabs, three logins and usually a Slack thread asking whoever had access to take a look.

Agents could use our tools. Just not together.

When MCP arrived, we did what every engineering team did: we connected our agents to the servers we needed. Then we noticed what it cost.

  • Every person set up every server in every client: Claude Code on one machine, Cursor on another, Claude on the web.
  • Tokens went into config files, usually with more access than the task needed, and nobody could say where all of them were.
  • Each team ended up with its own corner of the stack. Support couldn’t see deploys. Engineering didn’t see the conversations.
  • Nobody could answer the simplest security question: which agent called what, and as whom?

It worked for one person. It didn’t work for a company.

So we built one URL

We put a gateway in front of everything. Every teammate connects their agent to one address and authenticates once, as themselves. Groups decide what each team can reach: engineering gets the infrastructure, success gets the conversations and the product data that explains them, devrel gets usage and email. The tokens stay in the gateway, sealed. Every call is checked against our rules and recorded.

Setting up a new teammate went from a round of access requests to adding them to a group. That gateway is what we now call MCP1.

The power is in the joins

We expected the gateway to save time on setup. What we didn’t expect was how much it would change the questions people asked.

When one agent can reach every system at once, under one person’s permissions, it stops looking things up and starts connecting them. The customer in a Help Scout thread is a project in Metabase. That project’s errors are in Sentry, its builds ran on workers Prometheus watches, and the rollout that touched its region is in Argo CD. Each system holds one piece. The answer is the match between them.

Claude · connected to MCP1 6 servers
A customer says their builds started failing this morning. What changed?
  1. helpscout__searchThe customer wrote in at 09:12: builds fail with exit code 137Help Scout
  2. metabase__sqlTheir project builds in Frankfurt, and its failures start at 08:40Metabase
  3. sentry__search_issuesNew since 08:41: build worker out of memory, in Frankfurt onlySentry
  4. argocd__list_appsThe builder rolled out a new image in Frankfurt at 08:38Argo CD
  5. prometheus__queryBuild worker memory has sat at its limit since the rolloutPrometheus
  6. grafana__get_dashboardOther regions are on the old image, and their builds are healthyGrafana
The 08:38 builder rollout in Frankfurt raised build memory, and larger builds are being killed. Rolling the builder back in Frankfurt fixes it. Until then, the customer can build from another region. Here’s a reply you can send them.

6 tool calls across 6 systems · every call checked and recorded by MCP1

A typical question from our success team. The details are made up; the shape of the answer isn’t.

A question like that used to need a support engineer, an on-call engineer and most of a morning. Now the person who got the ticket asks it, and gets an answer with its sources.

Every system we run is good at its job. None of them knows what the others know. Through one gateway, our agents know all of it at once.

What changed for us

The gateway paid off differently for every team.

Success

Support answers with the full picture from the first reply: the customer’s project, its errors, recent deploys in its region. Fewer tickets wait on an engineer to look something up.

Engineering

An alert arrives with its context already gathered: the dashboard, the query behind it, a profile from Pyroscope, the last rollout and the errors that came with it. On-call starts from a summary instead of a blank page.

DevRel and growth

Questions about adoption, like which SDKs new projects pick or how a launch email landed, go straight to Metabase and Resend in plain words, without waiting for someone who writes SQL.

New teammates

A new hire joins a group, and their agent knows what that team knows from the first hour: the runbooks, the dashboards and the history behind a decision.

Me

I ask questions that cross the whole company every day: how a launch is landing, where support load comes from, what an infrastructure change will cost. I used to ask people and wait. Now I ask, and then I ask people better questions.

Speed without giving up control

None of this would have been safe as a pile of shared tokens. What let us say yes to agents everywhere was the control the gateway gave us.

  • Everyone is themselves. Each human authenticates with their own account, so every call is theirs, with their role and groups.
  • Read-only first. Most groups start with read-only access, and a server can hold a second, read-only token, so the service itself refuses a write.
  • Rules that ask first. Destructive tools need an admin, and rules by name like *__delete_* cover whole families of tools, including ones added later. Some calls ask the human in their client before they run.
  • Secrets stay put. Server tokens and OAuth grants are sealed with AES-256-GCM. Nobody sees a workspace server’s token, and neither does the agent.
  • A record of everything. Every call, block, authentication and change is in the audit log, with who made it and from which client.
  • One step to offboard. Remove someone from the workspace and every client and key they had stops working.

Why we’re opening it to everyone

Every company we talk to runs on its own patchwork of systems. The names change; the problem doesn’t. Their knowledge is spread across tools that don’t talk to each other, and their agents only see one at a time.

MCP1 became the tool we couldn’t imagine working without. An internal tool that changes how fast a company works shouldn’t stay internal, so we spent the last stretch turning ours into a product any team can run in a minute.

It’s built the way we’d want you to build, too: entirely on Appwrite, with Appwrite’s OAuth2 server, Teams, databases, storage and Sites. Here’s how.

What’s in MCP1 today

  • One URL per gateway. Shared gateways for groups, with full or read-only access, and personal gateways for anyone’s own servers.
  • A catalog of 149 servers, from GitHub, Linear and Sentry to Stripe, Notion and Metabase, many with one-click authentication. Any other remote MCP server works by URL. Browse the catalog.
  • Every client. Claude, Claude Code, Cursor, VS Code, ChatGPT, Codex, Windsurf, Gemini and any client that speaks remote MCP, plus API keys for CI.
  • Policies. Tool rules by role and group, rules by name, Ask first, guardrails and rate limits, with the whole policy as a YAML file you can review like code.
  • Observability. A live audit log, usage by human, group, server and tool, and CSV export.
  • Admin tools for agents. Admins run the workspace from a chat: invite people, change roles and groups, search the audit log.
  • Ready for your security review. SOC 2, GDPR, HIPAA and CCPA compliant, and hosted in Frankfurt.

Pricing

MCP1 is free for one human, 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. Compare the plans.

Start today

Create a workspace, install your servers and share a gateway with a group. It takes a minute. If you’re rolling it out across a company, our playbook is the order we’d do it in again.

We built MCP1 because we needed it. We think your team does too.

Eldad

Give your team one URL

Create a workspace, install your servers and share a gateway with a group. Free for one human.