> ## Documentation Index
> Fetch the complete documentation index at: https://docs.2501.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# MCP & Plugins

> When to give agents extra tools — and when not to

A **Plugin** (MCP) is an abstraction over a complex CLI or API. Instead of the agent shelling out to a command line, it calls tools described in natural language. The MCP server handles the underlying logic.

See [Plugins](/0.8/configure/plugins) for configuration. This page covers **when** to add one.

## Pros and cons

<CardGroup cols={2}>
  <Card title="Pros" icon="check">
    * Simplifies hard-to-use CLIs
    * Better tool definitions = fewer wrong arguments
    * Abstracts complex multi-step logic
    * Can expose capabilities the agent wouldn't normally have
  </Card>

  <Card title="Cons" icon="triangle-exclamation">
    * Each plugin adds a list of tools to the agent's context
    * That cost compounds quickly — many plugins = bloated context
    * Better to scope plugins per-agent than enable everywhere
  </Card>
</CardGroup>

## When to add an MCP

If you observe an agent **consistently struggling** with a specific tool or CLI, that's the signal. Symptoms:

* Repeated errors on the same command
* Wrong arguments, hallucinated flags
* Trouble parsing the tool's output
* Calling commands that don't exist

A real example from the field: agents handled VMware `govc` poorly — wrong paths, wrong arguments, invented commands. After adding a **VMware MCP**, the agent could manage machines, snapshots, and datastores with no friction. Night-and-day difference.

## When NOT to add one

* **Standard CLIs the agent already handles well** (`kubectl`, `docker`, `aws`, `psql`, basic shell) — adding an MCP just bloats context for no gain.
* **One-off use cases.** If you only need a tool once a quarter, the context cost outweighs the benefit.
* **Wrapping something already in a [specialty](/0.8/configure/specialties).** A specialty teaching `aws ec2` patterns is often enough.

## Scoping plugins

A plugin can be **tenant-level** (available to every org's agents) or **org-level** (only that org's agents). Per-agent assignment lets you be even more selective — give VMware MCP only to the vSphere-handling agents, not the database ones.

Rule of thumb: a plugin's cost is **paid by every agent it's attached to, on every task**. Be selective.
