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 239 tools, grouped by the part of Modulify they touch:

  • Workspaces: read your workspaces, your role in each, your AI credit balance and what the credits were spent on, down to each charge.
  • Sites: list, create, duplicate, rename, archive and unarchive, 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, start a build through a deploy hook.
  • Domains: add custom domains, up to 10 for each site, read their DNS records, verify them, remove them.
  • Configuration: environment variables, the skills and connectors a site uses, scheduled jobs, webhooks and deploy hooks with their logs and their counts over time.
  • Emails: the transactional email a site sends, its settings, its allowance, its history with any one email read in full, its counts over time and the addresses it is blocked from emailing, plus sending one email the person asked for, and the domains of your own it sends from and receives at.
  • 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 backup can also be browsed, read one text file at a time and restored, whole or in part, in two calls: the first answers the plan and changes nothing, and only a second carrying that plan's confirm value starts the restore. A database backup can never be browsed or restored, and neither kind can ever be downloaded through MCP.
  • Analytics: visitor numbers for a published site, the whole Analytics tab in one call, the collection status, and the analytics API key.

All tools lists every one of them, and each tool has its own page with the scope it needs and every input it takes.

Every tool is also a plain HTTP method. A script or a backend of your own can call it with the same token as POST https://api.modulify.ai/v1/<tool> with the inputs as a JSON body, under the same scopes and workspace rules. See the HTTP API.

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. Over the HTTP API, calling a tool outside the token's scopes is refused with a 403 that names the scope it needs.

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, DATABASE_TOKEN, the storage keys, the email keys and the analytics 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.
  • Deploy hook URLs stay masked. list_deploy_hooks and export_deploy_hooks show only the last four characters of the secret part, and create_deploy_hook does not return the URL at all. Reading or rotating one takes get_deploy_hook_url or rotate_deploy_hook_url and the credentials:reveal scope, because anyone holding the URL can publish the site. A hook URL saved as a scheduled job's request URL is hidden too: list_site_crons, list_site_cron_runs and export_site_crons return its secret part as mdh_<redacted>.
  • 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 and DATABASE_TOKEN are 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, counting its calls over MCP and through the HTTP API together. 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