MCP access. Connect your own agent to EnterraHost data.

What this is

The data source, not the driver.

EnterraHost exposes your monitoring and SEO data through the Model Context Protocol (MCP). Your agent connects to that endpoint, discovers the available tools, and asks for the properties, audits, findings or history it needs. EnterraHost does not run the agent, choose its changes or receive its credentials.

Read this first

The key cannot change your site. If your site changes, your agent changed it.

That sentence is the whole arrangement. The MCP key is a read-only credential that answers questions about data EnterraHost already holds. It has no file access, no database access, no SSH, no control panel, no ability to publish, and it cannot start a scan or spend credits. Anything that edits your site happens through whatever access you give your agent, and that access is between you and your agent.

What we can see. That a key was used, when, from which address, and whether the call was accepted or refused.
What we cannot see. What your agent did with the answer. If it edited a template with credentials you gave it, that change is invisible here. Your own version control is the record.
Who rolls back. You do. We restore a hosting backup when asked, and we do not reach into an application to undo an agent's edit.

EnterraMon data

Uptime, regional response times, SSL and domain expiry, daily audit scores, Core Web Vitals, security headers, accessibility findings and the latest recommendations.

EnterraSEO data

Crawl findings, page snapshots, technical on-page checks, keywords and rankings, content gaps, Search Console and Analytics summaries, backlinks, competitors and answer visibility where your plan includes them.

Separate from site access

The MCP key never grants file, database, SSH or control-panel access. Giving an agent access to the actual site is a second, optional decision with its own safeguards.

Before you start

What you need.

An active EnterraMon or EnterraSEO product. The key menu appears only when one of them is active on your account. If you have both, one key can read both.
An MCP-capable agent. It needs to support a remote MCP server over Streamable HTTP, or a local bridge that can reach one. The exact menu name differs by client. Look for “MCP”, “remote server”, “HTTP” or “connectors”.
The MCP endpoint. EnterraMon uses https://mcp.enterrahost.com/enterramon/mcp and EnterraSEO uses https://mcp.enterrahost.com/enterraseo/mcp. The endpoint is not the key, and it is not your website address.
A plan for changes. A backup, a repository or another rollback point, and a staging copy if you want the agent to do more than read.

The key is read-only. It cannot edit a page, create a backup, trigger a crawl or start a paid check. It can only read data that your active products already hold. Your agent may still be able to change your site through a different credential, that is the separate decision covered below.

Step one

Create a key.

Sign in at toolbox.enterrahost.com, open Account settings, then Agent access.

Choose Create agent key.
Give it a name you will recognize later, such as the agent or machine that will use it.
Copy the key immediately. It is shown once and cannot be revealed again.
Store it in your agent’s secret or environment store, not in a prompt, a document, a screenshot or a support ticket.
If it is exposed, revoke it in the same panel and create a replacement.

The key list shows the product access it carries. If a product is canceled, that access stops on the next check. The key itself is not a permanent grant. If you have both products, the panel shows both, and you can still use one key.

Step two

Connect your agent.

The shape is the same in every MCP client. It needs a server URL, a transport and an authorization header. The screens differ. The values do not. There is one URL per product, so add both entries if you have both products.

{
  "mcpServers": {
    "enterramon": {
      "type": "http",
      "url": "https://mcp.enterrahost.com/enterramon/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_CUSTOMER_KEY"
      }
    },
    "enterraseo": {
      "type": "http",
      "url": "https://mcp.enterrahost.com/enterraseo/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_CUSTOMER_KEY"
      }
    }
  }
}

Use those endpoints and your customer key. Do not commit the key to a repository. If your client only opens a browser window, use its “remote MCP” or “connector” flow and paste the URL and key there. If your client only supports local commands, ask EnterraHost support for the current bridge.

Check that it connected

Ask the agent to list its EnterraHost tools, or to call enterramon_list_properties / enterraseo_list_properties. A successful call returns your properties. A 401 means the key is wrong or revoked. A 403 means the key does not have that product. No tools at all usually means the endpoint or transport is wrong, not the data.

What the errors mean

isError with reason: "invalid_arguments" means the tool arguments are invalid. The message names the field and the rule it broke. The underlying protocol code is -32602.
-32601 means the tool or method does not exist. Call tools/list for the exact prefixed names.
isError with reason: "not_attached" means the domain is not attached to this key.
isError with reason: "inactive" means the property is attached but switched off. Use the product's list_properties with includeInactive: true to see it.
isError with reason: "page_not_found" means the URL is not in the latest crawl for that property.
isError with reason: "property_not_crawled" means the property has no crawl yet.

Step three

Tell your agent how to behave.

Your agent does not know your risk tolerance. Give it this brief before the first real task. It is deliberately explicit about evidence, backups and stopping.

You are working on YOUR_DOMAIN using EnterraHost MCP data.

Treat EnterraHost MCP as the source of measured data, not as a suggestion engine.
1. Start with the property list, then read the overview, latest audit, findings,
   performance and recommendations for the domain. Use the action plan and fix
   runbook when they are available. Check the audit date, age and whether it is
   scheduled or on-demand. If it is on-demand, stale or past the expected cadence,
   tell me before acting and ask for explicit permission.
2. Use exact values from the tools. Say which tool and date each number came from.
   Separate measured facts from your own inference. If a metric is missing, say so.
3. Never invent a keyword, ranking, score, crawl result or traffic figure.
4. The MCP key is read-only. If you also have access to the site, start read-only:
   compare the finding with the actual page, template, server config or CMS record.
5. Before any production change: take a restorable database and file backup, prove
   the restore path, create a Git branch or tag, and record the current values.
6. Put the change on staging or a preview first. Show me the exact diff and the
   verification you will run. Do not batch unrelated changes.
7. Do not edit theme/plugin code, update plugins, change DNS, touch payments or
   authentication, run arbitrary shell commands, or delete pages without my explicit
   approval. Do not put credentials in a prompt or a document.
8. Apply one change set at a time. Verify the result against the baseline. If a
   stop condition occurs, roll back and tell me what failed.
9. Finish with: what changed, where, before/after evidence, what you verified, and
   the backup id or commit to roll back to. If you changed nothing, say that.

Add your own constraints. A maintenance window, a list of pages that must not change, the staging URL, the backup command, or the person who approves production. The more specific the route, the less the agent has to guess.

How it queries

What the agent actually sees.

The agent discovers tools through MCP, then calls them by name. You do not have to list every tool in the prompt, but you should know the shape of the answer.

1. enterramon_list_properties / enterraseo_list_properties
   → the domains this key can read

2. enterramon_get_status / enterraseo_get_overview
   → is it up, how fast, what is the latest score and finding count

3. enterramon_get_latest_audit / enterraseo_list_findings
   → the measured issues, evidence and fixes

4. enterramon_get_performance / enterramon_get_uptime
   → the trend, not just today's number

5. enterramon_get_recommendations / enterraseo_build_action_plan
   → a ranked list, with the data behind each item

6. enterramon_get_fix_runbook / enterraseo_get_fix_runbook
   → backup, repository, staging, approval, verification and rollback

EnterraMon answers availability, speed, security, accessibility and daily-audit questions. EnterraSEO answers crawl, page, keyword, content-gap, backlink, competitor and answer visibility questions, within the products you have. Both are read-only and sequential. The agent can ask for a 30-day or 90-day window, but it cannot make a new crawl happen.

Data is a snapshot. EnterraMon measures daily. Its weekly and monthly PDF reports are built from those daily rows, not from separate scans. EnterraSEO runs its weekly and monthly passes on its own schedule. If a check has not run yet, the honest answer is “not available yet”, not an estimate. The tools report the date they are reading and label each audit as scheduled or on-demand. More than one on-demand test can share a date, so the audit history is a list, not one row per day. The newest row is the current snapshot. Older rows are history for trends, not current state. All timestamps are UTC unless a date is shown. If the latest row is on-demand or stale, the agent must tell you what is old or unscheduled and obtain explicit permission before acting on it.

The bigger decision

Should the agent have access to the actual site?

This is separate from the MCP key, and it is the part that can break something. The useful answer is yes, with caution, in stages, not “give it the hosting login”.

MCP data tells the agent what is wrong. The site tells it why. A finding that says “title is missing” is useful. Reading the template, the CMS field, the redirect rule or the server config is what lets the agent make a correct change instead of a plausible one. That is why connecting the two is valuable. It is also why the access needs to be narrower than the person doing the work.

Stage 1. Data only

The agent reads EnterraHost data and produces a report, a plan or a patch. You apply it. This is the lowest-risk starting point and it is enough for most audits.

Stage 2. Read-only site

The agent can read the repository, a staging copy, the CMS export or the server response. It can compare the data with reality, but cannot write. Use a separate read-only account.

Stage 3. Staging writes

The agent edits a staging site or a branch. You review the diff and the verification before anything reaches production. This is where most safe automation should sit.

Stage 4. Production writes

Only with a backup, a rollback point, human approval and a narrow operation set. Start with titles, descriptions, alt text, schema, canonical, robots.txt and llms.txt.

If you give it site access

The one arrangement that makes this safe

Put the site in a Git repository, and let the agent change nothing outside it. That single decision turns every agent mistake into a revert. The file it edited is a commit with a diff you can read, and the version before it still exists. Without a repository, the only record of what changed is the current content of the file, and the only rollback is whatever backup you remembered to take.

The repository is the rollback point. One commit per change, written by the agent and reviewed by you, so undo is git revert rather than a restore from a tarball.
The database is not in the repository. Content in a CMS lives in MySQL, so a repository protects the code and a backup protects the content. You need both, and the agent should take the backup before it starts rather than after.
Uploads are not in the repository either. Images and documents a customer added belong in the backup, not the commit.
Tell the agent to commit first and report the diff. A prompt that says "make the change, commit it, and show me the diff before you push" is worth more than any permission setting, because the diff is where you catch the forty things you did not ask for.

Use a separate identity. A deploy user or CMS account for the agent, not your personal login and not root. Grant only the permissions the task needs.
Start read-only. Repository read, SFTP read, a read-only database user, or a staging site. Do not begin with write access to production.
Use a branch, merge when you approve. The agent works on a branch and you merge it. Never force-push shared history, because that is the one operation that destroys the rollback point the repository exists to provide.
Version control is not optional. A repository with the change committed before it reaches production gives you a diff and a revert. An agent editing live files through SFTP gives you neither, and the only record is the file's current content.
Test the rollback before you need it. Restore a file, then a database, on staging. A backup that has never been restored is a hope, not a rollback point.
One site, one change, one review. An agent asked to "fix the SEO" will touch forty things. Narrow it to a page or a template, read the diff, then let it continue.
Keep the MCP key read-only and separate from the deploy credentials. If the two live in the same variable, a key that leaks is also a key that writes.
Back up before the first change. Database and files, stored off the target host. Test the restore once. An untested backup is not a rollback plan.
Use staging first. Compare the rendered page, HTTP status, title/meta, schema and Core Web Vitals. A diff is not a verification.
Rotate and revoke. Site credentials are more powerful than the MCP key. Use a secret manager, an IP allowlist where possible, and remove access when the task ends.
Never paste credentials into the prompt. The agent should read them from its own environment or secret store. A credential in a chat transcript is a credential leaked to every log and model in the path.

Do not give an agent the hosting control panel, root SSH, DNS, payment or authentication access for a content fix. If the task needs those, it is no longer a content fix. Stop, narrow the request, and have a person make that change.

Platform notes

WordPress. Prefer a Git-managed deployment and WP-CLI. Back up with wp db export and an archive of the changed files. Read content through the REST API or WP-CLI. Flush caches after a change. Do not let an agent edit theme or plugin PHP unless that code is in a repository and on staging first.

Joomla. Use a staging copy, a versioned template override and a database backup. Keep the database prefix and configuration out of the prompt. Do not let an agent install extensions or edit core files to solve an on-page finding.

Custom PHP and ASP.NET. Work through the existing repository and deployment pipeline. Use a staging slot or preview environment, environment variables for secrets, and a rollback deployment. Do not let the agent change production configuration or connection strings to fix a page title.

Static sites. A branch, a commit and a preview deployment are the whole safety model. The agent can change content and markup in the repository. The pipeline does the rest.

The change loop

Observe. Read the MCP finding and the actual page or template. Confirm the finding is still present.
Plan. Write the exact change, the target, the risk and the verification.
Back up and branch. Database and files, off-host, plus a Git branch or tag. Record the ids.
Stage. Apply one change set. Compare the rendered page and the measurements.
Approve. A person approves production, with the diff and rollback in front of them.
Apply. One change set at a time. No unrelated cleanup in the same batch.
Verify. Re-crawl, re-check status, title/meta, schema, CWV and the original finding. Search Console and rankings are slower. Say when to look, not that they are fixed.
Roll back if verification fails. Restore the backup or revert the commit, purge caches, and re-check before trying again.

Practical notes

What to expect, and what to check.

401 or 403. A 401 means the key is wrong, revoked or missing from the header. A 403 means the key is valid but that product is not active. Check the toolbox first. Do not create a second key to “fix” a scope problem.

The connection is refused before the key is checked. That is the gateway rather than your agent. The status page carries EnterraMon MCP and EnterraSEO MCP as separate components, so a failure there names the product and saves the guess.

No properties. The key is customer-scoped. If the product is active but the domain is not attached, the MCP tools have nothing to return. Add or verify the site in the product, not in the agent.

Stale data. The tools read the latest stored check. They do not trigger a new scan. If you need a fresh run, use the product’s own on-demand scan or wait for the schedule. Do not ask the agent to invent one.

The key was exposed. Revoke it in the toolbox immediately and create a new one. Rotating the site credentials is separate and may also be necessary if those were exposed.

The agent wants more access. Narrow the task instead. A content fix does not need shell, DNS or billing access. If the request cannot be done with read-only data and a staging copy, it needs a person, not a bigger permission.

Machine-readable details are at auth.md, MCP manifest and the server card.

Open the toolbox Download the Markdown guide Ask support