MCP1 docs

Every gateway has one URL. Add it to any MCP client and the client finds how to authenticate on its own. Your workspace’s Connect page shows these steps with your real URL filled in.

claude mcp add --transport http mcp1 https://mcp1.com/mcp/<workspace>/<gateway>

Each workspace also has a default gateway at /mcp/<workspace>. Clients can use https://mcp1.com/mcp too, and pick the workspace when they authenticate.

The gateway is an OAuth protected resource. Its authorization server is the Appwrite project’s OAuth2 server, so there is nothing else to run.

For CI and agents without a browser. Create one under Keys and send it as a bearer token.

Authorization: Bearer mcp1_live_…

A key acts as the human who made it and belongs to one gateway. It can expire and can be limited to some servers. MCP1 keeps only its hash.

Admins can stop members from making keys, or turn keys off for the whole workspace, under Settings → General.

You sign in to MCP1 with your email and a password, or with a sign-in link sent to your email. Open the menu under your name for your account: your name, email and password, the devices you’re signed in on, and two-factor sign-in.

Two-factor sign-in adds a 6-digit code from an authenticator app to every sign-in. Turn it on from the account menu in a few seconds. Admins see who has it on under Settings → Members.

A gateway is one URL holding a set of servers. There are two kinds.

Tools appear as server__tool, for example github__create_issue, so tools from different servers never collide.

Install servers from the catalog or add any remote MCP server by URL, over streamable HTTP or SSE. Admins install workspace servers; everyone can add their own.

Catalog servers that support OAuth, such as Linear, Notion and Sentry, authenticate in one click instead of with a pasted token. MCP1 keeps the tokens encrypted and refreshes them. Nobody sees a workspace server’s token, and nobody else can use a personal server’s.

A server can also hold a read-only secret: a second token with read scopes only. Humans on read-only access call with it, so the service itself refuses their writes, even if a rule in MCP1 were wrong.

MCP1 reads each server’s tools when it’s added. Press Sync on a server’s page after it changes, to pick up new tools. Admins and developers install workspace servers under Settings → Servers, and can hold a server to some groups.

The catalog lists remote MCP servers by team, from GitHub, Linear and Stripe to databases, observability and design tools. Admins install a server for everyone; anyone can add one with their own account.

Built an MCP server? Submit it to list it in the catalog of every MCP1 workspace. The MCP1 team reviews each submission, and you follow the review on the same page.

Some servers attach an interactive view to a tool: a chart, a table or a dashboard that clients like Claude and ChatGPT render next to the answer (MCP Apps). MCP1 passes those views through, as ui://<server>/… resources, to anyone who can use one of the server’s tools. When a view calls its tools again, the call goes through the same checks and the audit log as any other.

Tools that describe their output (an output schema) keep it through the gateway, and their structured results reach the client unchanged.

Groups are named sets of humans, like Engineering or Support. Admins grant shared gateways to groups, and can limit a server or a single tool to some of them. A shared gateway can hold a tool to fewer groups again.

Everyone has one role per workspace. Roles are Appwrite Teams roles.

Admins decide who can call which tools under Settings → Policies. Every tool can be turned off, need a lowest role, or be held to some groups. On top of that, rules by name cover every tool whose name matches a pattern, including tools installed later. * stands for any text.

A tool can match several rules, and every one applies. To ask first and also limit who can call, add two rules with the same pattern.

Guardrails cover every call in the workspace and live under Settings → General:

A tool call goes through only when every check passes, in this order:

1. 1You can use the gateway: it’s yours, or it’s shared with one of your groups. Admins always can; auditors never call tools.
2. 2The server is on the gateway and turned on. With a key, the key was made for this gateway and covers the server.
3. 3The tool is on, your role meets its minimum, and you’re in its groups, on the server and on this gateway.
4. 4On a read-only grant, the tool is read-only.
5. 5Rules by name: patterns like github__delete_* can block tools, set a minimum role, limit them to groups or ask first.
6. 6Guardrails: destructive tools need an admin, and members can be held to read-only tools.
7. 7You’re under the workspace rate limit.
8. 8With confirmations on, a destructive call asks you in your client first, where the client can ask. An Ask first rule always asks, and refuses clients that can’t.

A blocked call returns an error the model can read, and is logged as Blocked.

Every gateway also offers a few tools of its own, so an agent can answer questions about access without leaving the chat.

Admins’ agents get more MCP1 tools, to run the workspace from a chat. They follow the dashboard’s rules, and every change is one line in the audit log, with the client it came from. Turn them off under Settings → General.

Keep your access policy in a YAML file, review changes to it like code, and load it back. Admins export and import it from Settings → Policies. The file names things the way you do: groups by name, humans by email, servers by their short name, gateways by their URL and tools as server__tool.

version: 1
settings:
  guardDestructive: true
  rateLimitPerMinute: 120
groups:
  Engineering:
    members: [lena@acme.com, theo@acme.com]
  Support:
    members: [jonas@acme.com]
gateways:
  engineering:
    name: Engineering
    servers: [github, linear]
    access:
      Engineering: full
      Support: read-only
    tools:
      github__merge_pull_request: [Engineering]
tools:
  github__delete_repository:
    minRole: admin
rules:
  - pattern: "*__delete_*"
    minRole: admin
  - pattern: "*__send_*"
    confirm: true

The file is checked strictly. An unknown key, server, tool, group or member, a pattern that matches no tool, or a bad role or mode is an error with its place in the file, like gateways.engineering.servers[1]: no server "linaer". Preview lists every change, and a file with errors can’t be applied. Each import is one entry in the audit log.

Every call, sign-in and change is recorded: who, from which client and gateway, which tool, how long it took, and the result: OK, Failed or Blocked, with the reason. Arguments are stored encrypted, with secrets masked, unless an admin turns off Record arguments.

Owners, admins and auditors see the whole log under Settings → Audit log: filter it by kind, result, server or human, follow it live, or export CSV. Settings → Usage shows who’s active and what they call. Everyone sees their own calls under Analytics.

Run any tool from the dashboard, with a form built from its inputs. It runs as you, under the same checks as your clients, and each run is in the audit log. It’s a quick way to see what a tool returns, or why it’s blocked for you.

Clients lists the apps you approved, like Claude or Cursor, and Keys your API keys. Revoke one and it loses access at once. Admins see and revoke everyone’s under Settings → Clients and keys.

Remove someone from the workspace and every client and key they had stops working.

On Enterprise, a workspace can accept gateway calls only from listed IPv4 and IPv6 addresses and ranges, such as an office, a VPN or CI runners. It can cover every client or API keys only. Calls from anywhere else get a 403, and each refusal is in the audit log. The dashboard itself isn’t restricted.

203.0.113.7
203.0.113.0/24
2001:db8:1200::/40

Paid plans are billed monthly per member: everyone in the workspace, invited humans included, is a seat. Owners and admins manage the plan, payment method and invoices under Settings → Billing.

Before any change, Billing shows exactly what it charges or credits. Every invoice is listed there, with a PDF.

MCP1 is SOC 2, GDPR, HIPAA and CCPA compliant. A DPA is available for every workspace, and a BAA on Enterprise.