Skip to content

MCP

Tell Claude Code on your laptop, "Ask my research agent what we decided about pricing," and it asks Player One over MCP and shows you the answer. Tell one of your agents, "Use our ticket service to find the open tickets for the Halton account," and it calls that service's tools over MCP. MCP is a common way for AI tools to talk to each other, and Player One uses it in both directions.

Player One is the one you run. Everything you connect it to is what it teams up with: another person's Player One (Share an agent), a coding agent doing a big job (Hand big coding work to a coding agent), or a tool or service you reach over MCP, which this page covers.

Other tools driving your Player One

Claude Code, Codex, Cursor, VS Code and any other tool that speaks MCP can reach your installation at one address, with one key. Through it the tool can read your agents' chats, talk to your agents, answer the decisions waiting for you and search what Player One knows. What it may do is set on its key:

  • Read. See your agents, your chats and the decisions waiting for you, and read the messages your agents leave for it.
  • Chat. Start a chat with an agent and add messages to chats.
  • Decide. Answer the decisions waiting for you. A plain notice from an agent is not a decision, so it is not listed.
  • Notify. Send you a notification.
  • Memory. Search and read what Player One knows.
  • Owner. Off unless you turn it on, and it needs Chat. Your agents then treat the tool's messages as yours, owner-only tools included. Turn it on only for a tool you trust as yourself.

The first five are on when you make a key. A tool sees only the actions its key allows.

The tool speaks as itself. It appears in Manage > Contacts (/manage/contacts) as an agent of its own, named after its key, and its messages show as its own and never as yours. A key is not limited to one project: within its permissions it reaches the whole installation.

Work can flow the other way. Ask an agent, "When the build fails, tell my Claude Code," and the agent leaves a message for that tool. Player One never starts a tool or pushes to one, so the message waits until the tool next looks. You start the tool and tell it to watch. Your replies to a notification reach it the same way, as a message it reads when it looks.

You make the key on Admin > Communications > MCP (/admin/mcp), which also gives each tool its setup. Keys are listed and revoked on the MCP tab of Admin > Security > API keys (/admin/api-keys/mcp). Connect Claude Code, Codex or another tool to Player One has the steps.

Services your agents reach over MCP

  • You say: "Connect the MCP server at https://mcp.example.com/mcp so the ops agent can use it."
  • Player One does: adds the server to its settings. Its tools join the agent's own on the agent's next run, normally with no restart.
  • You see it: the agent using those tools in its replies.

A server is one of two kinds. A local server is a program your installation starts and talks to. A remote server sits at a public web address, and Player One reaches only public addresses: not the computer your installation runs on and not your local network. Player One does not follow redirects.

A server's entry cannot hold a key, a password or an authorisation header, and Player One refuses one that tries. A server that needs one of those is not one you can add this way.

A server can also offer prompts, which are its makers' written guidance for a task with its tools. Player One lists them to your agent, and the agent reads the one that fits before it starts, so it follows the service's own steps.

Player One keeps a remote server's connection between runs, so only the first run waits to connect. It lets go about ten minutes after the last run that used it, starts afresh after an hour, and starts afresh after a call on it fails.

Your agents get the servers you add, except sandboxed ones. A sandboxed agent, the kind you put in front of customers, never gets an MCP server, because servers run outside the walls it works within. Vault and sandboxing covers what such an agent can reach.

You add a server by asking in the chat, and an agent can add an ordinary one the same way. A local server is a program that runs on your installation's computer, so treat adding one as you would treat letting an agent run a command, and add only servers you trust. The MCP page lists only the servers tied to a signed connection, below. To see the rest, ask your agent which servers are connected.

Signed connections

Some services should not hold a key of yours at all. With a signed connection, Player One signs every request with an identity made for your installation, and the service checks the signature. The private half never leaves your installation, and no agent, tool or page ever shows it.

  • You do: open Admin > Communications > MCP (/admin/mcp), scroll to Signed connections, copy the Key ID and the Public key, and give both to the service so it can link your installation to your account. Neither is a secret.
  • Then: press Add, and fill in ID, Name, Origin (the service's https address, with no path) and Allowed paths, and the optional MCP server path if the service has an MCP server to sign for. Press Save.
  • You see it: the service listed with its origin, its paths and its MCP server, and a switch that turns it on and off.

The Profile field is the signature format the service expects. Today one format is offered, so this suits a service built for it, and the service's own instructions say whether it is. The form can fill itself in for the one service Player One already knows.

Player One signs only requests to the origin you approved, under the paths you listed. Anything else is refused and nothing is signed. Turning the switch off stops the next request, even in a run that is already going. Remove also removes the MCP server tied to the connection.

Only you can add, change or remove a signed connection, or an MCP server tied to one. If an agent tries, the change is refused and nothing is written. The tools of a signed server reach your agents only when you are the one asking, so a channel contact or a tool without Owner never gets them.

If the service refuses every signed request, it has not linked your installation's key yet, or it still holds an older one. Give it the Key ID and Public key shown on the page again.

A backup carries your signed connections only when you tick Include secrets, because each one is standing approval to sign as your installation. The signing key itself stays with the installation it was made on. After a move, give the service the new installation's Key ID and Public key.

Where next