MCP — Model Context Protocol servers

Register Model Context Protocol servers with AgentField and their tools become ordinary skills — discoverable, callable across agents, and traced like everything else on the mesh.

AgentField speaks Model Context Protocol as a client. Point it at an MCP server and every tool that server exposes becomes an AgentField skill.

An MCP server publishes tools. AgentField publishes skills. The bridge maps one onto the other, which means an MCP tool inherits everything the control plane already gives a skill: an HTTP endpoint, runtime discovery, cross-agent calls, tracing, and policy.

This page is about consuming MCP servers from AgentField. If you want the reverse — publishing AgentField capabilities to consumers outside your deployment — see external agent discovery.

Add a server with the CLI

# Remote MCP server
af add --mcp --url https://github.com/modelcontextprotocol/server-github

# Local MCP server, with setup commands run before it starts
af add --mcp my-server --run "node server.js --port {{port}}" \
  --setup "npm install" --setup "npm run build"

af add writes the server into agentfield.yaml, so the configuration travels with the project.

Flag	Description
`--mcp`	Add an MCP server (required for MCP mode)
`--url`	GitHub URL of a remote MCP server
`--run`	Command to start the server (supports the `{{port}}` template)
`--setup`	Setup command to run before starting (repeatable)

Manage running servers

af mcp status        # Show MCP server status
af mcp start         # Start MCP servers
af mcp stop          # Stop MCP servers
af mcp restart       # Restart MCP servers
af mcp logs          # View MCP server logs
af mcp discover      # Discover MCP server tools
af mcp skills        # List MCP-provided skills
af mcp remove        # Remove an MCP server

MCP Servers
───────────
Name             Status    Port    Uptime
server-github    running   9001    2h 15m
my-server        running   9002    45m
postgres-mcp     stopped   —       —

Auto-register tools as skills

app = Agent(
    node_id="mcp-bridge",
    enable_mcp=True,
)

# MCP tools are automatically discovered and registered as skills
# with the naming pattern: {server_alias}_{tool_name}
# Each tool gets a /skills/{skill_name} endpoint

const agent = new Agent({
  nodeId: "mcp-agent",
  mcp: {
    servers: [
      { alias: "github", url: "http://localhost:3100", transport: "http" },
      { alias: "db", port: 3200, transport: "http" },
    ],
    autoRegisterTools: true,
    namespace: "tools",
    tags: ["external"],
  },
});

Tools are named {server_alias}_{tool_name}, so the GitHub server's create_issue tool registers as github_create_issue and answers at /skills/github_create_issue.

Call an MCP tool from another agent

Once registered, an MCP tool is an ordinary capability on the mesh. Any other agent reaches it the same way it reaches a hand-written skill:

@app.reasoner()
async def triage(service: str) -> dict:
    metrics = await app.call("mcp-bridge.fetch_metrics", {"service": service, "window": "1h"})
    return await app.ai(f"Diagnose these metrics: {metrics}")

agent.reasoner('diagnose', async (ctx) => {
  const { service } = ctx.input;
  const metrics = await ctx.call('mcp-bridge.fetch_metrics', { service, window: '1h' });

  return ctx.ai(`Diagnose these metrics: ${JSON.stringify(metrics)}`);
});

Because the tool is a skill, it also shows up in app.discover() — so a reasoner using tools="discover" can pick an MCP tool at runtime without anyone hardcoding it.

Where to go next

Skills — what a registered tool becomes
Agent discovery — how a reasoner finds tools at runtime
CLI reference — every af add and af mcp flag
External agent discovery — publishing outward instead of consuming inward