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.

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.

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.

tool "weather" {
  kind         = "python"
  source       = "./tools/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 sandboxed shell interpreter. Host programs, filesystem access, environment variables, and network access are all individually controlled.

tool "shell" {
  kind     = "bash"
  commands = ["git"]

  env {
    kind = "inherit"
  }

  limits {
    max_execution_time_secs = 30
  }
}

fs block

env block

limits block

All fields are optional and fall back to the interpreter's built-in defaults when absent.

network block

See Use the bash tool for more detail and 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.

tenant block

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.