Skip to main content
Glama

revise

Continue a council discussion by feeding each member the previous round's answers and asking them to update their positions. Use when you want another round of cross-critique after reading the first results.

Instructions

Run ONE more round of an existing discussion: show every member what was said last round and ask it to revise.

This is ask_all's rounds turned inside out, so that you can drive them. Two reasons to want that.

You would rather decide after reading. ask_all(rounds=2) commits to the second round before the first one exists. Ask with rounds=1, read what comes back, and call this only if the disagreement is worth another call per member — or call it three more times if they are still moving. There is no round ceiling here, unlike ask_all, because every round is one you chose to pay for.

A voice in the discussion is one only you can produce — a subagent you spawned, or your own answer — and you want it to be a full member rather than a one-off: something that answers, reads the others, and revises alongside them.

The loop, in the second case:

  1. ask_all(prompt) — the members answer round 1 ...and you produce your subagent's round-1 answer yourself

  2. revise(prompt, answers=[...]) — pass EVERY round-1 answer, the members' and your subagent's; the members come back revised ...and you re-run your subagent on the same material

  3. repeat as long as it is still moving

Each entry in answers is {text, model} for a member's own answer, or {text, label} for an outside one. Naming the member matters: that is what lets it see its previous answer as its own and revise, instead of answering fresh.

round is which round the answers you are passing came from, so the members are told where they are. Pass answers verbatim, never summarised.

Pass the same materials you passed to ask_all, every round. The members are stateless: a document they were shown last round does not exist for them in this one, and a council revising from memory it does not have will revise from the other answers alone.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
roundNo
modelsNo
promptYes
systemNo
answersYes
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 provided, the description carries the full burden and delivers: it discloses that members are stateless, that answers must be passed verbatim, that model-named answers are shown back as the member's own so they revise rather than start over, and that each round is paid for. It also walks through the expected loop so an agent knows exactly what will happen.

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?

The description is longer than average but earns its length with dense, useful information: a summary sentence up front, two motivating use cases, a numbered loop, and parameter-specific warnings. Every paragraph adds value, and the structure makes navigation easy.

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?

Given the tool's complexity, lack of annotations, and zero top-level schema coverage, the description covers almost everything needed to call it correctly: when to use it, how to construct `answers`, what to pass every round, and the statelessness caveat. The only gap is the undocumented `models` and `system` parameters, which keeps it just short of fully complete.

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 top-level schema has 0% description coverage, so the description compensates well for the key parameters: `answers`, `round`, `materials`, and `prompt` all receive operational meaning. However, `models` and `system` remain undocumented, so the compensation is not complete.

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 states the exact action: 'Run ONE more round of an existing discussion: show every member what was said last round and ask it to revise.' This clearly distinguishes it from ask_all (which commits to rounds in advance) and ask (one-off), and the rest of the description reinforces that distinction.

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 explicitly contrasts with ask_all: 'This is ask_all's rounds turned inside out' and explains two concrete use cases: deciding after reading each round, and injecting a subagent or one's own voice as a full member. It also gives the loop steps and notes there is no round ceiling unlike ask_all. This is exemplary when-to-use guidance.

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