Skip to main content
Glama

Run agent swarm

run_agent_swarm
Idempotent

Engineer a system with a swarm of agents (ADR 0027): an orchestrator divides the description into subsystems and frozen interface contracts, divides again any subsystem too large for one agent (max_depth levels, default 2), specialists write the subsystems in parallel, and every answer is checked in the context of the whole model, with conflicts sent back to the agent that caused them. With a prompt alone, the result is a new saved model holding the skeleton and one federation proposal per subsystem. With model_id (a saved m_ model), nothing is divided: one agent develops each subsystem the model already has, keeping what is there, and its work is staged as a proposal on that same model; pass subsystem to go one level deeper, decomposing that subsystem's parts, and repeat level by level. The prompt is then optional guidance. Nothing is written until you review and commit each proposal. Paid. Call it directly: it charges what the job uses, never more than its estimated maximum or the max_spend_credits you set. request_id is optional; set one to make a retry safe. Returns job_id immediately. Poll get_job_status for later progress.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "run_agent_swarm"
  }
}

Input Schema

NameRequiredDescriptionDefault
rowsNoOnly for cost_mode "agent_authored" on generate_safety_analysis: {conditions:[{target,description,severity,...}],modes:[{target,mode,severity,occurrence,detection,...}]}; with analysis "stpa": {losses:[{id,description}],hazards:[{id,description,losses}],controllers:[{target,processModel}],controlActions:[{from,to,name,ucas:[{id,type,context,contextVariables,hazards,constraint}|{type,notApplicable,rationale}]}],feedback:[{from,to,name,updates}],constraints:[{id,name,text}]}.
modelNo
studyNo
eventsNo
formatNo
promptNo
stop_sNo
analysisNoFor generate_safety_analysis: fha, fmea, both (default) or stpa. stpa needs no standard.
fidelityNo
model_idNoA model from a generation job (model_ id) or a saved studio model (m_ id); a saved model is read at the head of main.
providerNo
standardNo
cost_modeNomanaged
max_depthNoOnly for run_agent_swarm: levels of division, 1 to 3 (default 2). At 2 and 3, a subsystem the orchestrator judges too large for one agent is divided again inside its frozen boundary.
subsystemNoFor reprompt_agent: qualified name of the subsystem, e.g. "Rover::DriveUnit". For run_agent_swarm on a saved model: the subsystem to decompose one level further (its parts get the agents); leave it out to work on the whole system's subsystems.
request_idNo
scenario_idNo
simulationsNo
specificationNoOnly for cost_mode "agent_authored" on generate_system_model and build_full_system; see those tools for its schema.
simulation_typeNo
max_spend_creditsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / analysis / description
      Added value: +"For generate_safety_analysis: fha, fmea, both (default) or stpa. stpa needs no standard."
    • changedInput schema / properties / analysis / enum
      Previous value: -[
      -  "fha",
      -  "fmea",
      -  "both"
      -]New value: +[
      +  "fha",
      +  "fmea",
      +  "both",
      +  "stpa"
      +]
    • changedInput schema / properties / rows / description
      Previous value: -"Only for cost_mode \"agent_authored\" on generate_safety_analysis: {conditions:[{target,description,severity,...}],modes:[{target,mode,severity,occurrence,detection,...}]}."New value: +"Only for cost_mode \"agent_authored\" on generate_safety_analysis: {conditions:[{target,description,severity,...}],modes:[{target,mode,severity,occurrence,detection,...}]}; with analysis \"stpa\": {losses:[{id,description}],hazards:[{id,description,losses}],controllers:[{target,processModel}],controlActions:[{from,to,name,ucas:[{id,type,context,contextVariables,hazards,constraint}|{type,notApplicable,rationale}]}],feedback:[{from,to,name,updates}],constraints:[{id,name,text}]}."
  2. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Beyond the annotations it discloses cost behavior (paid, charged on usage, capped by the estimate or max_spend_credits), the review-before-write guarantee ("Nothing is written until you review and commit each proposal"), immediate job_id return with deferred progress, and the request_id retry lever. These are exactly the mutation and billing facts an agent needs that annotations alone cannot express.

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

Conciseness3/5

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

The content is dense and mostly earns its place, but it is delivered as one long paragraph of chained clauses rather than separated mode, cost, and lifecycle statements. The ADR reference and heavy inline parentheticals add parsing cost without much decision value.

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

Completeness4/5

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

For a paid, asynchronous, mutation-bearing tool with no output schema, the description covers the essentials: what is produced in each mode, when work is actually written, what is returned immediately (job_id), and how to follow progress. It stops short of naming how proposals are reviewed/committed or what get_job_result yields, leaving a small gap at the end of the workflow.

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

Parameters3/5

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

Schema description coverage is 29% across 21 parameters, so the description carries real load and does define the ones that matter most: model_id (a saved m_ model, nothing divided), max_depth (levels of division, 1–3, default 2), subsystem (decompose one level further, prompt becomes optional guidance), max_spend_credits and request_id. It says nothing about the remaining parameters, several of which belong to unrelated tools and are left for the agent to infer should be omitted.

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?

"Engineer a system with a swarm of agents" names a specific verb and resource, and the description immediately separates the two operating modes (prompt-only produces a new saved model plus federation proposals; model_id develops each existing subsystem and stages proposals on that same model). This is far more than a restatement of the name and lets an agent predict the outcome shape before opening the schema.

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?

It gives explicit mode-selection rules (with a prompt alone vs. with model_id, and pass subsystem to go one level deeper and repeat level by level) and states the follow-up action: "Poll get_job_status for later progress." It does not, however, say when to pick this over the model-generating siblings build_full_system or generate_system_model, which an agent must decide between.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources