Connect MCP servers to your base

An MCP server gives your base's agents and the assistant more tools: your ticket system, your notes, your payments, another service. The agents that choose it can list and call its tools. Most services are on Base Captain's list, and you connect one by signing in to it. The admins and the AI managers connect MCP servers.

1. Click Settings, then MCP servers, then New MCP server.
2. The page opens on the list of services, such as Notion, Linear, Stripe, Airtable or Zendesk, each with one line that says what it does and how you get in: Sign in, Key or Open. Type in Search services to find one. A service marked Not available yet, such as Gmail, Google Calendar, Google Drive, HubSpot, Slack or GitHub, signs in only with a client that Base Captain registers with it, which the list does not have yet.
3. Click the service. The form is filled for you: its Name, its Address and What it does. Click Save MCP server. Saving also allows the service's host in Settings, General, which only an admin may do; for anyone else the page says "An admin must allow … in Settings, General first".
4. On the server's page, connect it. For Sign in, click Connect: the service's own page opens, you sign in there and allow access, and you come back to the page, which says Connected as and your account on that service. For Key, paste the key in the one Key field, where the page also says where to get it, and click Save key. An open server says Connected at once.
5. Tick it on the agents that may use it, at most 12 each.

What it does is one line, at most 200 characters, that you can change on the server's page. Every run is told it with the server's tools, so the agent knows what the server is for. If you leave it empty, runs get the description that the server gives. The MCP servers page shows each server's line under its name.

Limits and details:

• One connection serves the whole base: every agent that chose the server uses it.
• Base Captain keeps the service's token sealed, renews it when it runs out and sends it only to that server; you never see it.
• Disconnect ends the connection, and the agents lose the server's tools until someone connects it again.
• If the service refuses the connection later, the page says "… refused the connection: connect it again" with Connect, and the builders get a notification.
• A key is kept as a secret of the base, sent only to the server's host (Store the keys of other services).

A service that is not on Base Captain's list connects through one of the list's last two entries, a custom address or a command:

• Custom address: a service's remote MCP server at the address it gives, which any agent can use. Once saved, Base Captain checks it and finds whether it needs a sign-in, a key or nothing, and the page shows Connect, the key field or Connected as for a server from the list.
• Command: a program a machine starts for a machine agent's run. Enter the Command, its Arguments one per line and its Environment variables. A command gets no secrets, since it runs on a user's own machine: set its key in that machine's own environment. A secret in a command's variables is refused with "A command MCP server gets no secrets: set the key in the machine's own environment".

A remote server's headers are under Advanced. Where a server needs a header of its own, write {{secrets.NAME}} in it for a secret from the Secrets in Settings: it is filled in at each run, only when the server's host is where that secret is sent, and never shown. A secret saved for a service from the list goes only in the header that service takes, such as Authorization, and a secret that is an address goes in no header. Such a header is refused, and nothing is sent to the server (Store the keys of other services).

An agent gets all the tools of each MCP server it chose, or only the ones you name. On the agent's page, under each MCP server it chose, pick All tools, the default, or Only these tools, and tick the tools it may use: each shows its name and the first words of what it does, from the server's last check.

For example, give a support agent only a mail server's tools that read mail: it cannot send one, whatever a mail asks of it. There is no "read only" choice: read the tools' names and pick.

Limits and details:

• A server not checked yet offers only All tools until it is.
• A named list takes no tool the server adds later.
• A tool on the list that the server's last check no longer lists shows as missing until you remove it.
• A run, in Base Captain or on a machine, lists and calls only the agent's tools; a call of another one is refused with the tools the agent may use, such as "This agent may not use “send_message” of gmail: it may use search_messages, read_message."

The assistant and an API token set and read the same choice as the agent's mcp_tools, by tool name: {"tickets": ["ticket", "echo"]}.

The assistant uses the base's MCP servers, such as your ticket system or Linear, from the item you have open. Open an order and ask "Create a ticket issue for this order": the assistant finds the server's tool and calls it with the order's details. An admin or an AI manager sets how the assistant uses each server, on the server's page.

Who may use a server through the assistant

• Roles: on the server's page, tick the roles whose users may use the server through the assistant. The users who build the base always may. Other roles get no tools of the base's MCP servers.
• The customers of a portal get none either, and a role of a portal's customers is not on the list: a server signs in with the base's connection, so a call acts in the other service as the user who connected it.
• The assistant uses only the servers with an address, never a command that a machine starts: a command server has no roles, starters or tools settings. It uses them only in your own conversation with it, never in a chat channel.
• A role or a table that is deleted later goes away from the server by itself.

Tools that change something wait on a card

A tool that only reads, such as a search, runs at once. A tool that changes something waits on a card. The card's title is one plain sentence of what the call does, with its names and values, such as "Create the issue 'Refund fails' in tickets." Under it, the card names the server and the tool, such as tickets · create_issue, and each value it sends, such as title: Refund fails. Click Apply, and the call runs; click Cancel, and nothing is sent.

Tools, on the server's page, has one row for each tool of the server's last check, with its name and what it does. Pick Ask first to make the assistant show a card before each call, or Run at once. Default runs a tool at once when the server says that the tool only reads, and shows a card for each other tool: the row says which, Default (runs at once) or Default (asks first).

What the call makes is linked back. When you apply the card on an item's page and the service answers with a web address, such as the new issue's, the base adds a comment on the item in your name, via the assistant: the card's sentence and the address as a link. If the comment cannot be added, the assistant says so, and the call still counts.

A server's answer comes from outside the base, so after a call, every change the assistant makes in that conversation waits on a card, its calls of tools that change something included. Its reads and the tools that only read still run at once, but opening a web page waits on a card that shows the page's whole address (Ask a question about a web page).

Starters: buttons on an item's page

Starters are short requests that an admin or an AI manager writes for a server, such as "Create a ticket issue for this order". An item's page shows the starters of the servers you may use as small buttons, such as Create a ticket issue for this order. Click one: the assistant opens and gets the request, with the item you are looking at. When there is no server you may use, the page shows none. Each starter is one line of at most 120 characters, for the tables you pick, or for every table if you pick none. A server has at most 10.

With an API token

GET /api/assistant/starters?table=orders answers the starters an item page of that table shows you, and you talk to the assistant through POST /api/assistant/messages and answer its card through POST /api/assistant/cards/<id>. POST /api/builder/apply with put_mcp_server sets the same roles (role keys), starters ({"text": "…", "tables": ["…"]}) and ask, a tool's name with "ask" or "run": {"create_issue": "ask", "echo": "run"}. Ask the assistant "Let managers use tickets" and it shows the change on a card. A role that is not one of the base's is refused, and so is a role of a portal's customers, with "an outside role cannot use an MCP server". Base Captain's MCP server does not offer the MCP servers' tools (What an AI client can and cannot do in a base).

The MCP servers page says which agents chose each server and whether it works: for a command, on each machine ("3 tools", or why not, such as a program the machine does not have); for a remote server, from Base Captain. Each is checked when it changes, and the round-arrows button at the end of its row ("Check again" when you point at it) asks once more.

A server can change its tools after you chose it: a tool's description changes, a tool is added or one is removed. Base Captain finds it when a run lists the server's tools or when the server is checked. The builders then get one notification, "The MCP server … changed its tools", which opens the server's page. There, Tools changed on and the date list the tools one by one, Added, Removed or Changed, with the old and the new description, and "Its inputs changed" when a tool now takes other inputs. The MCP servers page marks the server Tools changed. The agents keep using the tools meanwhile: nothing is held back, so read the change and untick the server on an agent if you do not want it.

Limits and details:

• A change is told once: the next runs and checks find the same tools and notify nobody, and the page shows the last change until a newer one replaces it.
• Editing the server yourself tells nobody: what it lists then is what you chose, and the page clears the change.
• A command server is listed on each machine, so each machine finds its own change, the notification names the machine ("… changed its tools on …") and the page shows the change under that machine.

With an API token, GET /api/builder/mcp gives each check's change, and the tool check_mcp_server does the same for the assistant and through Base Captain's MCP server.

The assistant connects a service from the same list as the MCP servers page. Ask it "Connect our Notion": it adds the server from the list and gives you the Connect link to open. Signing in is always your own step, in your own browser.

• The link opens the service's own page, after a Base Captain sign-in if you are not signed in, but only for a user of the base who may connect its MCP servers; anyone else sees "Only a user of … who may connect its MCP servers can finish this sign-in."
• Finish the sign-in in the browser where you opened the link: in another one, it stops with "This sign-in was started in another browser. Click Connect again in the base."
• Base Captain checks every service on the list each week and keeps the list current.

With an API token, GET /api/builder/mcp/list?q=notion returns the list's entries, POST /api/builder/mcp/notion/connect answers the Connect link, and DELETE /api/builder/mcp/notion/connection disconnects. Through Base Captain's MCP server, the tools find_mcp_server and connect_mcp_server do the same.