Connect your AI agent to Anchor.
One URL. OAuth sign-in. Works with every MCP-compatible agent.
Skip the reading
Give this link to your AI and ask it what you need — it'll read this page and figure out the answer.
What is MCP?
The Model Context Protocol (MCP) is the open standard for AI agent tool use — think "USB-C for AI." It defines how an agent discovers and calls tools on a remote server. Any MCP-compatible agent can talk to any MCP server without custom integrations.
The Anchor MCP server exposes tools covering every action you can take in Anchor: build and edit apps, design and query tables, upload and download files, and organize folders. Your agent calls these tools on your behalf; Anchor handles storage, hosting, permissions, and versioning.
One connection, every agent. No vendor lock-in. No webhooks. No custom integration code.
Supported agents
Anchor works with every MCP-compatible agent. The setup is the same everywhere: paste one URL, sign in, and you're connected. The whole thing takes less than a minute.
We have step-by-step walkthroughs for Claude, Claude Desktop, Claude Code, ChatGPT, Codex, Codex Desktop, Gemini CLI, Open WebUI, and OpenCode — with more agents added regularly.
View all supported agents and setup instructions
Any other MCP-compatible client also works — the server follows the Model Context Protocol spec exactly.
Tool reference
The Anchor MCP server exposes the tools below, grouped by capability. Agents discover the same list at runtime via tools/list.
| Tool | What it does |
|---|---|
| Navigation & discovery | |
list_orgs |
List the organizations the authenticated user belongs to. Returns each org's id, name, and creation timestamp. |
ls |
Inspect an org (lists root folders), a folder (lists its contents), a single file, an app slug, or everything shared with you from outside your orgs. The workhorse of navigation — every returned folder and file includes its owning org_id and org_name, and APP files include published_version and latest_version for use with unpack_app. |
| Files | |
write_file |
Create or edit one or more textable files (HTML, Markdown, JSON, CSV, XML/YAML, source code, etc.) in a single batched call — up to 100 entries, applied in order with per-item results. Supports new-file creation, surgical edits (oldString / newString, optional replaceAll), and full rewrites. HTML is the preferred format for documents and slides — Markdown is for source-style content where structure matters more than layout. Binary document formats (PDF, DOC/DOCX, PPT/PPTX, XLS/XLSX, RTF) are read-only via read_file and cannot be created or rewritten. Also the entrypoint for authoring app source — write the source files into a temp folder, then call build_app. Apps and tables have their own tools — use build_app and query_table for those. |
read_file |
Read a file's textable content. Text-like formats (HTML, Markdown, JSON, CSV/TSV, XML/YAML, plain text, source code) are returned as raw bytes — byte-for-byte identical to what write_file would round-trip, so surgical edits match exactly. Binary document formats (PDF, DOC/DOCX, PPT/PPTX, XLS/XLSX, RTF) are returned as extracted plain text. Supports line-range reads for large files. For tables use describe_table or query_table; for apps use unpack_app. |
file_upload_link |
Generate a deep link to the Anchor UI where the user can manually upload files into a folder. Only applies to files of type OTHER — apps and tables are not uploaded, they are created by build_app and create_table. |
file_link |
Return view and download links for a file of type OTHER. Does not apply to apps or tables — those have their own access paths. |
rm_file |
Delete a file from a private/hidden/temporary folder. This is the only deletion path exposed to MCP agents — deletions in regular folders are user-driven and done through the Anchor UI. Typical use: pruning stale source files from a temp folder before calling build_app. |
| Apps | |
build_app |
Build a new app, or a new version of an existing app, from the source files in a temporary folder. Required files: index.tsx and favicon.json. Optional: index.css, functions.json, other-file-connections.json, plus any helper modules in the same flat folder. New apps land in a destination folder at v1 and auto-publish; new versions are appended to the existing app, and auto-publish when the app isn't shared with anyone else. Returns an app_link for end users and a separate app_management_link for the owner. |
unpack_app |
Copy a chosen app version's source files into a new private/hidden/temporary folder for editing. Defaults to the published version when no version is specified. Pass the folder back to build_app once changes are ready. Also pulls in any OTHER files referenced from other-file-connections.json so the temp folder is fully self-contained. Requires contributor/owner access — app source is not exposed to viewers. |
list_app_functions |
List the callable backend functions an app exposes — each function's name, description, input parameters (inputSchema), return shape (outputSchema), and the tables it reads or writes. |
call_app_function |
Execute one of an app's functions with positional arguments. Returns the result as an array of typed row objects matching the function's outputSchema. Enforces server-side authorization (requireAuth) on parameters tied to the caller's verified email. Prefer this over query_table when an app already exposes a suitable function. |
| Tables | |
create_table |
Create a new table with typed columns (STRING, NUMBER, INTEGER, BOOLEAN, ENUM, DATE, DATETIME, EMAIL, CREATED_BY_EMAIL), uniqueness and required constraints, default values, and optional foreign keys with CASCADE / SET_NULL behavior. Each Anchor table maps directly to a PostgreSQL table. |
describe_table |
Return a table's full column schema, row count, connected apps, and create/update timestamps. Does not return row data — use query_table for that. |
query_table |
Execute a SQL statement (SELECT / INSERT / UPDATE / DELETE) against Anchor tables. Schema/DDL statements (CREATE, ALTER, DROP, TRUNCATE) are rejected — use create_table, add_table_column, and delete_table_column for schema changes. Joins across tables in the same org are allowed. |
add_table_column |
Add a new column to an existing table. Same column schema as create_table. Required columns must include a default value so existing rows can be backfilled; unique columns cannot be required and cannot have a default. |
delete_table_column |
Permanently delete a column and all its data. If apps depend on the column, the deletion is deferred as a pending schema change instead — the table owner must approve it from the table page after the dependent apps are disconnected or updated. The record_id primary key cannot be deleted. |
| Folders & organization | |
mkdir |
Create a new folder at the org root or inside an existing folder. Set private_hidden_temporary to create a flat, agent-only scratch folder for staging app source — invisible in the Anchor UI, holds OTHER files only, and is auto-cleaned after ~24h of inactivity. Use these temp folders to assemble inputs for build_app or to receive output from unpack_app. |
mv |
Move or rename a file or folder within the same org — pass a destination, a new_name, or both. Files cannot live at the org root; folder cycles and over-deep nesting are rejected. Also the canonical way to rename an app. |
cp |
Copy a file into a folder (same org only). Apps get a rebuilt bundle; tables get a fresh duplicate of schema and data; OTHER files clone their content. The copy gets a new ID and the caller becomes the owner — no existing access roles are carried over. |
Authentication & security
Anchor's MCP server uses OAuth 2.0 with PKCE — the same flow Claude, ChatGPT, and other MCP clients already speak natively. No client secrets, no static API keys, no copy-paste tokens.
| Discovery | On first request, your agent fetches /.well-known/oauth-protected-resource and /.well-known/oauth-authorization-server from mcp.anchor.cc to learn where to authorize. |
| Dynamic client registration | Your agent registers itself via POST /oauth/register. No pre-provisioning required. |
| User sign-in | The authorization endpoint redirects to Google SSO. You sign in with the same Google account you use for anchor.cc. |
| Tokens | Access tokens are short-lived JWTs. Refresh tokens rotate on use. Revoke access anytime from your Anchor account settings. |
| Authorization | Every tool call runs as you. Your agent can only see and modify content you have access to — the same permission model used in the UI. |
The server implements the Model Context Protocol OAuth flow as specified by modelcontextprotocol.io — any MCP client that follows the spec will authenticate correctly.
Usage & limits
Each MCP tool call counts against your organization's monthly usage quota. Free organizations start with a generous allowance; paid plans raise the ceiling. See pricing for the full breakdown.
Large reads — such as read_file on long PDFs or query_table on wide tables — count as a single unit regardless of size. Rate limits apply per-token to keep runaway agents from exhausting your quota.
FAQ
Which MCP transport does Anchor support?
Streamable HTTP — the recommended transport for remote MCP servers. Any MCP client that speaks Streamable HTTP over OAuth 2.0 works out of the box. Local stdio transports are not required or supported.
Do I need an API key?
No. Anchor issues OAuth access tokens transparently when you connect your agent. There is no API key to generate, store, or rotate.
Can one agent connection access multiple orgs?
Yes. You authorize once; the agent sees every organization your account belongs to. Use list_orgs to enumerate them and ls to navigate into a specific one.
Can I self-host the MCP server?
Enterprise customers can run Anchor — including the MCP server — under their own domain or inside a managed VPC. Contact us for details.
Where is the full tool spec?
Every tool's input and output schema is served by the MCP server itself — connect your agent and call tools/list to retrieve it. The Tool reference above is the same list in human-readable form.