MCP Tool (MCP_TOOL)
A ready-made tool from the Docker MCP catalog — for example web search or a database. The agent server starts the tool itself. Connect it to an Agent so the agent can use it.
Category: Integration · Deployed: yes · Tool-capable: yes, only as a tool
Ports
| Port | Kind | Purpose |
|---|---|---|
Tool ( |
Tool |
Connect to the Tools port of an Agent |
There is no Input and no Output. The module is not a step in the flow. Only an agent calls it.
How to add it
-
In the Pipeline Designer, click the MCP Tools button at the bottom of the module list.
-
In the dialog Select MCP Tool, search for a tool. You can sort by name or by category.
-
Select the tool and click Add to Canvas.
-
Connect its Tool port to an Agent and fill in the fields in the properties panel.
The choice in the dialog decides which tool runs. Each card shows the category of the tool and how many settings it needs.
Properties
| Field | Required | Meaning |
|---|---|---|
Name ( |
Shown as required |
The tool’s name in the catalog. The tool that runs is chosen with the dialog above, not with this field. See the notes |
URL ( |
No |
The address of a tool server that you run yourself. Leave it empty for catalog tools. A catalog tool always wins: if the tool was added from the catalog, the URL is not used |
Tool Filter ( |
No |
Which functions of the tool the agent may use, by their exact name. The list offers the functions of the catalog tool. Empty → the agent may use all of them. Fewer → the agent chooses more reliably and cannot use what is left out. More → the agent has more options, and also the risky ones |
Secrets and parameters
The properties panel shows more fields below these. They depend on the tool you picked, so there is no fixed list.
-
Secrets — one hidden field per secret that the tool needs, for example an API token. Every one is marked as required. The field shows the tool’s own example as a hint, when it has one. The app does not check that they are filled in when it deploys the pipeline. If a secret is missing, the tool most likely fails when the agent calls it.
-
Configuration Parameters — settings that are not secret, for example a folder or an address. The field is filled with the tool’s example. Change it to your own value.
Both are given to the tool when it starts. A tool without secrets and parameters shows neither section.
|
Secrets are saved in the pipeline, but they are not included when you export the pipeline. After an import, fill them in again. The configuration parameters are included in an export, so do not put secret values there. |
What happens at run time
-
With Docker, the agent server starts the tool as its own container. The container is removed when it ends.
-
With Kubernetes, the agent server starts the tool as its own pod. It waits up to 60 seconds for the pod. It deletes the pod when the pipeline is removed from the agent. Folder mounts from the catalog are not used on Kubernetes.
-
The agent’s model decides when to call the tool.
Use cases
-
Standard abilities from the catalog — files, web pages, search, developer tools — without running a server yourself.
-
Narrow a broad tool with Tool Filter: allow only the read functions of a tool that can also write.
Notes
-
The pipeline cannot be deployed without a tool. A module that has neither a catalog tool nor a URL is reported as missing a field: "select an MCP tool from the catalog, or provide a manual SSE URL".
-
The Name field does not choose the tool. A tool added with the dialog works even when Name is empty. Do not try to select a tool by typing a name.
-
A tool you run yourself belongs in SSE Tool. That module is made for it.
-
Tool Filter is your safety control. Without it, the model can use every function the tool has, including ones that change or delete data.
-
The agent’s model must support tool calling. Otherwise the tool is never called.
-
The first start can be slow, because the tool’s image may need to be downloaded.