tool

The tool block declares a tool that the agent can call during a run. A manifest can contain any number of tool blocks. The kind field determines the tool type and which additional fields apply.

tool "adder" {
  kind         = "javascript"
  source       = "./tools/adder"
  capabilities = ["math::add"]
  enabled      = runtime("TOOL_ADDER_ENABLED", true)
}

Common fields

These fields apply to all tool kinds. For javascript, python and bash tools, the block label is the tool's name, the name the model calls it by.

javascript

A JavaScript tool is a TypeScript or JavaScript package bundled by esbuild at compile time and executed in the runtime's embedded engine. See runtime libraries for the environment that engine provides. The bundle is embedded in the binary; no Node.js installation is required at runtime. The selected export must be a class extending Tool from agentc:tools. Its static parameters must be a Schema instance.

tool "adder" {
  kind         = "javascript"
  source       = "./tools/adder"
  export       = "AdderTool"
  capabilities = ["math::add"]
  enabled      = runtime("TOOL_ADDER_ENABLED", true)
  config       = {
    API_ENDPOINT = runtime("ADDER_API_ENDPOINT", "http://localhost:3000")
  }
}

See Write a tool for how to write the tool source.

python

A Python tool is a uv-managed Python package. Dependencies are installed at compile time and the package source and site-packages are embedded in the binary. The selected interpreter determines whether the embedded package runs through RustPython or CPython. The selected export must be a class subclassing Tool from agentc_tools.

tool "weather" {
  kind         = "python"
  source       = "./tools/weather"
  export       = "Weather"
  interpreter  = "embedded"
  capabilities = ["weather::get"]
}

See Write a tool for how to write the tool source.

bash

A Bash tool provides the agent with a shell interpreter. It uses the top-level filesystem and network configuration. The agent must hold the built-in bash capability in addition to any capabilities declared on the tool.

tool "shell" {
  kind     = "bash"
  commands = ["git"]
  cwd      = "/workspace"
  shared   = false

  env {
    kind = "allow"
    vars = ["HOME", "PATH"]
  }

  limits {
    max_execution_time_secs = 30
    max_output_size         = 10485760
    max_command_count       = 10000
    max_loop_iterations     = 10000
  }
}

BashEnv

Supported policies are "empty" (no variables), "inherit" (all variables), "allow" (only vars), and "deny" (all except vars).

BashLimits

All fields are optional and use the following defaults when absent.

With shared = false, each invocation gets a fresh interpreter. With shared = true, variables, functions, aliases, and working directory changes persist between invocations. Filesystem changes follow the configured filesystem backend in either mode.

The built-in curl command uses the agent's HTTP client and cannot bypass its network policy or limits. See Use the Bash tool for configuration and lifecycle examples.

mcp

An MCP tool connects the agent to a Model Context Protocol server. Two transports are supported: stdio spawns a local subprocess; http connects to a remote server over streamable HTTP.

# stdio transport
tool "time_server" {
  kind      = "mcp"
  transport = "stdio"
  command   = "uvx"
  args      = ["mcp-server-time"]
}

# HTTP transport
tool "remote_tools" {
  kind       = "mcp"
  transport  = "http"
  url        = runtime("MCP_URL", "https://tools.example.com")
  auth_token = secret(runtime("MCP_TOKEN"))
  headers    = {
    "X-Client-ID" = runtime("CLIENT_ID")
  }
}

stdio fields:

HTTP fields:

See Connect external tools via MCP for more on Model Context Protocol integration.

a2a

An A2A tool delegates work to another agent through the Agent2Agent protocol. Each configured target is a fixed downstream server, not a model-visible arbitrary URL. Every A2A target registers the same four operation tools:

• a2a_{target_id}_send
• a2a_{target_id}_stream
• a2a_{target_id}_get_task
• a2a_{target_id}_cancel_task

tool "planner" {
  kind        = "a2a"
  description = "Delegate planning subtasks to the planning agent."
  url         = runtime("PLANNER_A2A_URL", "https://planner.example.com")
  auth_token  = secret(runtime("PLANNER_A2A_TOKEN"))

  headers = {
    "X-Client-ID" = runtime("PLANNER_CLIENT_ID", "assistant")
  }

  tenant = {
    policy = "inherit"
  }

  timeout_secs                  = runtime("PLANNER_A2A_TIMEOUT", 90)
  default_accepted_output_modes = ["text/plain"]
  capabilities                  = ["a2a::planner"]
  enabled                       = runtime("PLANNER_A2A_ENABLED", true)
}

There is no operation-selection field. Every target always gets send, stream, get-task, and cancel-task tools.

TenantPolicy

The tenant block controls the X-Tenant-Id value sent to the downstream A2A server.

tenant = {
  policy = "inherit"
}

inherit forwards the effective tenant from the parent run. fixed sends the configured id. none omits the A2A tenant header.

Stream activity

The stream operation emits stateless activity deltas while the downstream task runs. These deltas are A2A-specific and are delivered through the normal tool activity event channel.

Activity types are:

• a2a_task
• a2a_task_status
• a2a_artifact
• a2a_message

The accumulated activity state has this shape:

{
  "target_id": "planner",
  "task_id": "task-123",
  "context_id": "ctx-123",
  "state": "TASK_STATE_WORKING",
  "latest_message": "Drafting plan.",
  "artifacts": []
}

See Connect agents via A2A for a complete guide to outbound A2A delegation.