Skills & MCP servers
Two ways to equip every run at once: instructions the agent reads, and tools it can call.
Both are registered once by an admin for the organization, then picked per project.
- A skill is a page of instructions with one line saying when it applies. The agent always sees that line; when the work matches, it reads the page and follows it. "How we write commit messages", "our review tone", "the deploy checklist" — the things you would brief a new teammate on.
- An MCP server is an outside service the agent may call tools on during a run — a docs index, a database gateway, an internal API. Anything that speaks the Model Context Protocol.
This is the opposite direction from Connected apps: that page is about chat apps driving Peractor; this one is about a run's agent reaching somebody else's tools.
Skills
Write one under Settings → Skills: a name, the "when it applies" line, and the instructions in markdown. Skills use the open SKILL.md format, which buys two things:
- Any public skill works here. Paste a GitHub address — the
repository URL, a folder inside it, or plain
owner/repo— and Peractor fetches its SKILL.md as a draft for you to read and save. The empty screen suggests a few well-known ones to start from. - They work on every agent. Claude Code discovers staged skills natively; agents without a scanner get the same skills listed in their instructions, with the files on disk beside the work.
During a run, each picked skill is staged read-only into the workspace and excluded from git, so it can never be committed.
MCP servers
Register one under Settings → MCP servers: a name, how it is reached — a URL, or a command that runs beside the agent inside the sandbox — and where its token goes. Both built-in agents get every picked server on every prompt step, each configured in its own format.
The token is write-only. It is encrypted the moment you save it, never shown again, and never written to any file the agent could read into a commit — the run's environment carries it, and the generated config refers to the variable.
Registering or changing a server is admin-only and lands in the organization's audit log, because a server is a network peer reachable from inside the sandboxes that hold your code. Register only services you trust.
A repository's own committed
.mcp.json is deliberately ignored during runs. Only servers
registered here apply, so what your agents can reach is always the list
on this screen. If you restrict outbound traffic, a registered server's
host is allowed through automatically.
Picking is the boundary
Like shared workflows and personas, nothing an admin registers reaches any run until a project ticks it, under that project's Settings → Shared library. Stop picking a skill or server and it stops applying on the next run — nothing needs restarting.