Connect your coding agent

If you (or your agency) already manage your website with a coding agent such as Claude Code, Pinnacles can hand that agent your recommendations and take back a report of what it applied. The agent edits your site, in your own repository, on your own machine, under your review.

Nothing in this server can write to your site.

We hold no credentials for your site, and the only things the agent can change on our side are the status of a recommendation, the note of what it applied, its reason when it dismisses one, and, for a new page, the URL the page went live at.

Who can use it

The MCP server is on the Pro plan. Any MCP client that can send an Authorization header works: Claude Code, Cursor, VS Code, Windsurf, Cline, Zed, Gemini CLI, or an agent built on an MCP SDK. Browser chat apps that only take a URL (claude.ai, Claude Desktop connectors) are not supported yet.

Connect in three steps

In your dashboard, open Settings and find the card Agent access (MCP). Enter a name for the connection (for example "my laptop") and choose Create connection.
Copy the .mcp.json block or the Claude Code one-liner the card shows. The token starts with pmcp_ and is shown once; if you lose it, revoke the connection and create another. The card shows the server URL. The one-liner looks like this:
```
claude mcp add --transport http pinnacles <server URL> --header "Authorization: Bearer <token>"
```
Optional but recommended for Claude Code: install the Skill.
```
claude plugin marketplace add pinnacles-ai/skills && claude plugin install pinnacles@pinnacles
```
The Skill is a procedure for the apply loop. It is loaded only when relevant and adds no tools.

Revoking a connection in the same card stops that agent within five minutes.

What your agent can see

list_sites — the sites on your account (one today).
get_recommendations — every open recommendation your dashboard shows (status ready or approved), with the one exception below. Each item has the page URL, priority, why it matters, and a list of changes. Each change says what kind of edit it is (set, append, remove, or procedure for work that is not a single value), where on the page it belongs, the current and suggested values where we have them, framework-neutral steps (guidance.how) and warnings (guidance.caveats), and what we will check afterwards (verify). Recommendations about Google Business Profile, reviews or your business listing are flagged off_site: true; the agent should hand those to you rather than try to do them. If we have no steps for a change yet, guidance is null and the agent should show you the recommendation instead of skipping it.
get_drafted_content — the full drafted value when it is too large to inline (schema JSON-LD, robots.txt rules; items with value_inline: false).
verification_status — what our re-check of your live pages found for each applied recommendation (see "When to check back" below).

Core Web Vitals recommendations are not served, and the backlog rows the dashboard does not show are not served either.

What your agent can report back

mark_applied — marks a recommendation done and records what was actually written, per change target. That is what the agent wrote, not what we drafted: the agent may adapt our wording to fit the page, and we verify against the live page, not against our draft. For a new-page recommendation it must pass the URL the page went live at, on your own domain. In the dashboard the action shows Applied by your agent, and you can undo it with Mark as not done. There is no "roll back" for agent-applied changes because we did not make the edit; undo it in your repository.
dismiss_recommendation — declines a recommendation with a reason. The dashboard shows Your agent dismissed this with the reason, and you can restore it. We read these reasons; they are the best signal we get about where a recommendation is wrong for your site.

The agent cannot approve, cannot change what we recommend, cannot mark anything verified, and cannot touch your site through us.

When to check back (verification)

After mark_applied, the recommendation is pending. Every two hours we re-fetch the live page and check whether the issues that recommendation was raised for are gone.
The quiet period is site-wide. We do not start checking until two hours have passed since the most recent recommendation was marked done on the site, by your agent or in the dashboard. If your agent applies ten recommendations over an hour, nothing is checked until two hours after the tenth, and pending during that time means "not checked yet", not "failed". Verdicts usually land within about two to four hours after the last mark_applied (two hours quiet, then the next scheduled pass).
The four verdicts: verified (the issues are gone), not_detected (an issue is still on the page, or we couldn't load the page; we retry once, 24 hours later, then leave it), pending (not checked yet), and skipped (we cannot check this kind of change, for example hosting or certificate work, so it is done when you say it is).
observations: when the applied value fixed our issue but introduced another on the same surface (a title that now runs too long, for example), we list it under the verdict so the agent can fix it on its next pass. No new recommendation is created.
If a recommendation ends not_detected after the retry: fix the page, click Mark as not done in the dashboard (this clears the retry state), and have the agent call mark_applied again.

Partial applies are fine

If the agent applied two of three changes, it should report exactly those two. The recommendation completes, the verdict will be not_detected until the rest is done and re-reported, and the record of what was touched is kept. Do not loop on a partial apply; finish it or leave it.

If something fails

The agent sees a 403 with This token was revoked or Your plan does not include MCP access. Per-connection rate limiting returns 429 if an agent loops. Questions? Write to support@pinnacles.ai or see our contact page.

Connect your coding agent

Nothing in this server can write to your site.

Connect in three steps

In your dashboard, open Settings and find the card Agent access (MCP). Enter a name for the connection (for example "my laptop") and choose Create connection.

Copy the .mcp.json block or the Claude Code one-liner the card shows. The token starts with pmcp_ and is shown once; if you lose it, revoke the connection and create another. The card shows the server URL. The one-liner looks like this:

claude mcp add --transport http pinnacles <server URL> --header "Authorization: Bearer <token>"

Optional but recommended for Claude Code: install the Skill.

claude plugin marketplace add pinnacles-ai/skills && claude plugin install pinnacles@pinnacles

The Skill is a procedure for the apply loop. It is loaded only when relevant and adds no tools.

Revoking a connection in the same card stops that agent within five minutes.

What your agent can see

list_sites — the sites on your account (one today).

get_recommendations — every open recommendation your dashboard shows (status ready or approved), with the one exception below. Each item has the page URL, priority, why it matters, and a list of changes. Each change says what kind of edit it is (set, append, remove, or procedure for work that is not a single value), where on the page it belongs, the current and suggested values where we have them, framework-neutral steps (guidance.how) and warnings (guidance.caveats), and what we will check afterwards (verify). Recommendations about Google Business Profile, reviews or your business listing are flagged off_site: true; the agent should hand those to you rather than try to do them. If we have no steps for a change yet, guidance is null and the agent should show you the recommendation instead of skipping it.

get_drafted_content — the full drafted value when it is too large to inline (schema JSON-LD, robots.txt rules; items with value_inline: false).

verification_status — what our re-check of your live pages found for each applied recommendation (see "When to check back" below).

Core Web Vitals recommendations are not served, and the backlog rows the dashboard does not show are not served either.

What your agent can report back

mark_applied — marks a recommendation done and records what was actually written, per change target. That is what the agent wrote, not what we drafted: the agent may adapt our wording to fit the page, and we verify against the live page, not against our draft. For a new-page recommendation it must pass the URL the page went live at, on your own domain. In the dashboard the action shows Applied by your agent, and you can undo it with Mark as not done. There is no "roll back" for agent-applied changes because we did not make the edit; undo it in your repository.

dismiss_recommendation — declines a recommendation with a reason. The dashboard shows Your agent dismissed this with the reason, and you can restore it. We read these reasons; they are the best signal we get about where a recommendation is wrong for your site.

The agent cannot approve, cannot change what we recommend, cannot mark anything verified, and cannot touch your site through us.

When to check back (verification)

After mark_applied, the recommendation is pending. Every two hours we re-fetch the live page and check whether the issues that recommendation was raised for are gone.

The quiet period is site-wide. We do not start checking until two hours have passed since the most recent recommendation was marked done on the site, by your agent or in the dashboard. If your agent applies ten recommendations over an hour, nothing is checked until two hours after the tenth, and pending during that time means "not checked yet", not "failed". Verdicts usually land within about two to four hours after the last mark_applied (two hours quiet, then the next scheduled pass).

The four verdicts: verified (the issues are gone), not_detected (an issue is still on the page, or we couldn't load the page; we retry once, 24 hours later, then leave it), pending (not checked yet), and skipped (we cannot check this kind of change, for example hosting or certificate work, so it is done when you say it is).

observations: when the applied value fixed our issue but introduced another on the same surface (a title that now runs too long, for example), we list it under the verdict so the agent can fix it on its next pass. No new recommendation is created.

If a recommendation ends not_detected after the retry: fix the page, click Mark as not done in the dashboard (this clears the retry state), and have the agent call mark_applied again.