Skip to main content
Glama

consensus

Read-only

Structured multi-model debate for complex decisions: consult models with for/against stances, capture findings, and synthesize a consensus recommendation.

Instructions

Builds multi-model consensus through systematic analysis and structured debate. Use for complex decisions, architectural choices, feature proposals, and technology evaluations. Consults multiple models with different stances to synthesize comprehensive recommendations.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stepYesConsensus prompt. Step 1: write the exact proposal/question every model will see (use 'Evaluate…', not meta commentary). Steps 2+: capture internal notes about the latest model response—these notes are NOT sent to other models.
imagesNoOptional absolute image paths or base64 references that add helpful visual context.
modelsNoUser-specified roster of models to consult (provide at least two entries). User-specified list of models to consult (provide at least two entries). Each entry may include model, stance (for/against/neutral), and stance_prompt. Each (model, stance) pair must be unique, e.g. [{'model':'gpt5','stance':'for'}, {'model':'pro','stance':'against'}]. When the user names a model, you MUST use that exact value or report the provider error—never swap in another option. Use the `listmodels` tool for the full roster. Top models: gemini-2.5-pro (score 100, 1.0M ctx, thinking, code-gen); gemini-3-pro-preview (score 100, 1.0M ctx, thinking, code-gen); gemini-2.5-flash (score 61, 1.0M ctx, thinking); gemini-2.0-flash (score 56, 1.0M ctx, thinking); gemini-2.0-flash-lite (score 42, 1.0M ctx).
findingsYesStep 1: your independent analysis for later synthesis (not shared with other models). Steps 2+: summarize the newest model response.
step_numberYesCurrent step index (starts at 1). Step 1 is your analysis; steps 2+ handle each model response.
total_stepsYesTotal steps = number of models consulted plus the final synthesis step.
relevant_filesNoOptional supporting files that help the consensus analysis. Must be absolute full, non-abbreviated paths.
continuation_idNoUnique thread continuation ID for multi-turn conversations. Works across different tools. ALWAYS reuse the last continuation_id you were given—this preserves full conversation context, files, and findings so the agent can resume seamlessly.
model_responsesNoInternal log of responses gathered so far.
next_step_requiredYesTrue if more model consultations remain; set false when ready to synthesize.
current_model_indexNo0-based index of the next model to consult (managed internally).
use_assistant_modelNoUse assistant model for expert analysis after workflow steps. False skips expert analysis, relies solely on your personal investigation. Defaults to True for comprehensive validation.
Behavior3/5

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

Annotations already declare readOnlyHint=true, indicating no state modification. The description adds that the tool consults multiple models, which implies external calls but does not detail potential costs, rate limits, or other side effects. There is no contradiction with annotations.

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 three concise sentences front-loaded with the core action. Every sentence adds value with no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the multi-step consensus process and lack of an output schema, the description gives a general idea but omits procedural details and return value format. It does not fully prepare users for the step-based workflow evident in the input schema.

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

Parameters3/5

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

With 100% schema description coverage, the input schema already thoroughly explains each parameter. The tool description provides a high-level overview but does not add significant new semantic information beyond the schema.

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 clearly states the tool's purpose: building multi-model consensus through analysis and debate. It lists specific use cases like complex decisions, architectural choices, feature proposals, and technology evaluations, effectively distinguishing it from sibling 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 provides clear guidance on when to use the tool for complex decisions and evaluations. However, it does not explicitly mention when not to use it or direct users to alternative tools, though the context is sufficient for appropriate use.

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/bigl34/pal-mcp-server'

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