Connect an MCP Tool Once, and Have Every AI Engine Get It
The config sprawl is not anybody's fault.
Every engine shipped its own format.
The fix is not a standard nobody will adopt; it is one install that writes all of them.
Short answer
Connect it a layer above the engines. Each one stores MCP configuration differently: different file, different format, different location, and some support project scope where others only support global. So the capability is connected once and written into every installed engine's own config and skills directory, rather than added by hand in each.
What this covers
- A Pathrule plugin is a packaged capability you connect once, and installing it writes into every installed engine's own configuration and skills directory.
- A plugin differs from a pattern by ownership rather than content: a plugin's skill is updated upstream by whoever publishes it, while a pattern's skill becomes your knowledge the moment you import it and never changes underneath you.
- Scope is chosen at install, global for every project on the machine or scoped to one project, and engines with no project-level configuration fall back to global and are shown as such rather than failing.
- Connecting a plugin grants no new permissions over your machine; its tools run under the engine's own permission model and the workspace's rules and work-safety limits still apply.
Comparison
| Object | What it gives you | Who owns it | Does it change under you |
|---|---|---|---|
| Plugin | A capability: tools, skills, agents | The author or the catalogue | Yes, upstream updates it |
| Pattern | Knowledge: memories, rules, skills | You, from the moment you import | No |
| MCP server you configured | One tool surface | You | Only when you edit it |
| Agent | A subagent definition | You, or a plugin | Only if a plugin owns it |
The chore
You decide to connect a tool to your AI setup. Not an exotic one: an issue tracker, a database, a deploy platform. Then you discover that Claude Code keeps its MCP configuration in one file, Codex in a TOML file somewhere else, OpenCode in its own JSON, Kimi in another, Antigravity in another, and Cursor, Windsurf and Copilot in three more.
Some of them support a project-level config. Some only support global. The formats are not the same shape. None of this is anybody's fault; every engine shipped what made sense for it. But the result is that connecting one tool everywhere is a twenty-minute job you do wrong at least once.
One install, every engine
A plugin is a packaged capability: tools, and often skills and agents alongside them. When you connect one, Pathrule writes it into the configuration of every engine you have installed, in that engine's own format and location.
Skills the plugin ships are written into each engine's skills directory, with duplicate targets filtered so a skill is never written twice for engines that share a directory.
At install you choose the scope: global, for every project on the machine, which is the default because an account connection like a drive or a notes app is meaningful at the machine level; or this project only. Engines with no project-level configuration fall back to global and are shown as global in your inventory, which is a quiet correct answer rather than an error you have to read.
Plugin, pattern, server, agent
Four objects live near each other and two of them look alike, so the distinction is worth stating plainly. The carrier of the difference is ownership, not content.
A plugin's skill is updated upstream by whoever publishes it. A pattern's skill becomes your knowledge the moment you import it, and never changes underneath you again. A single MCP line you typed yourself is not a plugin at all; it stays in its own group with its own menu, because you maintain it.
That asymmetry shows up in the interface without a word of explanation: a plugin offers Update, Disable and Remove, while a server you configured by hand offers Edit JSON, Auth, Disconnect and Delete.
What connecting does not do
Connecting a plugin does not give an agent new powers over your machine. The tools it brings run under the engine's own permission model, and the rules and work-safety limits your workspace already enforces still apply.
That boundary is deliberate and it is the reason the feature can be one click. If installing a plugin also widened what an agent could touch, it would need a consent dialog with real stakes every time. It does not, so it does not.
The [plugins documentation](/docs/studio/plugins) covers the panel, the marketplace and the exact configuration paths per engine.