Skip to main content
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. 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 or activating a workspace, 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.

​
What an agent can change or delete

Keep confirmation prompts on for actions that change content, settings, or reusable assets.
Template and voice deletions are permanent. An agent cannot delete a Content Editor over MCP, but it can replace its entire document.
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.

​
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: Read tools then return what was found: Any of that text can contain instructions written for your assistant rather than for you.
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.
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. 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.
Who can connect is on Authentication; what the consent page shows is under What you approve. Credits and limits lists the plans. Client-side controls are where administrators act today: 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.

​
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 lists the refresh action per client, and Changelog records what changed.

​
Protocol support

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