Skip to main content
Glama

run_agent

Execute a task via a pooled agent, with subagents, findings tool, and dynamic capabilities. Start new or resume existing sessions.

Instructions

Run the pooled agent live and record every agent that participates. The entry's first-ever run starts a fresh session; later runs resume it. Requires the claude CLI at runtime.

Every run is granted the full capability set — for the main agent and, when named, for each dispatched subagent: fan-out subagents (resolved from their own pool entries and wired in via with_subagents), the run-scoped findings-writer (with_findings_tool), and dynamic capability acquisition (with_acquire_tool). The findings tool needs the run id at wiring time, so the run is started here and its id handed to run_with_capture rather than minted inside it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
taskYesWhat the generated agent should do — the job it is being built to perform.
agent_keyYesStable external identifier for the pooled agent a caller manages — assign your own scheme (a ticket id, a slug, a UUID, anything meaningful to your use case). The pool's logical lookup key; distinct from the human-readable display name, and distinct from the harness's per-dispatch `AgentId`.
resume_agent_idNoWhen set, continue one specific previously-dispatched subagent (its `AgentId`, captured from an earlier `RunOutcome.agent_runs[i].agent_id`) rather than just re-prompting the main agent: this run resumes the main session, is granted the harness's `SendMessage` tool (`with_agent_resume`), and its literal turn wraps `task` as `"Resume agent {id} and now: {task}"` — while the run record still logs `task`. It composes with `subagent_agent_keys`, since the resumed turn may dispatch further subagents too.
subagent_agent_keysNoA subagent name → pooled `agent_key` mapping; each referenced entry's spec is wired in as a dispatchable subagent that also carries the findings and acquire tools. Empty runs the agent solo.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
runYesOne invocation of a pooled agent — appended when a run starts and stamped when it finishes. Distinct from `PoolEntry`'s "current state per problem" role: an entry has many runs over its life. `finished_at` and the outcome fields (`output`, `structured_output`, `total_cost_usd`, `error`) stay None while the run is in flight, and the outcome fields stay None afterward too if the run finished without a captured outcome. `error` is set instead of the outcome fields when the run raised rather than completed.
outputYesThe collected assistant text of a finished run, persisted on its record; text over 200000 characters is truncated to that bound.
agent_runsYes
total_cost_usdNo
structured_outputNo
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses behavioral traits: recording participants, session start/resume, full capability set, findings tool wiring, and resume_agent_id behavior. It covers both simple and complex runs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is information-dense and front-loaded with the core purpose. While it is a single paragraph, it is well-structured and every sentence contributes meaning. Could be slightly more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (4 parameters, nested objects, output schema), the description covers session lifecycle, tool wiring, and parameter interactions comprehensively. It addresses edge cases like resume and subagents.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining how parameters like resume_agent_id and subagent_agent_keys interact with the overall run mechanism, beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool runs a pooled agent, records participant agents, and distinguishes between first-run and resumed sessions. It includes a requirement (claude CLI) and differentiates from sibling tools like create_agent and list_agents.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the tool (to run a pooled agent), describes session behavior, and outlines the granted capabilities. It does not explicitly exclude alternative tools, but the context makes usage clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Magic-Man-us/claude-sdk-agent-fleet'

If you have feedback or need assistance with the MCP directory API, please join our Discord server