> ## Documentation Index
> Fetch the complete documentation index at: https://devs.surferseo.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Security and admin

> Understand what a connected agent can read, change, and delete, and how to keep confirmations on.

A connected client acts as you inside one Surfer organization and can call every tool from its first request. The per-call review step lives in your client, not in Surfer. Three things follow:

* Check the server address before you install.
* Keep the confirmation prompt on for the tools that overwrite or delete.
* Know what an admin can and cannot control.

## The official endpoint

Surfer operates one server, the one on [Server details](/mcp/authentication#server-details). Before you add Surfer from a marketplace listing, an install link, or a shared snippet, check two things:

* The URL matches the one on Server details.
* The snippet asks for no API key and no custom header. A snippet that asks for either is not Surfer's.

## What connecting grants

The connection is bound to your account and one organization, across every tool.

* The token Surfer issues at authorization is bound to your user account and to the one organization you picked on the consent page. From then on the client acts as you inside that organization.
* Permission checks apply to you, not to the client. A tool that requires an organization owner or admin, such as [creating](/mcp/tools/index#workspaces-and-brand) or [activating a workspace](/mcp/tools/index#workspaces-and-brand), fails for a member.
* The grant covers the whole tool catalog. Every tool, read and write, is available to the client from the first call.

The four scope groups behind the catalog, and how to disconnect or switch organizations, are described on [Authentication](/mcp/authentication).

## What an agent can change or delete

Keep confirmation prompts on for actions that change content, settings, or reusable assets.

| Area | What an agent can change |
| - | - |
| Content Editors | Replace the document body, regenerate an outline, or change the editor's settings. |
| Surfer AI | Generate an article or apply Auto-Optimize changes directly to the document. |
| Brand and guidelines | Update brand knowledge, terms, topics, structure targets, and competitor selections. |
| Templates and voices | Create or update reusable assets, change defaults, and permanently delete assets. |

<Warning>
  Template and voice deletions are permanent. An agent cannot delete a Content
  Editor over MCP, but it can replace its entire document.
</Warning>

The server supplies behavior annotations with each tool so your client can distinguish reads from changes and deletions. Client approval settings determine when you see a confirmation. Some actions also spend credits; see [Credits and limits](/mcp/credits-and-limits).

## Prompt injection

Text that Surfer fetches from the web comes back through read tools, and it can carry instructions aimed at your assistant.

These actions fetch web content:

* [Creating a workspace](/mcp/tools/index#workspaces-and-brand) analyzes the brand site.
* [Creating a Content Editor](/mcp/tools/index#content-editors) analyzes the SERP, and imports a page when you give it a URL to import.
* [Loading more competitors](/mcp/tools/index#guidelines) fetches additional competitor pages.

Read tools then return what was found:

* Competitor titles and URLs, with the [SEO guidelines](/mcp/tools/index#guidelines).
* The imported page, as the [editor's document](/mcp/tools/index#content-editors).
* [AI Search facts](/mcp/tools/index#guidelines), with their source URLs.

Any of that text can contain instructions written for your assistant rather than for you.

<Warning>
  Treat imported pages, competitor content, and other web-sourced text as data,
  never as instructions. Assume nothing removes injected text from a page Surfer
  imported or a competitor it analyzed.
</Warning>

Three habits limit the damage:

* Keep confirmation prompts on for changes and deletions, so a hidden instruction cannot rewrite or delete content without you seeing the call.
* Do not allowlist write tools, even in a client that can allowlist a whole server.
* Be deliberate about which other servers share the session. A client can pass content returned by Surfer to another connected server. A session that also has email, chat, or shell access carries that risk.

## Keep confirmations on

Each client decides when to ask before a tool runs. The table shows where each client's setting lives, so you do not switch the prompt off by accident.

* Claude and the local ChatGPT desktop and Codex clients read the tool annotations and prompt before a tool marked destructive; ChatGPT web prompts before any tool that is not read-only.
* Cursor and VS Code ask before an MCP tool runs until you allowlist it.

Some actions, including creating a Content Editor, spend credits without being marked destructive. Check your client’s approval settings for all write actions if you want to approve spending too.

| Client | Default behavior | Where the setting lives |
| - | - | - |
| Claude (web, desktop) | Read-only tools run without per-call confirmation; destructive tools always prompt. | **Customize → Connectors**, select the connector, set a tool to **Blocked**. Team and Enterprise owners set **Always allow**, **Needs approval**, or **Blocked** per tool. |
| ChatGPT web | Write actions require confirmation; a tool without `readOnlyHint` counts as a write. | The confirmation dialog; a remembered choice lasts one conversation. |
| ChatGPT desktop (Work) and Codex | A destructive-annotated tool always requires approval; `default_tools_approval_mode = "writes"` also prompts for anything not marked read-only. | `[mcp_servers.surfer]` in `config.toml`, per tool under `tools.<tool>.approval_mode`. |
| Cursor | Asks before using any MCP tool. | The approval card; the arrow next to the tool name shows the arguments. |
| VS Code | The Default Approvals level shows a confirmation dialog for one use, the session, the workspace, or always. | **Chat: Manage Tool Approval** per tool or per server. |

Allowlisting read-only tools costs nothing: they change no data and spend no credits. Keep the prompt for the rest.

## What an admin controls

Access follows the plan. An administrator's controls live in the client, not in Surfer.

On the Surfer side there is:

* No separate switch to allow or deny MCP for an organization.
* No list of connected clients or of the members who have connected, and no revoke button; disconnecting happens in the client, as described on [Authentication](/mcp/authentication#disconnect-or-switch-accounts).

Who can connect is on [Authentication](/mcp/authentication#who-can-connect); what the consent page shows is under [What you approve](/mcp/authentication#what-you-approve). [Credits and limits](/mcp/credits-and-limits) lists the plans.

Client-side controls are where administrators act today:

| Client | What an administrator controls |
| - | - |
| Claude Team and Enterprise | Only Owners can add a custom connector ([Claude setup](/mcp/connect/claude#team-and-enterprise)). Owners can set per-tool permissions for members. |
| Cursor, Codex | Allowlist or block MCP servers by URL. |
| VS Code | Turn MCP off entirely, or restrict which MCP servers members may use. |

A server that never appears for a member may be policy rather than a network fault.

## What Surfer records

Surfer records which tools were called and by whom. The MCP server sends no tool arguments or document content to its own error reporting or analytics; its requests to Surfer's backend are logged like any other API request.

* Every call is recorded with the tool, the user, the organization, the client, the outcome, and the duration.
* Unexpected failures are sent to error reporting with the tool name, the client id, and an id for your account.

Retention follows the [privacy policy](https://surferseo.com/privacy-policy).

## Tool payloads are not a compatibility surface

Tool inputs and outputs may change shape without versioning or a deprecation period.

Fields can be added, removed, renamed, or given a new meaning, as long as the description and output schema served with the tool stay accurate. This is deliberate: your assistant reads the tool list live at the start of each session and interprets responses through it, so nothing durable binds to a payload shape.

A session that started before a change can hold a stale tool list until you refresh it. [Troubleshooting](/mcp/troubleshooting) lists the refresh action per client, and [Changelog](/mcp/changelog) records what changed.

## Protocol support

The server is a stateless Streamable HTTP endpoint that exposes tools only.

| Area | What the server supports |
| - | - |
| Transport | One Streamable HTTP endpoint; the URL and what it accepts are on [Server details](/mcp/authentication#server-details). No SSE transport, and no way to connect over stdio. |
| Session state | None. Each request carries everything the server needs. |
| Primitives | Tools only. No MCP resources, prompts, tasks, elicitation, or sampling. |
| Progress | Long-running tools send progress notifications when the client asks for them, as [Timeouts and long-running tools](/mcp/credits-and-limits#timeouts-and-long-running-tools) describes. |
| Protocol versions | 2025-03-26 through 2025-11-25 are accepted, and the server answers with the version the client requested. A client on an older version connects but misses features the newer schema adds, such as structured output. |
| Authentication | OAuth 2.1, with the metadata the server publishes on [What the server supports](/mcp/authentication#what-the-server-supports). |


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.