Modulify
Dashboard

What is MCP

Modulify runs an MCP server, so an AI client can work on your sites for you.

On this page

MCP, the Model Context Protocol, is the standard way an AI client talks to an outside system. Modulify runs an MCP server, so a client like Claude Code, Claude Desktop or Cursor can connect to your Modulify account and work on your sites from wherever you are already working.

The mental model

Your AI assistant becomes a client of your Modulify workspace. It signs in with an access token you create, and from then on it can call Modulify the same way you would click through the dashboard: list your sites, send a prompt to one, watch the build, read the resulting code, publish it.

The token is the whole boundary. It belongs to you, it acts as you, and it can only do the things you ticked when you created it.

What a connected client can do

The server exposes 180 tools, grouped by the part of Modulify they touch:

  • Workspaces: read your workspaces, your role in each and your AI credit balance.
  • Sites: list, create, duplicate, rename, delete, change the free address, change sharing.
  • Chat: send a prompt to the site agent, poll the generation, read the history, manage the queue.
  • Code: list, read and write the source files of a site, and read its server logs.
  • Publishing: publish, check the publish, list past publishes, take a site offline.
  • Domains: add a custom domain, read the DNS records, verify it, remove it.
  • Configuration: environment variables, scheduled jobs and webhooks.
  • Content: the collections, schemas and rows of a site database, SQL against it, plus its file storage.
  • Backups: project snapshots, the code backup history, and storage and database backups, which a client can list, take, delete one or all of, and turn the daily run on or off for. A storage or database backup can never be downloaded or restored through MCP.
  • Analytics: visitor numbers for a published site.

Tools lists every one of them with its inputs.

Scopes decide what the client even sees

A token carries a list of scopes. When a client connects, Modulify builds the tool list for that token alone: a tool whose scope the token does not hold is never registered, so the client cannot see it, cannot call it and will not try. Untick data:write and the client behaves as though row editing does not exist.

Each tool is also registered with a read-only hint and a destructive hint. Clients that surface those hints will ask you before running something marked destructive, such as delete_site or clear_collection.

It acts as you, inside your permissions

A token is tied to your user account, not to a workspace. By default it can reach every workspace where you are a member and your role allows API access, and you can narrow it to specific workspaces when you create it.

Every call has to resolve to a workspace, from the workspaceId it names or from the workspace that owns the site it names, and one that resolves to neither is refused before it runs. That workspace then has to be one the token is allowed to reach, and your role in it has to hold the API access permission. Workspace owners hold it already. For anyone else it is a permission the owner grants to a role, described in the product as "Reach this workspace with a token from an AI client".

What it deliberately cannot do

Some things are withheld on purpose, and the riskiest work sits behind scopes that stay unticked until you tick them:

  • Environment variable values stay hidden. list_secrets gives names and flags only. Reading a value back takes get_secret or get_all_secrets and the separate credentials:reveal scope. get_all_secrets leaves the platform-managed rows out, so DATABASE_URL and the storage keys come back only from get_secret, one at a time.
  • Webhook destination URLs are stripped to their host, because a webhook URL is itself a credential.
  • The data tools never return database credentials. get_site_database tells you whether a database exists, whether it is running and which engine it runs, not how to connect to it, and create_site_database returns no more. The stored DATABASE_URL is reachable only through get_secret, so credentials:reveal is the whole boundary here.
  • Writing a file skips the site agent. write_file, behind its own code:write scope, replaces files straight in the running preview, with no review and no code backup taken first. For a change that depends on the surrounding code, the client describes it with send_message and the site agent edits it instead.
  • Running SQL has its own scope. execute_sql, behind data:sql, runs any statement it is sent, including one that drops a table.

Credits and cost

Reading costs nothing. send_message and create_site spend AI credits from the workspace that owns the site, exactly as prompting from the dashboard does. A workspace with no AI credits left refuses both rather than running them part of the way, so a client that checks get_workspace first can tell you before it tries.

Limits

A token may make 240 tool calls per minute. Past that, calls come back with the number of seconds to wait, and the window is per token rather than per account.

A single tool result is capped at 60,000 characters. A larger result is cut off with a note saying so, which is why the paging tools exist: list_rows, list_sites, list_messages and the rest all page.

Next