Skip to main content
Plugins connect agents to external systems: an inventory, a ticketing tool, a cloud API. The agent calls a plugin’s typed tools instead of driving a command-line tool through the shell, which stays available for everything else. Use a plugin when that tool needs authentication, has a poor --help, or is internal; Shell, Central and plugins walks through the choice.

​
MCP Servers and HTTP APIs

An MCP server publishes its own tools over the Model Context Protocol. 2501 connects to a remote one by its URL, or runs a hosted one from a container image. Prefer an MCP server when a decent one exists: its tools are designed for agents. An HTTP API plugin connects agents to a much broader range of APIs: your internal APIs, and APIs that LLMs have no prior knowledge of. Register its base URL and describe it with OpenAPI or Swagger files, or plain Markdown and text documentation, so the agent knows which endpoints exist and what they take. In investigate mode it can only send GET.

​
Agents and Plugins

Agents and plugins are many to many. A plugin belongs to one organization or is tenant-wide. Switching it off stops every agent from using it from the next turn, and keeps the assignments. A plugin is anonymous or authenticates with a saved credential: a Bearer token, an API key header or, for an MCP server, OAuth. The agent never sees the secret. Plugins has the setup steps, including checking that a plugin is reachable.

​
Plugins and Clusters

An HTTP API can send its requests from a cluster’s nodes, to reach an API only that network zone can. MCP server calls go out from the engine for now; running them on a cluster is planned. When a call goes out from the engine, a task on a cluster needs no route of its own to the API. Clusters shows how. A task can use an HTTP API whatever it runs on: a Host, a Central, or neither. The requests always leave from the HTTP API’s own location, never from inside a Central, and fail if that cluster is unavailable instead of moving elsewhere.