Skip to main content
Glama
PyModel
by PyModel

delegate_many

Fan one question out to several models for a council with a disagreement report, or fan several sub-tasks to one model. Queues behind a shared concurrency cap so it doesn't stampede quota.

Instructions

Fan one question out to several models at once (a council, with a disagreement report), or fan several sub-tasks out to one model. Runs behind the same concurrency cap as everything else, so it queues rather than stampedes the shared quota.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cwdNoAbsolute path to the working directory / project root. Defaults to the server's cwd.
dirsNoExtra directories to add to agy's workspace, for cross-repo or worktree-vs-base analysis.
modelNoOverride the model. Accepts a display name ("Gemini 3.8 Flash (High)"), an id ("gemini-3.8-flash-high"), or a family selector ("gemini-pro@latest-high"). Normally omit — the tool routes automatically.
tasksNoSeveral prompts to run, each as its own delegation (at most 8).
effortNoReasoning tier. Gemini models carry their tier in the name, so this switches to the sibling model at that tier (Flash (High) -> Flash (Medium)); agy's own --effort flag only reaches models without a tier. Defaults to the user's set_model choice, else the tool's own tier.
modelsNoModels to ask with `prompt` (at most 8). Defaults to a Flash/Pro/Opus council.
promptNoOne prompt to send to every model in `models`.
slash_commandsNoLet agy expand your slash commands and skills into the prompt. Off by default: a hostile file in the workspace can otherwise steer the delegated model.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed17 schema fields changedv3.1.0
    • addedInput schema / properties / cwd / minLength
      Added value: +1
    • addedInput schema / properties / dirs / items / minLength
      Added value: +1
    • addedInput schema / properties / dirs / maxItems
      Added value: +256
    • addedInput schema / properties / model / maxLength
      Added value: +512
    • addedInput schema / properties / model / minLength
      Added value: +1
    • addedInput schema / properties / model / pattern
      Added value: +"^[^-]"
    • changedInput schema / properties / models / description
      Previous value: -"Models to ask. Defaults to a Flash/Pro/Opus council when `prompt` is used, and to the automatic route when `tasks` is used."New value: +"Models to ask with `prompt` (at most 8). Defaults to a Flash/Pro/Opus council."
    • addedInput schema / properties / models / items / maxLength
      Added value: +512
    • addedInput schema / properties / models / items / minLength
      Added value: +1
    • addedInput schema / properties / models / items / pattern
      Added value: +"^[^-]"
    • addedInput schema / properties / models / maxItems
      Added value: +8
    • addedInput schema / properties / models / minItems
      Added value: +1
    • addedInput schema / properties / prompt / pattern
      Added value: +"\\S"
    • changedInput schema / properties / tasks / description
      Previous value: -"Several prompts to run, each as its own delegation."New value: +"Several prompts to run, each as its own delegation (at most 8)."
    • addedInput schema / properties / tasks / items / pattern
      Added value: +"\\S"
    • addedInput schema / properties / tasks / maxItems
      Added value: +8
    • addedInput schema / properties / tasks / minItems
      Added value: +1
  2. Addedv2.1.0

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden, and it does disclose a real trait: it runs behind the shared concurrency cap and queues rather than saturating quota. However it omits failure semantics (partial failures across N delegations), relative cost/latency, and how results and the disagreement report are returned — meaningful gaps for an 8-param fan-out tool.

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

Conciseness5/5

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

Two tightly written sentences, both front-loaded with the most decision-relevant information (the two modes) followed by the queueing constraint. Nothing is redundant or padded.

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 tool with a fully documented 8-param schema and no output schema, the description covers the essential decision context: the two invocation modes and the concurrency behavior. It stops short of describing how a council's disagreement report is surfaced or how errors are aggregated, which the schema cannot supply.

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 100%, so the schema already explains every parameter (cwd, dirs, model, tasks, models, prompt, effort, slash_commands). The description adds no parameter-level guidance and notably never states that the `prompt`+`models` mode is mutually exclusive with the `tasks` mode, so it does not exceed the baseline.

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

Purpose4/5

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

The description gives a concrete verb and resource ('fan one question out to several models', 'fan several sub-tasks out to one model') and covers both operating modes, which is the key differentiator from the singular `delegate` sibling. It never names `delegate` explicitly, so the routing boundary is inferred rather than stated.

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 clearly states the two conditions that select this tool: one question to many models (council), or many sub-tasks to one model. There is no explicit 'when not to use this / use delegate instead' statement, so the exclusion is left to inference.

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