agentc
GitHubagentc-sh/agentc
agentc
GitHubagentc-sh/agentc
›Introduction
Get started›Concepts in 5 minutes›Build your first agent›Add your first tool›Serve and connect
Concepts›Architecture overview›The manifest›The compilation pipeline›Archetypes›The graph›Tools and capabilities›Runtime libraries›Skills›Agents and prompts›Serving and protocols›Observability
Guides›Author a manifest›Write a tool›Give your agent a filesystem›Control network egress›Connect external tools via MCP›Connect agents via A2A›Use the bash tool›Control tool access with capabilities›Write templated prompts›Manage prompts with Langfuse›Pass context from the client›Configure a model provider›Connect a CopilotKit frontend›Deploy a standalone binary›Deploy with Docker and PostgreSQL›Instrument with OpenTelemetry›Extend code generation with blocks
Reference
Manifest
Runtime
›Observability

Connect external tools via MCP

Connect an agent to tools served by a Model Context Protocol server.

Not every tool has to live in your project. A Model Context Protocol (MCP) server exposes a set of tools over a standard protocol, and agentc can connect to one and register every tool it offers. Unlike tools you write, MCP tools are not embedded at compile time; the manifest describes how to reach the server, and the server must be available when the agent runs. When the agent starts, it connects, queries the server for its tools, and registers each one automatically. For the full field reference, see the tool reference.

MCP servers are not embedded

An MCP server cannot be baked into the artifact. Only the connection configuration is compiled in, so the server must exist in the runtime environment. If the agent cannot reach the server at startup, it errors. Make sure the command or URL you configure is available wherever the agent runs.

Connect to a local server over stdio

The stdio transport spawns the server as a child process and talks to it over standard input and output. This is the usual way to run a local MCP server:

agent.acl
tool "time" {
  kind      = "mcp"
  transport = "stdio"
  command   = "uvx"
  args      = ["mcp-server-time"]
}

Both command and individual args entries accept runtime(), so you can configure the server from the environment:

tool "filesystem" {
  kind      = "mcp"
  transport = "stdio"
  command   = "npx"
  args      = ["-y", "@modelcontextprotocol/server-filesystem", runtime("FS_MCP_WORKSPACE", "/workspace")]
}

Connect to a remote server over HTTP

The HTTP transport connects to a remote MCP server. Use secret(runtime(...)) for the auth token so it stays out of logs and build output:

agent.acl
tool "remote_tools" {
  kind       = "mcp"
  transport  = "http"
  url        = runtime("MCP_SERVER_URL", "https://tools.example.com")
  auth_token = secret(runtime("MCP_AUTH_TOKEN"))
  headers    = {
    "X-Client-ID" = runtime("CLIENT_ID")
  }
}

Apply capabilities to a server's tools

A capabilities list on the tool block applies its tags to every tool discovered from that server, so you can gate a whole server behind a capability the agent must hold:

tool "my_service" {
  kind         = "mcp"
  transport    = "http"
  url          = runtime("SERVICE_URL")
  capabilities = ["my_service"]
}

See Control tool access with capabilities for how capabilities gate access.

Where to go next

  • Tools and capabilities: how MCP tools sit alongside the other kinds.
  • Control tool access with capabilities: restrict what a connected server exposes.
  • tool reference: every stdio and HTTP field for MCP tools.
← PreviousControl network egressNext →Connect agents via A2A

© 2026 pogue.dev. All rights reserved.

Creative CommonsCC BY 4.0
On this pageConnect to a local server over stdioConnect to a remote server over HTTPApply capabilities to a server's toolsWhere to go next

Search docs

Search the agentc documentation