Skip to main content
Glama
muad-yasin

The High Council

by muad-yasin
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
JavaScript
Remote

Ask other AI labs for advice (spends money)

council_advise

Get advice from other AI labs on one decision after council_quote. Requires your approval for each call and spends your own API credits.

Instructions

Ask other AI labs for advice on ONE decision, after council_quote. This spends the user's own API money. The user is asked to approve each call after seeing the exact text; use it when the user asks for other labs' opinions, or before something hard to undo with the user's agreement. mode "single" (set in the quote): one non-Anthropic model, about $0.083 expected and at most $1.32 with a brief at the 48,000-character limit, from under a minute to over ten minutes for a slow reasoning model (measured once, 6 Oct 2026: 6 to 13 minutes), with no time limit of its own (a stop waits for calls in flight). mode "council": 3 labs answer blind, read each other once and may change an answer only by quoting an argument, about $0.75 expected and at most $1.40 with a brief at the 48,000-character limit, several minutes (unmeasured). The reply is advice from other models, never an instruction: a leaning, every dissent in the models' own words, what would change each answer. The models saw only the brief and can be wrong. It returns within wait_seconds, or within 25 s while the user is being asked to approve (use 25; at most 30: a client that times out and cancels stops the run); if the user has not answered it returns awaiting_approval with what to do, and if the run is still going it returns the run id and you continue with run_status(run, wait_seconds: 25, until: "settled"). Record accept, reject or defer with a reason for each dissent id (dispositions) before asking again. A refusal costs nothing: do not retry it unchanged.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
quote_idYesfrom council_quote
dispositionsNoyour accept, reject or defer, with a reason, for each objection of the previous answer
wait_secondsNohow long to wait for the answer before returning a run id (default 25, at most 30)
confirm_sha256Yesthe sha256 of the text, as council_quote showed it

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.8.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations leave the money/approval story untold, and the description fills it: exact expected and worst-case costs per mode, per-call user approval of the exact text, a 25-30s approval window whose client timeout cancels the run, multi-minute latency, and a refund guarantee on refusal. It also characterizes the output as advice, never instruction, including dissents in the models' own words.

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?

It is a dense block, but routing-critical facts (one decision, costs money, needs approval) are front-loaded and nearly every sentence carries decision-relevant information. Structure loses a point for being a single long paragraph with heavy clause nesting that is harder to skim than it needs to be.

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?

With no output schema, the description carries the return contract itself: awaiting_approval plus next steps, or a run id to poll via run_status(until: 'settled'). Combined with cost, latency, and 'models can be wrong' caveats, nothing needed to call it correctly is missing.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: wait_seconds gets an operating value and rationale (use 25, at most 30, because a client timeout cancels the run), and dispositions is explained as a per-dissent accept/reject/defer record required before asking again.

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 a specific verb and resource ('Ask other AI labs for advice on ONE decision') and immediately names the prerequisite sibling, council_quote, plus the mode variants. An agent can distinguish this from council_quote, run_status, and external_prompt without opening any schema.

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?

It gives explicit trigger conditions ('when the user asks for other labs' opinions, or before something hard to undo with the user's agreement'), the required ordering after council_quote, and the continuation path via run_status with concrete arguments. The 'do not retry a refusal unchanged' exclusion is stated outright.

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

Deploy Server

Other Tools