Skip to main content
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 for configuration. This page covers when to add one.

​
Pros and cons

Pros

  • 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

Cons

  • 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

​
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. 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.