Skip to content

Guided tour

FabrCore 2.0 · Release and package availability

These guides track the current 2.0 source. Stable 2.0.0 publication is pending; package commands show the release target. Until it is published, follow the source quick start or use a matching available prerelease set. Release migration · Runtime modes

MODULE 03 · LESSON 3.4

Add MCP tools

Add external tools with MCP while retaining agent-level selection.

Lesson 14 of 86 · FabrCore 2.0

Overview

MCP supplies external tool definitions; FabrCore combines them with local tools and plugins. Stdio starts a local process and is useful for workstation tools. HTTP reaches a service and can use a principal-bound connection. Tool output remains untrusted content.

Discovery crosses a process boundary

An MCP client asks another process or service which tools it offers and how to call them. Stdio launches a child process on the Host machine. HTTP connects to a separately hosted endpoint. Choose by deployment needs: an Android device does not run a Host's stdio tool process, and a server's localhost address does not identify your development workstation.

Replace the executable/arguments or URL with an MCP server you actually run. Config-driven resolution can continue without tools from an unavailable MCP source, so check discovered tools and connection diagnostics explicitly; a healthy agent alone is not proof the MCP session connected.

Treat remote results as data

External tools can return long text, errors or content containing instructions. The output should be treated as retrieved data, bounded before it overwhelms context, and checked before it drives a business action. For authenticated HTTP tools, use a supported principal-bound connection/resource configuration rather than embedding a bearer token into an ordinary tool definition.

Connect an MCP tool source

Download the Operations Desk source. The README lists project setup, package prerequisites and local ports.

  1. Add an McpServerConfig to the agent definition with the documented stdio or HTTP transport fields. Start with a read-only tool and a bounded output.
  2. Resolve the configured tools and verify the advertised names before asking the model to use one. Restrict the configured selection to the needed capabilities.
  3. For authenticated HTTP MCP, set Connection and Resource and complete the connections lessons before supplying real credentials.
AgentConfiguration.McpServers · local process option 
{
  "McpServers": [
    {
      "Name": "request-tools",
      "TransportType": "Stdio",
      "Command": "<installed-mcp-server-executable>",
      "Arguments": [
        "<server-specific-argument>"
      ]
    }
  ]
}
AgentConfiguration.McpServers · separate HTTP service option 
{
  "McpServers": [
    {
      "Name": "request-tools",
      "TransportType": "Http",
      "Url": "https://tools.example.com/mcp"
    }
  ]
}

Check discovery before asking the model

  1. Start the chosen MCP service independently, then initialize a disposable agent with the matching transport configuration. Verify which remote tools were actually discovered.
  2. Invoke one read-only tool with a known input. Expect a returned result in the agent's tool-call record; merely reaching the server's home page does not verify MCP.
  3. Stop the MCP service and repeat. Expect a tool/discovery error that identifies the unavailable dependency, not an invented answer presented as a successful lookup.

The transport, remote tool catalog and business result are separate checks. If discovery works but invocation fails, investigate the tool's inputs and authorization rather than changing the model prompt.

If the result is different

Inspect process paths/environment for stdio failures and endpoint/authentication for HTTP failures. Do not register the same tool through both MCP and another plugin path.

Go deeper

Explore the related documentation.