MCP server

The MetaMonster connector lets Claude work on your site's on-page SEO. Claude can find the pages worth fixing, analyze a page against 40+ factors, write briefs, outlines and drafts, and keep your business facts up to date. It works on the same sites, pages and drafts you see in the app.

The server is a remote MCP server at https://app.metamonster.ai/mcp.

Before you start

You need:

• A MetaMonster account. Sign up at app.metamonster.ai with Google or with an email and password.
• An active subscription, for everything but the quick check and the site list. quick_check_page is free with or without one: give Claude a page's URL, or a draft, and every factor that needs no AI is checked. Every other tool but list_sites needs a subscription, the read-only ones included. Without one, connecting still works, the tools are still listed, Claude is told to start with the free check, and list_sites lists your sites and says the other tools need a plan; every other tool call comes back as a payment_required error naming what needs a plan, the cheapest plan that includes it with its price, a checkout link, and that quick_check_page is free. Nothing is read, changed or charged. Once you subscribe, the same connector or key works at once (see Conventions).

Connect from Claude

This works the same in claude.ai on the web, Claude Desktop and the Claude mobile apps.

1. Open Settings → Connectors (Customize → Connectors in some versions).
2. Browse the connector directory and find MetaMonster.
3. Click Connect.
4. Sign in with your MetaMonster account.
5. Pick the organization to authorize, if you belong to more than one.
6. Approve.

There's no API key to copy or paste. The connector gets its own token and refreshes it.

Add it as a custom connector

If you don't see MetaMonster in the directory, add it by URL instead:

1. Go to Settings → Connectors → Add custom connector.
2. Enter the server URL: https://app.metamonster.ai/mcp.
3. Sign in, pick the organization, and Approve, as above.

Revoke or switch organization

Revoke access anytime from Settings → Connected apps in MetaMonster. Revoking cuts off access immediately.

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

Connect from Claude Code, Cursor or Windsurf

These clients send an API key as a header instead of signing in. Create a key under Settings → API keys in MetaMonster. It's the same mm_ key the REST API uses, sent as a bearer token:

Authorization: Bearer mm_YOUR_API_KEY

There's no separate MCP 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).

Claude Code

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

Cursor / Windsurf

Add to mcp.json:

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

The endpoint is stateless Streamable HTTP. There's no session state, so any request can land on any server instance.

Example prompts

Once connected, ask in plain language. Claude picks the tools.

• "Which pages on my site should I work on first?"
  Claude calls list_sites to find your site, then get_opportunities and lists the pages with the most to gain.
• "Analyze https://example.com/pricing and tell me what's failing."
  Claude calls analyze_page, then shows each factor that fails, the measurement behind it, and the fix that would make it pass.
• "Write a content brief for my page about kitchen remodeling costs."
  Claude calls generate_content_brief for the angle, then generate_content_outline for the sections, and shows you both to edit.
• "Draft a better title and meta description for https://example.com/services."
  Claude calls generate_field_draft for each field and shows the current and proposed text side by side. For a single failing factor it uses draft_fix instead.
• "Find keywords for a new page about emergency plumbing in Denver."
  Claude calls keyword_research and returns keyword ideas with search volume and difficulty.
• "Which queries lost the most clicks this month?"
  Claude calls query_search_console with the query dimension, compare_to: "previous_period" and sort: "clicks_change" ascending, then shows the biggest drops.
• "Add this testimonial to my site facts: 'They fixed our leak in an hour.' (Jane D.)"
  Claude calls add_site_facts, so every later draft for the site can use it.

Start from a page in the app

Every page in the app's page editor has Work on this with your agent in its header. It copies one prompt for any agent connected to the MCP, the Claude app or a coding agent alike. The prompt names the page and what the agent can do with it through the MCP (read its analysis and fixes, push content and drafts into MetaMonster, write or rework the page, publish), and has the agent tell you where the page stands and ask what you want before it changes anything. If you ask it to publish and it has the site's repo open, it applies only what get_page_drafts returns, commits with a MetaMonster-Page: <page id> trailer, then calls mark_page_published with exactly what it applied.

Nothing is published to your CMS from the connector. Drafts, content versions and alt text are saved in MetaMonster, and you review and publish them yourself.

Data and privacy

What the connector reads and writes. Only your organization's MetaMonster data: sites, pages, analyses, fixes, briefs, drafts, business facts and context documents. Every tool works through the v1 API, with the same access rules as the app.

One organization per connection. An OAuth token is scoped to the one organization you approve. Revoke it anytime in Settings → Connected apps.

What it doesn't see. The connector does not read your Claude chats, memory or files. It only receives the arguments of the tools Claude calls, such as a URL or the text of a testimonial, and returns their results.

Logging. Tool calls are logged for reliability and product analytics, tied to your account and organization: the tool name, whether it succeeded, how long it took, and the call's arguments and result. Anything shaped like an API key or access token is removed before it's stored.

AI providers. Briefs, drafts and other generated content are written by AI providers, as described in the privacy policy.

Support

Email support@metamonster.ai.

Tools

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

Every tool returns a short human-readable summary plus a structured JSON payload mirroring the REST data shape (snake_case field names, with the fix vocabulary below). The MCP speaks of factors and fixes: where the REST API says recommendations, tool inputs and results say fixes (fix_id, fixes_status, fix_count).

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

Page writer (internal preview)

Only for organizations with the page writer enabled.

Items (internal preview)

Only for organizations with items enabled. Items are the work in progress on a site: pages being created or updated. An item exists only once work starts; the Playbook is the queue, so to add work without starting it, add an idea with add_content_idea.

Email reports (internal preview)

Only for organizations with email reports enabled. The monthly email report sends a site's performance summary and what to do next to the addresses listed (for an agency, usually its client).

Drift (internal preview)

Only for keys whose user has Drift enabled. Drift finds places where a site contradicts itself or its business facts.

Content ideas

Every account gets these tools.

Factors and fixes

There is one analysis. Every factor passes or fails, with the measurement and the threshold behind it, grouped by area. Each failing factor comes with fixes: the edits that would make it pass.

• analyze_page and get_page_report return a factor table: every factor with its verdict, measurement and threshold, plus the fixes once written. 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, and a no analysis error when the page has none.
• find_pages takes min_factors_passing_pct (0-100) and has_fixes. min_score/max_score filter the opportunity (demand) score.
• get_opportunities rows show factors passing (for example 36/41 factors passing, or not analyzed) and a fix_count. A row's score is the demand rank, not an analysis score.
• get_factors lists every factor that is checked.
• An analysis whose fixes_status is not_requested has findings but no fixes yet: call write_fixes.
• Results use fix vocabulary throughout: fixes, fixes_status, fix_count, fix_id, and error codes such as no_actionable_fixes and fixes_in_progress. The REST API underneath still says recommendations.

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 writes the angle. Review it and edit it with update_content_brief (brief), then generate_content_outline builds the sections from it, and update_content_brief accepts 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. With the page writer, generate_page_draft writes the body, title and meta description for you instead.
5. quick_check_page (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.

Plan content from ideas (preview)

For accounts with the content ideas tools:

1. get_content_playbook to see what to publish next, and get_authority_map for topical gaps and drifting pages.
2. get_content_idea for the one the user picks.
3. For a new page: create_page with the idea's proposed path and keywords, then accept_content_idea with action: "create" and the new page_id, and build it as in Create new content. For a change to an existing page: accept_content_idea with action: "optimize".
4. Only when the user wants the plan refreshed: generate_content_ideas (it updates the current playbook; mode: "rebuild" starts over; it costs money and is capped), then get_content_ideas_status every few minutes until it has succeeded.

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:

• result_too_large means the result would be more than Claude can read in one go (about 120,000 characters). Ask for less: a smaller limit, the next page with offset, or a narrower search or filter.
• payment_required without a plan means the organization has no active subscription. Every tool but quick_check_page and list_sites returns it in that case (list_sites answers, with plan_required: true and a one-line note), with a plain notice in place of the v1 message: what needs a plan for that tool's task, the cheapest plan that includes it with its price and limits (Drift tools: the cheapest plan with Drift), a /pricing?plan=… checkout link, and that quick_check_page is free (offer it on the page the call named, else ask which page). The prices come from the v1 refusal's details.plans. The same facts are in details.paywall (reason: no_plan, task, plan, checkout_url, free_check). Tell the user a plan is needed and share the link, don't retry: calling another paid tool will not help. When the organization has a plan, the same code with details.reason limit_reached (pages or sites used up this period) or not_on_plan (a feature the plan lacks) carries an upgrade link instead.
• 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 50 AI generations for the current analysis (draft_fix and revisions). Re-run the analysis to get a fresh set.
• revision_cap_reached means a draft has been revised 3 times. Accept it and edit the text directly (update_content or set_field_draft), or reject it and draft the fix again.
• generate_content_brief, generate_content_outline, draft_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 its outline, or call draft_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.