MCP server

MetaMonster runs a remote MCP server at:

https://new.metamonster.ai/mcp

It's a stateless Streamable HTTP endpoint. There's no session state, so any request can land on any server instance. Authentication is the same mm_ API key as the REST API, sent as a bearer token:

Authorization: Bearer mm_YOUR_API_KEY

There's no separate MCP-specific key or scope model. An MCP call spends the same rate-limit budget and respects the same scopes as the REST call behind it (see Authentication).

The server wraps 43 curated tools over the v1 API (39 for organizations on the new analysis), not a 1:1 endpoint mirror. Each tool is a small workflow step (find pages, stage an edit, resolve a recommendation, run an analysis, generate a brief or a fix) so a chat agent can drive the whole verification loop, and everything the app can generate, without knowing the REST shapes underneath.

claude.ai web and Claude Desktop connect via OAuth, through the custom-connector flow below: sign in, pick the organization to authorize, and approve. Claude Code, Cursor, and Windsurf connect directly with a bearer API key since they support header-based auth on a remote server.

Setup

Claude Code

claude mcp add --transport http metamonster https://new.metamonster.ai/mcp --header "Authorization: Bearer mm_YOUR_KEY"

Cursor / Windsurf

Add to mcp.json:

{
  "mcpServers": {
    "metamonster": {
      "url": "https://new.metamonster.ai/mcp",
      "headers": { "Authorization": "Bearer mm_YOUR_KEY" }
    }
  }
}

claude.ai web / Claude Desktop (OAuth connector)

Both connect the same way, through the custom-connector UI:

1. Go to Settings → Connectors → Add custom connector.
2. Enter the server URL: https://new.metamonster.ai/mcp.
3. Sign in with your MetaMonster account.
4. Pick the organization to authorize (if you belong to more than one).
5. Approve.

There's no API key to copy or paste. The connector flow issues and refreshes its own token. Revoke access anytime from Settings → Connected apps in the app; revoking cuts off MetaMonster API access immediately.

To switch which organization the connector is authorized for, revoke it in Settings → Connected apps, then reconnect and pick the new organization. There's no in-place org switch.

Tools

Every tool returns a short human-readable summary plus a structured JSON payload mirroring the REST data shape (same snake_case field names as the REST API). Organizations on the new analysis get 46 tools: the five checks_* tools are dropped and write_recommendations is added. Everyone else gets 50.

Nothing a tool generates is published to your CMS. Drafts, content versions and alt text are saved in MetaMonster for review.

Find and read

Edit and verify

Plan a new site

For a site that isn't live yet, the same flow as the app's "Plan a site".

Generate

Business facts and the Context Library

Checks engine (preview)

Organizations that are not on the new analysis also get these five tools. They run the checks engine as a separate lineage: no score or grade, and not shown in the app.

New analysis (factors)

Organizations moved to the new analysis (rolled out gradually) see a slightly different tool set and different payloads, with the same REST mapping as the switched endpoints:

• analyze_page and get_page_report return a factor table: every factor with its verdict, measurement and threshold, grouped by area, plus the recommendations once written. There is no score or grade. Passing factors are summarized; pass include_passing: true to list them. analyze_page re-judges content only when it changed (unchanged content spends no allowance), and force re-runs it anyway.
• get_page_report returns the page's latest analysis (404-style no analysis error when the page has none, including a page that only has a legacy analysis).
• find_pages takes min_factors_passing_pct (0-100) in place of grade. min_score/max_score still filter the opportunity (demand) score.
• get_opportunities rows show factors passing (for example 36/41 factors passing, or not analyzed). A row's score is the demand rank, not an analysis score.
• get_rubric returns the factor list instead of components and grade bands.
• write_recommendations is added (see the table). An analysis whose recommendations_status is not_requested has findings but no recommendations yet.
• The checks_* tools (checks_run, checks_analyze_page, checks_get_report, checks_regenerate_recommendations, checks_get_rubric) are not available to these organizations: they are neither listed nor callable. Use analyze_page, get_page_report, write_recommendations and get_rubric.

Everything else is unchanged.

Analyze a URL

analyze_page and get_page_report both accept { url } instead of { page_id }, so a client can hand over a bare URL and get a report back without knowing whether MetaMonster has seen the page before. analyze_page resolves it through three cases:

1. Known page. The URL already resolves to a page. If it has a crawled snapshot, saved body content, or staged field drafts, it's analyzed directly (or its existing report is returned), so a page made with create_page and written with update_content is analyzed without a crawl. A discovered page with none of those is crawled first. A planned or hand-added page with no content returns page_not_live / no_content instead of crawling a URL that may not exist.
2. Known site, unknown page. The URL's host matches an existing site but the path doesn't. The page is created and crawled first, then analyzed.
3. Unknown site. Neither the host nor the path is known. The tool returns site_not_found with a next_step hint instead of guessing. Confirm with the user, then call analyze_page again with create_site: true to add the site (this queues a background discovery crawl of the whole site). Only the one page you asked about is analyzed; site creation never spends extra allowance on its own.

A mistyped URL on a known site creates a page, so confirm uncertain paths with the user before calling analyze_page with a URL. If one slips through, remove it with delete_page.

Only analyze_page will create a site or page on your behalf, and only with explicit opt-in (create_site: true). get_page_report only reads what already exists (returning page_not_found/site_not_found otherwise), and recrawl_page only accepts page_id; it doesn't resolve a URL.

Create new content

To take a content idea from nothing to a reviewed draft without publishing anything:

1. create_page with a working title (the path defaults to its slug, as in the app) and the idea as purpose.
2. keyword_research on a seed keyword, then update_page to save the primary and secondary keywords.
3. generate_content_brief, then update_content_brief to accept sections (their headings go into the body).
4. Write the body with update_content (pass the brief's content_version_id as base_version_id) and the title, meta description and H1 with set_field_draft.
5. run_checks (free), then analyze_page to review the saved content. No crawl is needed.

Plan a new site

To plan a whole site before it exists:

1. plan_site with the user's description of the business. Show them the proposed pages.
2. edit_site_plan to remove, rename, re-slug or add pages, or to regenerate the set from a revised brief.
3. assign_planned_keywords once the user confirms the set. Check on it with get_site_plan if it is still running.
4. Build each page as in Create new content (steps 3-5): briefs, body and fields work on planned pages.
5. When the site is published, go_live_site with its domain. After the crawl, the pages are analyzed like any live page.

Errors

Tool errors carry the same code/message/details as the REST error envelope: payment_required, analysis_in_progress, crawl_in_progress, site_not_found, page_not_found, already_resolved, and so on. A few additions and behaviors are specific to the MCP layer:

• invalid_arguments means the tool call itself was malformed (bad zod input). Fix the arguments and retry.
• generation_cap_reached means the page has used its 15 AI generations for the current analysis (generate_fix and revisions). Re-run the analysis to get a fresh set.
• generate_content_brief, generate_fix and generate_content_draft wait up to ~45 seconds. If the generation is still running, they return status: "processing" with a job_id. Poll it with get_job, then read the result: get_content_brief for a brief, or call generate_fix / generate_content_draft again with the returned action_id / rewrite_id (this resumes the wait and doesn't start a new generation).
• page_not_live / no_content mean analyze_page was asked to analyze a planned (no live URL yet) or hand-added page that has no crawled or saved content. Write the body with update_content (or stage fields with set_field_draft) and analyze again, or, if the page is live, call recrawl_page first.
• analyze_page's crawl and analysis waits share a single ~45-second server-side budget for the whole call (not ~90s per step), so the second wait gets whatever's left after the first. If the budget runs out while a step is still running, the tool returns status: "processing" with a job_id instead of an error. Call get_job to poll it, honoring its retry_after_seconds.

Rate limits are the calling key's normal REST limits (see Conventions). There's no separate MCP-layer limit; each tool call spends the budget of the v1 request(s) it makes underneath.

Local development

Run against a local dev server at http://localhost:3000/mcp with the same bearer auth. The MCP Inspector is the fastest way to poke at it directly:

npx @modelcontextprotocol/inspector

In the Inspector UI, choose transport Streamable HTTP, set the URL to http://localhost:3000/mcp, and add an Authorization: Bearer mm_YOUR_KEY header.