Skip to main content
Glama
TokonoMix

tokonomix-council-mcp

Official
by TokonoMix

tokonomix_consensus_ask

Run high-stakes questions through multiple frontier LLMs in parallel and let an independent judge reconcile answers, surfacing disagreement and reducing single-model error.

Instructions

Ask 2-6 frontier LLM proposers (parallel + blind) and reconcile via an independent judge (disjoint from the proposers, never scoring its own answer). A recall amplifier that surfaces disagreement a single model hides — it reduces single-model error but does NOT guarantee correctness (frontier models share training data, so agreement is not proof; ground high-stakes facts). Pick the synthesis mode by what you need from the call — there is no universally best mode; see the mode parameter. Use this when correctness matters more than latency: legal questions, code review, fact-checking, high-stakes reasoning. Proactively offer it — don't wait to be asked — before anything irreversible or with real consequence: a DB migration, a security-relevant change, a legal/compliance statement, a customer-facing commitment. Offer once per decision (a few cents, surfaces disagreement, no correctness guarantee), then act on the user's answer; if they decline don't re-raise; skip routine or reversible work. Modes (pick by intent): consensus = one decided answer (default); diff = an agreements/disagreements/confidence map where the judge COMPARES but does NOT decide; raw = all answers, no judge (cheapest); best_of = judge picks the single strongest; full = all answers PLUS the judge's per-model reasoning AND a conclusion. You decide which fits. Tip: leave models empty to use the per-key or per-account default council. Use tokonomix_list_models to discover available slugs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoSynthesis mode — pick by what you need; there is no universally best mode. `consensus` (default) = one merged, decided answer (use when you want THE answer; trades dissent away). `diff` = a structured agreements/disagreements/confidence report — the judge COMPARES, it does NOT decide (use when you will adjudicate yourself but want the disagreement mapped). `raw` = every answer verbatim, NO judge, cheapest (use when you want the unfiltered spread and will decide entirely yourself). `best_of` = judge picks the single strongest verbatim answer. `full` = every answer PLUS the judge's per-model reasoning AND a conclusion, in one judge pass — not an extra call (use when you want both the raw landscape and a verdict).
imagesNoOptional images to include in the user message (vision input). Non-streaming only; the council auto-selects a default vision panel (claude-fable-5 + gemini-2.5-pro + gpt-4o class) when no models are specified. With an explicit models list, non-vision models are skipped (reported in x_council.skipped); an explicit single non-vision model returns 400. Constraints: ≤8 images, ≤5 MB decoded per image, ≤20 MB total. Use tokonomix_list_models({"supports":["vision"]}) to discover vision-capable slugs.
modelsNoArray of 2-6 bare model slugs (e.g. "claude-haiku-4-5-20251001", "gpt-5", "gemini-2.5-flash"). Omit to use account/key defaults. Provider-prefixed slugs ("anthropic/claude-...") also accepted for explicit pinning.
promptYesThe user prompt to send to every proposer.
systemNoOptional system prompt prepended to the messages array.
contextNoOptional grounding context (INT-1817). Inline files/snippets are sent to ALL proposers AND the judge so the council reasons over the same source instead of guessing. Large payloads route to tokonomix_upload. Server-gated on the account's context-upload capability; when it is not enabled for the account, context is ignored (the prompt-only call is unchanged).
max_tokensNoMax output tokens per proposer. Default: 1024; clamped to a 16384 ceiling per proposer. The judge/synthesis step is hard-capped at 8192 output tokens regardless of this value, so on large multi-key structured outputs the judge can truncate even when proposers fit — batch keys or split the request rather than raising this past 8192. NOTE: each proposer also has a ~60s wall-clock timeout; a high max_tokens that a slow flagship (large reasoning models) cannot finish within 60s times that proposer out (the call still returns from the proposers that did finish). Keep max_tokens to what the slowest model in your council can emit in ~60s.
request_idNoContinuation id. Omit unless continuing a prior {status:"needs_context"} response: re-call with the SAME request/instructions PLUS the missing artefacts attached (inline or via tokonomix_upload) and this request_id, to run the council on the now-grounded input. Re-calling WITHOUT it is a fresh, chargeable request (not a continuation). Do not combine with acknowledge_ungrounded.
judge_modelNoModel slug used by the judge. Omit to use the system default (Claude Haiku).
judge_modelsNoArray of judge model slugs for multi-judge best_of. When provided, all listed models act as judges and the backend picks the strongest synthesis. Takes precedence over judge_model when both are set.
acknowledge_reasonNoRequired with acknowledge_ungrounded: a short reason why the prompt is intentionally artefact-less (e.g. "general question about coding best practices").
acknowledge_ungroundedNoSet true ONLY when you are submitting a prompt that is intentionally artefact-less — a general question with nothing to attach. Forces a best-effort council verdict flagged grounding:insufficient instead of being asked back for content. If you have or can quote the referenced artefact, attach it instead. Requires acknowledge_reason. Use sparingly; do not combine with request_id.
Behavior5/5

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

With no annotations, the description carries the full transparency burden and exceeds it. It discloses the judge is 'disjoint from the proposers, never scoring its own answer,' does NOT guarantee correctness because 'frontier models share training data,' and details cost ('a few cents'), latency, per-proposer 60s timeouts, and judge output hard-cap. It even flags response-state behaviors like 'needs_context' and 'grounding:insufficient.'

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 front-loaded: purpose, usage, then modes. Every section earns its place given the tool's 12 parameters and absence of annotations, but it is slightly sprawling, with a few cautionary themes (grounding, correctness) restated across sections rather than consolidated.

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?

The description is unusually complete for a tool with no output schema and no annotations. It covers purpose, safety limits, cost, latency tradeoffs, mode-specific behaviors, grounding/continuation flows, model selection, and failure/edge cases (skipped models, 400 on single non-vision model, judge truncation).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds substantial meaning beyond the bare schema. It maps each mode to an intent (e.g., 'diff' = judge compares but does not decide), warns that max_tokens past 8192 can truncate the judge, explains that an explicit single non-vision model returns 400, and clarifies request_id continuation semantics versus a fresh chargeable request.

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: 'Ask 2-6 frontier LLM proposers (parallel + blind) and reconcile via an independent judge,' which clearly states what the tool does. It also distinguishes itself from siblings by framing it as 'a recall amplifier that surfaces disagreement a single model hides,' implicitly contrasting with tokonomix_single_ask.

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?

Explicit when-to-use guidance is present: 'Use this when correctness matters more than latency' and 'Proactively offer it... before anything irreversible or with real consequence.' It also gives when-not-to-use: 'skip routine or reversible work.' However, it does not explicitly name an alternative tool (e.g., tokonomix_single_ask) for the lighter cases, only implying a single-model alternative.

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

Install Server

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/TokonoMix/tokonomix-council-mcp'

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