# Tool servers

> The outside services your agents can use — described once, delivered to every CLI, with the credentials kept out of the file.

An agent is much more useful when it can reach the things you already use: your
issue tracker, a browser, a database, a design tool. Those connections are
called **MCP servers**, or tool servers.

Every agent supports them, and every one wants the configuration in a different
file, in a different place, in a slightly different shape.

beafk keeps **one description** and delivers it to all of them.

## Adding one

**settings → MCP**. The screen is a catalogue of the services people actually
connect — GitHub, Linear, Slack, Jira, Sentry, Datadog, Playwright, Figma,
Stripe, and forty-odd others — grouped by what you came to do rather than
alphabetically, and searchable by what a thing is *for*: type "browser" and
Playwright comes up, which is called nothing of the sort.

Tap **add**. That press *is* the connection. Sign-in, if the service needs it,
is on that server's own row, not a second button in the dock.

A server nobody listed — a command to run, a URL somebody gave you — is still
there: **Something else**, at the end of the list, and then the form.

Then you choose which agents get it. That is the whole of it — beafk writes each
agent's own configuration file in the shape that agent expects.

![settings → MCP — the catalogue, grouped, with a couple already connected](https://beafk.app/docs-shots/mcp.webp)

## Signing in

Some servers need a token; some need an OAuth round trip. Both are handled from
the panel. A server that needs you to go and approve something in a browser says
so, with the link.

Some ask for a client id before the first press, because their issuer does not
hand one out on the spot — GitHub is the one everybody meets, and Google's,
Slack, Asana, HubSpot, Box and Render are the same story. The screen says so
before you start, and it says which.

Google's go further: a sign-in can succeed and every call still be refused,
because the server is gated in your own Google Cloud project rather than by the
handshake. [Connecting Gmail](https://beafk.app/docs/connecting-gmail.md) is that walk, and it is
the same two gates for the others.

The credential is kept by beafk and delivered to the agents that need it. It is
masked in the panel and in the CLI, and it is not written into a file that ends
up in your repository.

## Which agents get which

Per server. A browser tool that everybody should have goes to all of them; a
staging database that only your reviewer needs goes to one.

A chat that is already running may not pick up a server you just added.
Start a new one — and see
[keeping every CLI in sync](https://beafk.app/docs/keeping-every-cli-in-sync.md) for when a change
reaches which agent.

## Taking one away

Remove it and beafk takes it out of every agent's file. A revoked credential is
forgotten rather than moved to the [trash](https://beafk.app/docs/the-trash.md): a trash is a folder
inside a repository, and a live credential does not belong in one.

## Machine-wide or per project

Both. A server described for the machine is available in every project on it; a
server described for a project is available in that one. Same rule as
[variables](https://beafk.app/docs/variables.md), and for the same reason.

## What this does not do

It does not change how a server's code runs, and it does not audit what a tool
does once an agent calls it. Give your agents the ones you would give a new
colleague on their first day.

---

beafk documentation · Skills and variables · https://beafk.app/docs/tool-servers

In this section:
- Keeping every CLI in sync — https://beafk.app/docs/keeping-every-cli-in-sync.md
- Variables — https://beafk.app/docs/variables.md
- Tool servers — https://beafk.app/docs/tool-servers.md (this page)
- Connecting Gmail — https://beafk.app/docs/connecting-gmail.md
- Skills — https://beafk.app/docs/skills.md

Every page, one line each: https://beafk.app/docs/llms.txt
All of it in one file: https://beafk.app/docs/llms-full.txt