Skip to main content
Glama

list_council

Lists every council member's id, label, model, weight, endpoint, call budget, and readiness, so you know which ids to use with ask/ask_all or can spot configuration issues.

Instructions

List the council's members: their ids, labels, target models, weights, wire format, endpoint, call budget, and whether each one is ready to answer.

weight is how much this council trusts each member, relative to the others; everyone is 1 unless the roster says otherwise, and ask_all reports it alongside the answers whenever they differ.

tries is how many attempts a call gets and how long each may take, so a member that is slow or that keeps being retried is visible here.

sees is whether this member may be shown an image in materials. The line above the table says whether this server will read materials paths at all, which depends on how its operator runs it.

route is how this member reaches its endpoint — env follows the proxy in the server's environment, direct ignores it, and a URL is a proxy set for that member alone. It appears only when the members can differ; passwords in a proxy URL are masked.

A member may have backups: further endpoints for the same seat, indented under it as ↳ backup 1, ↳ backup 2 and tried in that order when the one above does not answer. They are the same member — same id, same label, one vote — so you never address a backup directly; the seat's id reaches whichever of them is up. Read their model column: a backup is often the same model under a different id, and sometimes not the same model at all, and ask_all names the one that actually answered above each answer.

Cheap and local — makes no network calls. Use this to find out which ids you may pass to ask and ask_all, or to explain a configuration problem.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Install Server

TDQS

A4.7/5.0
Behavior5/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 does so thoroughly. It discloses that the tool makes no network calls, explains the meaning of each output field, and covers edge cases like backups, proxy routing, password masking, and conditional columns.

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 long but each paragraph explains a distinct cluster of output fields and edge cases. It front-loads the core action and field list, then uses compact and consistent formatting for backups, routing, and usage guidance.

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?

For a tool with no parameters and an output schema, the description is complete: it names every visible field, defines non-obvious values, explains backup behavior and proxy routing, and gives concrete use cases. There are no meaningful gaps an agent would need filled to call it correctly.

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 input schema has zero parameters and 100% schema description coverage trivially, so there is no parameter semantics for the description to add. The baseline of 4 for zero-parameter tools applies, and the description does not need to compensate.

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 opens with a specific verb and resource: "List the council's members" and enumerates the exact fields returned. It also positions itself against siblings by saying it reveals which ids may be passed to ask and ask_all, so an agent can distinguish it from the other tools.

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 gives clear usage context: "Cheap and local — makes no network calls" and "Use this to find out which ids you may pass to ask and ask_all, or to explain a configuration problem." It names the relevant alternatives, though it does not explicitly spell out when not to use it.

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