Skip to main content
Glama

ask_all

Send one prompt to multiple AI models in parallel and compare their labeled answers side by side. Add discussion rounds to surface disagreement and refine the council's conclusions.

Instructions

Ask several members the SAME prompt in parallel, returning their answers side by side and labeled by model.

By default every configured member answers. Pass models to ask only some of them; the schema lists the valid ids.

rounds (1-3, default 1) runs a real discussion. With rounds=2 the members first answer independently, then each is asked again — this time carrying the question plus every answer from round 1, its own and the others', verbatim — and asked to revise. Members are stateless, so carrying the previous round back to them is the whole mechanism: without it a second round is just the same question asked twice. The transcript returns round by round, so you can see who moved and who held their ground.

One round is a survey of opinion. Two is worth the extra latency and tokens when the answers are likely to disagree and the disagreement is the interesting part.

rounds is chosen before anything has been asked, which is the one thing wrong with it: you commit to a second round without having read the first, and a council that turns out to agree costs exactly what one still arguing would. When you would rather look first, ask with rounds=1 and then call revise with the answers — it runs one more round on demand, as many times as you judge it worth, and it has no ceiling. Reading before you buy is usually the cheaper of the two: one more round is another full call per member, while revise costs you only the answers written back into it.

guests seats answers you already have. If you spawned a subagent on this same question, or formed your own view first, pass it here as {label, text} and it joins the table: it appears in round 1 beside the members, and from round 2 the members are shown it verbatim and argue with it. This is the difference between an answer that is in the discussion and one that is merely next to it — without it, the models never learn your subagent had an opinion. Pass the text verbatim, not a summary; a summary is not what you want critiqued.

A guest speaks once and does not revise, so it appears in round 1 only. The transcript says so, and says it is not a retraction. From round 2 the members are told to answer its strongest point rather than pass over it: a seat that cannot restate itself is the one a discussion drops by default, and dropping it reads in the transcript exactly like answering it.

steelman seats a standing objection. A council mostly agrees, and its agreement is the least informative thing it produces — the strongest case against a plan is not volunteered by members who think the plan is fine. Pass {} and one member writes that case each round, against whatever the table has converged on, and it goes back to everyone as an ordinary anonymous answer:

ask_all(prompt, rounds=3, steelman={})

Note what is and is not assigned. No member is told to argue a side it does not hold, so what the members say is still what they think; the assignment lives in one extra call they are not told about, and they answer it as they answer any other seat. It speaks every round rather than once, because an objection that cannot reply to its own rebuttal is quoted rather than represented, and by the third round the table is arguing with its paraphrase of it. tenure buys fewer rounds than that, and when the seat is retired early the transcript says it was retired by configuration rather than answered — an unexplained silence reads as a position abandoned. You are told what the seat was and who wrote it; the members are not, because a model that knows an argument was commissioned discounts it instead of answering it. Read what it says as the strongest objection this council can produce to order, never as evidence that anyone holds it.

Members may carry different weights — how much this council trusts each one. When they do, every answer is labeled with its weight and the transcript ends with the ranking and how to read it. The members are never told each other's weights; a model told it is outranked stops arguing, and its dissent is what you came for.

materials hands the council the thing the question is about — a spec, a log, a diff, a screenshot — instead of you pasting it into prompt. Give {path, label} for a file, or {text, label} for something with no file behind it. Prefer a path: the members are then handed the file's exact bytes rather than your reproduction of them, you do not spend a copy of the whole document writing this call, and every member and every round get an identical copy, which is both what makes their answers comparable and what an endpoint's cache can match. Images go this way too, and are the case that matters most: describe a screenshot in prose and every member inherits the same description, so anything you misread is misread by the whole council at once. It is carried into every round for you, so a discussion about one document costs you the path once.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
guestsNo
modelsNo
promptYes
roundsNo
systemNo
steelmanNo
materialsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Install Server

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries full disclosure burden and meets it. It reveals hidden mechanics: members are stateless, round 2 only works because previous answers are carried back verbatim, steelman assignments are hidden from members, and weights are never shared. It also states what the transcript will and won't say (e.g., a retired steelman is labeled as retired by configuration, not as a retraction).

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 long but deliberately organized: it front-loads the core behavior, then devotes one section to each advanced feature in a consistent order. Some conceptual rationale could be trimmed, but for a seven-parameter tool with this many interaction effects, the length earns its place.

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 and the presence of an output schema, the description covers the full decision space: defaults, rounds mechanics, guest behavior, steelman tenure and concealment, weights, and material handling. Nothing an agent needs to decide whether to call it or how to shape a call is left unexplained.

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?

The description adds substantial meaning beyond the 0%-coverage schema for `models`, `rounds`, `guests`, `steelman`, and `materials`, including defaults and interaction effects. However, it never mentions the `system` parameter, and the guest `weight` field is absent from the prose even though it exists in the schema, leaving small gaps that the schema cannot fill at 0% coverage.

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 first sentence names a specific verb and resource — 'Ask several members the SAME prompt in parallel' — and states the output shape ('answers side by side and labeled by model'). This clearly separates it from siblings like `ask` and `revise` without needing to open their schemas.

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

Usage Guidelines5/5

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

The description gives explicit decision rules: one round is a survey, two rounds are for disagreement, and 'when you would rather look first, ask with rounds=1 and then call revise'. It also tells when to use `guests` (answers already obtained elsewhere) and `steelman` (a council that mostly agrees), so an agent can route itself correctly.

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

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/Totti0135/model-council'

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