MCP servers and skills, per harness, without the dotfile hunt

Model Context Protocol servers and reusable skills are two of the best ways to make coding agents more useful. They are also two of the most tedious things to manage once you use more than one agent.

Each CLI keeps its configuration somewhere different, in a slightly different JSON or TOML shape, with its own idea of global versus project scope. Add a server to one agent and you will forget to add it to the other. Six months later nobody remembers why a server that no longer exists is still configured.

One screen for every harness

The Harnesses screen in Dispatcher lists the agent CLIs it can run and shows, for each one, whether it is installed, whether it is signed in, and what it has spent. From the same screen you can manage the two things that shape what an agent can do.

MCP servers

For each harness, you can see its configured MCP servers, add a new one, test that it actually starts and responds, and remove the ones you no longer use. Dispatcher reads and writes each CLI's own configuration file, so the agent behaves exactly the same when you run it outside Dispatcher.

Testing matters more than it sounds. A misconfigured server often fails silently: the agent simply does not have the tool and works around it. A quick test when you add the server saves a confusing session later.

Skills

Skills are reusable instructions, usually a SKILL.md with supporting files, that teach an agent a procedure: how your team writes release notes, how to review a database migration, how to build a stacked pull request.

From the Skills tab you can search the catalog, install a skill onto a specific harness, and choose its scope:

• Global skills are available to that agent in every repository.
• Repository skills live in the repo, are reviewed like code, and apply only there.

A few habits that help

1. Start with fewer servers. Every MCP tool is something the agent has to consider. A small, relevant set beats a long list of maybes.
2. Prefer repository scope for team practices. If a skill encodes how your team works, put it in the repo so changes go through review.
3. Keep harnesses in step deliberately. When a server is useful for one agent, decide whether the others need it too, rather than drifting apart by accident.
4. Check spend after adding tools. New tools can change how an agent works, and how many tokens it uses doing it.

Configuration is not the exciting part of agent-driven development. It is, however, the part that decides whether your agents can reach the systems they need.