How to add a teammate to MCP Self-hosted

To add a teammate to mcp-core, you create a new seat for them on your license, pick the tools and mode they get, and hand them the token. They use the server you already run, with no second install.

This post covers the steps in My Account, which tools to give, and how to remove access when someone leaves.

What do you need before you add a teammate to mcp-core?

You need one free seat. A seat is one identity, a person or a device, with its own token, its own subset of the tools on your license and its own read-only or read-write mode per tool. The server checks every request against those seats and builds the tool list for that token.

An MCP Self-hosted license includes 3 seats. The first one already exists: when your download was built, a seat labelled “Default install” was created with every tool on the license. That is usually yours. So on a plain MCP Self-hosted license, two seats are free for colleagues.

Does a new colleague use a seat or an activation?

When you add a teammate to mcp-core, you use a seat, not an activation. An activation is one running mcp-core container, and MCP Self-hosted includes one. Your colleague connects to the server you already have.

You only need a second activation when you start a second container, for example on another server. The Advanced tab of your license lists each running container with its Last check date and a Release button.

How do you add a teammate to mcp-core, step by step?

The whole flow sits under My Account on addocore.com:

1. Open My Account → MCP Self-hosted and choose the Seats tab of the license.
2. Enter a Label. Name the person and the device, for example “Anna – support laptop”.
3. Tick the tools this seat can use. Only tools on your license are listed.
4. Pick read-only or read-write next to each ticked tool.
5. Click Add seat. The new row shows the token with a Copy button.
6. Apply the change on your server with the command below.

docker exec mcp-core npm run refresh-license

The server works with the seats it received at its last license check. Without the refresh, the new token starts working at the next automatic check, within 72 hours. With it, the next request already knows the new seat. No restart is needed.

Which tools and mode should a teammate get?

Give each person only what their work needs. A support colleague who answers customer mail needs Missive, in read-write if Claude should send replies for them. An analyst who checks numbers needs Database in read-only. Someone who writes blog posts needs WordPress in read-write and nothing else.

Read-only is the default for every tool except Brain, which defaults to read-write. In read-only mode the write tools are not registered at all, so Claude never sees them. The Database tool is the exception: its query tool stays, but write statements are rejected. You set the mode here, per seat, and not in the .env file. The full logic is on entitlements vs tool modes.

Narrow seats are easier to reason about. When you add a teammate to mcp-core with only two tools, a leaked token exposes two tools.

How does the teammate connect Claude?

The last step to add a teammate to mcp-core happens on their machine. Send them two things: the server URL and their token.

By default the container listens on 127.0.0.1:3200, so only the host itself can reach it. For a colleague on another machine, put a reverse proxy with HTTPS in front of it and give them that address. They then add the server to Claude Desktop or Claude Code with their token. Connect Claude to an MCP server has the exact configuration for both clients.

To check the result, have them ask Claude to run mcp_status. It lists the license state and the tools and modes of the calling seat. If a tool is missing, the container log has a line per tool that says why it was registered or skipped for that seat.

What if you can’t add a teammate to mcp-core because of the limit?

When all seats are in use, the form on the Seats tab is replaced by the message “You have reached the maximum number of seats for this license.” You have two options. Revoke a seat nobody uses anymore, or buy an extra seat for € 18,15 excl. VAT: € 15,00 per year.

How do you remove a teammate’s access?

Removing access is the reverse of how you add a teammate to mcp-core. Click Revoke in the Actions column of their row and confirm. The seat disappears; every other seat on the license keeps working. Then run the refresh command so the server drops the token now.

If a token leaked but the person still needs access, use Regenerate token instead. The old token stops working once mcp-core picks up the change, and you send them the new one.

Never hand out the “Default install” token. It is also the BEARER_TOKEN in your .env and in claude-plugin/.mcp.json, so regenerating it means updating both files and running ./mcp-update.sh.

What else lives on the license page?

The Tools tab holds the API keys your add-ons need, such as the Missive token or the WooCommerce consumer key. They are stored encrypted and shared by every seat on the license. When you add a teammate to mcp-core, they never need their own copy of those keys. When you buy an add-on later, nothing has to be downloaded again: enter its keys under Credentials or in .env and run the refresh command. MCP license management covers every tab in detail.

The short version

To add a teammate to mcp-core: one seat per person or device, only the tools they need, the right mode per tool, and a license refresh after every change. Removing them takes one click and the same refresh. For the reference on tokens, stores and limits, read MCP seats.