The Wisepanel MCP Server orchestrates multi-AI deliberations where panels of 6–30 AI agents (Claude, GPT, Gemini, Perplexity, etc.) debate complex questions from opposing perspectives. This surfaces objections, alternatives, and hidden assumptions, delivering auditable, disagreement-surfacing insights for high-stakes decisions. Key capabilities include: starting a deliberation with customizable parameters (panel size, model groups, number of rounds, optional reasoning audits, web search verification, context); rewriting biased questions for neutral framing; polling live results to watch arguments develop; retrieving full results post-hoc; canceling runs; publishing completed deliberations to the public Wisepanel Commons; and listing all session runs. It integrates with MCP clients like Claude Code for seamless use.
Integrates Google's AI models to participate in structured deliberation panels across multiple rounds.
Allows for the selection of OpenAI models to serve as agents in the Wisepanel multi-agent deliberation platform.
Provides access to Perplexity's search-augmented models for informed, real-time deliberation and panel discussions.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Wisepanel MCP Server start a deliberation on the impact of universal basic income"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The decision-intelligence layer between frontier models and high-consequence decisions.
Wisepanel takes a question, builds a panel of AI agents around it, and has them argue it out. You get back the positions that survived the argument, the reasoning behind each one, and the disagreements that never resolved.
This MCP server exposes that to Claude Code and any MCP-compatible client.
A single model gives you one answer, fluently, whether or not it is right. That is fine for most questions. It is a bad property for the ones where being wrong is expensive.
The failure usually isn't ignorance. A model commits to a framing early and then argues for it, so you never see the objection, the alternative, or the assumption doing the work. Ask again and you get the same framing in different words. Ask three models separately and you get three confident answers with no way to choose between them.
Related MCP server: AgentDebate MCP Server
Wisepanel builds disagreement in deliberately, at three levels.
One — each agent is handed a conflict to resolve. Roles are derived from your question, and each is defined by two forces that genuinely oppose each other: cost against access, speed against safety, proven against new. The agent can't champion one side. It has to reach a position that answers both, so it arrives with something worked through rather than a talking point.
Two — every agent resolved a different conflict, so their positions don't match. The agent holding cost against access lands somewhere the one holding speed against safety does not. These aren't two sides of an argument. They are several honest resolutions of the same question that disagree about what mattered most, and between them they cover the ground the question actually occupies.
Three — the structure makes them contend. Agents are placed on the edges of a polyhedron, so each one works at two vertices — two separate conversations. At its second vertex an agent is not merely a participant but a delegate from the first, instructed to represent what its co-participants concluded there alongside its own position. Every vertex therefore hears whole conversations it was not part of, argued by someone who was.
That last part is what makes a small panel go further than its headcount. Six agents means twelve seats, and each seat imports another discussion — so a point raised anywhere reaches the entire panel within a few hops, with no aggregator, no summarizer and no bottleneck. Speaking order is balanced, so no agent frames the discussion first or takes the last word. Details.
Pasting the same question into Claude, GPT and Gemini is a real technique, and it works for a real reason: different labs train on different data with different methods, so their priors genuinely differ. Wisepanel does the same thing — roles are spread across Anthropic, OpenAI, Google and Perplexity by default, so no single lab's blind spots go unchallenged.
But the model is only one of the places bias enters. There are four, and doing it by hand reaches one.
Your framing goes to everyone unchanged. You paste the same words three times, so you
sample three training substrates against a single reading of the question. When the question
carries an assumption — and questions about decisions usually do — you get three confident
answers to the wrong question.
wisepanel_magic_prompt rewrites the framing before the panel sees
it.
Each model answers as itself. You get Claude's median take, GPT's median take, Gemini's median take, and medians cluster. A model asked a neutral question gives a balanced answer; it will not volunteer the strongest case against your plan, because that isn't what it was asked for. Assigning a role changes what the model is optimising for, which produces arguments none of them offer unprompted.
Bouncing answers between models makes anchoring worse, not better. Feed A's response to B and B now reasons inside A's framing — models tend to accept a stated position and refine it rather than discard it and start over. So the sequential version is more biased than three independent queries, and whichever model you happened to open first sets the terms. Wisepanel balances speaking order and spreads the conversation across vertices precisely so no single position gets to be the one everyone reacts to.
The reconciliation lands on you. Three answers arrive; nothing has compared them. You do that work yourself, with your own priors, usually at the end of a long day on a decision you already lean one way about. A panel does the contending first and hands you what survived it.
Then there is the part that doesn't scale by hand. Three models is three samples. A panel is 6 to 30 roles chosen to span the question, each holding an opposition, each carrying a second conversation to its other vertex — twelve seats at the smallest size. You are not going to hand-run that, and you are certainly not going to do it consistently on every decision that deserves it.
Where doing it by hand wins: it's free, it's immediate, and you keep complete control of the wording. For most questions that is the right trade. This is for the ones where it isn't.
The question is checked for bias first.
wisepanel_magic_prompt rewrites loaded framing, embedded
assumptions and false binaries before the panel sees them. A biased question produces a
confident answer to the wrong thing.
Reasoning is auditable. Agents attribute claims, surface assumptions and flag each
other's gaps — on by default. See show_and_audit_reasoning.
Claims can be checked against sources. Optional native web search verifies dates,
citations, figures and rules instead of trusting recall. See
web_search_enabled.
When being wrong is expensive — architecture calls you'll live with for years, migrations, security and privacy trade-offs, vendor selection, anything where you want the strongest case against your instinct before you commit. It is slower and costs more than a single query. That is the trade you are making.
Don't use it for questions with a known answer, or where you would not act differently given a dissenting view.
Runs stream live, so you watch the argument develop rather than waiting for a verdict. Completed deliberations can also be published to the Wisepanel Commons.
Get your API key at wisepanel.ai/settings, then:
claude mcp add wisepanel --scope user \
--env WISEPANEL_API_KEY=wp_sk_ExampleOnly0000-replace-with-your-own-key \
-- npx -y wisepanel-mcpPaste the key exactly as shown on the settings page — the whole wp_sk_… string and
nothing else. Quotes around it are optional and harmless. Do not add a Bearer prefix:
the server sends Authorization: Bearer <your-key> itself, so including it yields
Bearer Bearer wp_sk_… and auth fails.
Restart Claude Code and run /mcp — wisepanel should show as connected.
✔ Connected only means the server process launched. Your API key isn't checked
until the first call, so a bad key still shows as connected. To confirm auth
actually works, run a deliberation and check that it returns a run_id.
This is a stdio server, not a remote one. There is no HTTP endpoint —
claude mcp add --transport httpwill not work no matter what URL you give it. Everything after the--is the command that launches the server locally.
Add to your client's config file — ~/.claude.json for Claude Code, or the
equivalent for Cursor, Windsurf, Claude Desktop, etc.:
{
"mcpServers": {
"Wisepanel": {
"command": "npx",
"args": ["-y", "wisepanel-mcp"],
"env": {
"WISEPANEL_API_KEY": "your-api-key"
}
}
}
}Variable | Required | Default |
| yes | — |
| no |
|
'url' is not a valid URL — the server was added with --transport http.
Remove it and re-add using the stdio command above:
claude mcp remove wisepanel --scope userWISEPANEL_API_KEY environment variable is required — the key didn't reach
the server process. Pass it with --env as shown, not as an Authorization
header; headers apply to remote servers only.
API 401 / not authenticated despite a valid key — check the stored value with
claude mcp get wisepanel. It must be the bare wp_sk_… string. A Bearer prefix, a
trailing space, or a partial paste are the usual causes.
Not authenticated — verify the key is active at wisepanel.ai/settings. Keys are secrets: never paste them into chat, issues, or screenshots. If one leaks, revoke and reissue it.
wisepanel_startStart a deliberation. Convenes a panel of AI models to debate a question from assigned perspectives. Returns run_id immediately.
Parameter | Type | Description |
| string (required) | The topic for the panel to deliberate |
| string | Panel size — see Topology. |
| string | See Model groups. Default |
| number | Polyhedron traversals (1-5). Default |
| string | Additional framing context |
| string | Path to a file used as context, for payloads too large to pass inline. Concatenated after |
| string | Context compression: |
| boolean | Request concise panelist responses. Default |
| boolean | Reasoning-quality scaffolding + cross-agent audit. Server default is on — omit to accept it, pass |
| boolean | Let agents verify factual claims via native provider web search. Requires |
Agents sit on the polyhedron's edges, so the agent count is the edge count:
| Polyhedron | Vertices | Agents | Responses per round |
| tetrahedron | 4 | 6 | ~12 |
| octahedron | 6 | 12 | ~24 |
| icosahedron | 12 | 30 | ~60 |
Time and cost scale with agent count — large is 5× small. Escalate when a question needs
more genuinely distinct perspectives, not when you want a better answer from the same ones.
Why edges rather than vertices. Every edge of a Platonic solid is equivalent under the solid's symmetry group, and speaking order is balanced so no agent consistently anchors or consistently gets the last word. There is no hub and no privileged seat. Graph diameter stays small — 1, 2 and 3 respectively — so an insight raised anywhere reaches the whole panel in a few hops. Because each agent sits on an edge, it is simultaneously a participant and a bridge: propagation is a side effect of participation, with no messenger or aggregator role.
Structure | Uniform influence | Fast propagation | Cost |
Hub-and-spoke | ✗ one position frames everything | ✓ | linear |
Chain / round-robin | ✗ anchoring, last-word advantage | ✗ | linear |
All-to-all | ✓ | ✓ | O(n²) |
Polyhedral edges | ✓ | ✓ | linear |
All-to-all buys the same reach and uniformity at quadratic cost. Edge assignment on a regular polyhedron is the structure that gets both at linear cost.
Cost is relative to smart, the default:
Group | Relative cost | Use when |
| 1× (baseline) | default; current flagships (Opus 5, GPT-5.6 Sol, Gemini 3.1 Pro Preview) |
| ~¼× | small models; |
| < 1× | random across all providers; cheaper on average, quality varies seat to seat |
| ~1× | search-capable models incl. Perplexity Sonar; the answer turns on current facts |
| varies | largest context windows — for big context payloads, not better answers |
| ~2× | Claude Fable 5 on every seat; only when maximum capability is explicitly wanted |
Single-provider groups (openai, anthropic, google, perplexity) pin every seat to one
vendor, which removes cross-vendor diversity — usually the point of a panel.
Agents sit on the edges of the polyhedron, not the vertices. Each agent connects two
vertices (conversation nodes) and contributes at both endpoints every round — so
rounds: 1 already produces roughly num_agents × 2 responses.
Rounds are full polyhedron traversals, not chat turns. rounds: 1 is already substantial
deliberation. Use 2+ only when agents need to react to other agents' completed positions —
e.g. a binary strategic decision with sharply opposing arguments.
wisepanel_magic_promptRewrite a question to remove framing that would bias the panel toward a predetermined
answer — loaded wording, embedded assumptions, false binaries — while preserving intent.
Optional pre-step before wisepanel_start.
Parameter | Type | Description |
| string (required) | The question to rewrite, as the user wrote it |
Returns one of three outcomes. The original question is echoed back in every case, so you can always fall back to it:
| Meaning | Billed |
| Rewritten. Response includes | yes |
| Already unbiased — use the original | no |
| No safe rewrite produced — use the original | no |
Show the user both versions and let them choose. The rewrite can shift emphasis in ways they may not want, so it should never be substituted silently. This mirrors the web app, where the transform runs only on an explicit click, behind a cost confirmation, with revert available.
Billed separately from the deliberation, and only when the text actually changes.
wisepanel_pollLong-polls a running deliberation (waits up to 15s for new events). Returns panelist responses as they arrive.
wisepanel_resultRetrieve full results of a completed deliberation. Only needed if you didn't poll it live.
wisepanel_cancelCancel a running deliberation.
wisepanel_publishPublish a completed deliberation to the Wisepanel Commons. Makes it publicly viewable and shareable.
wisepanel_list_runsList all deliberation runs in the current session.
1. wisepanel_start -> returns run_id
2. wisepanel_poll -> (repeat) returns panelist responses as they arrive
3. On completion, poll includes publish_available: true
4. wisepanel_publish -> publishes to Commons, returns public URLVariable | Required | Description |
| Yes | Your Wisepanel API key |
| No | API base URL (defaults to |
git clone https://github.com/ikoskela/wisepanel-mcp.git
cd wisepanel-mcp
npm install
npm run devWisepanel's multi-agent deliberation architecture — including the polyhedral topology and the reasoning-audit and verification subsystems — is the subject of pending US patent applications assigned to QuROI, Inc.
MIT — see LICENSE.
The MIT license covers the client in this repository only. It grants no license, express or implied, to any patent, or to the Wisepanel platform and the methods it implements.
Cancel a running Wisepanel deliberation.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | The run ID to cancel |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Cancel') but does not describe behavioral traits such as whether cancellation is reversible, what happens to the run (e.g., deletion, stopping), permission requirements, rate limits, or response format. For a mutation tool with zero annotation coverage, this is a significant gap, though it minimally indicates a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, with every part contributing essential information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation to cancel runs), lack of annotations, and no output schema, the description is incomplete. It does not cover behavioral aspects like effects of cancellation, error conditions, or return values, which are crucial for safe and effective use. The description alone is insufficient for a mutation tool with no structured support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'run_id' parameter fully documented in the schema. The description does not add any meaning beyond what the schema provides (e.g., no details on run_id format or examples). With high schema coverage, the baseline score is 3, as the description does not compensate but also does not detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Cancel') and target resource ('a running Wisepanel deliberation'), distinguishing it from siblings like 'wisepanel_list_runs' (list), 'wisepanel_poll' (check status), 'wisepanel_publish' (publish), 'wisepanel_result' (retrieve results), and 'wisepanel_start' (initiate). It uses precise verb+resource phrasing without tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('a running Wisepanel deliberation'), suggesting it should be used on active runs, but does not explicitly state when to use it versus alternatives (e.g., vs. 'wisepanel_poll' for status checks or 'wisepanel_result' for completed runs) or provide exclusions (e.g., not for completed runs). It offers basic implied guidance but lacks explicit alternatives or when-not-to-use details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Wisepanel deliberation runs tracked in this session. Returns run_id, status, topic, and panel size for each run.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the tool's read-only nature (implied by 'List') and output structure, but lacks details on behavioral traits like pagination, rate limits, error handling, or session-specific constraints. It adds basic context but misses deeper operational insights.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action ('List all Wisepanel deliberation runs'), followed by scope and output details in a single, efficient sentence. Every word adds value without redundancy, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but minimal. It covers the basic purpose and output fields, yet lacks context on how runs are tracked, what 'session' entails, or potential limitations. For a list tool with no structured metadata, more completeness would enhance usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's function and output. A baseline of 4 is applied as it compensates for the lack of parameters by clarifying the tool's scope and return data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List all Wisepanel deliberation runs') and resource ('tracked in this session'), distinguishing it from siblings like 'wisepanel_start' (create) or 'wisepanel_cancel' (terminate). It specifies the scope ('in this session') and output fields (run_id, status, topic, panel size), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'tracked in this session' and listing return fields, suggesting it's for retrieving existing runs. However, it doesn't explicitly state when to use this tool versus alternatives like 'wisepanel_poll' (check status) or 'wisepanel_result' (get detailed outcomes), leaving some ambiguity in sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll a running Wisepanel deliberation for new events. Long-polls up to 15 seconds, returning immediately when panelist responses arrive. Returns new events since last poll.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | The run ID from wisepanel_start |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does so effectively. It discloses key behavioral traits: the long-polling mechanism ('Long-polls up to 15 seconds'), immediate return condition ('returning immediately when panelist responses arrive'), and state management ('Returns new events since last poll'). This covers timing, triggering, and incremental data retrieval without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by two concise sentences that add critical behavioral details. Every sentence earns its place by providing essential information without redundancy, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (stateful polling), lack of annotations, and no output schema, the description is largely complete. It explains the operation, timing, and data return logic. However, it does not specify the format or structure of returned 'events', which could be important for an agent to process results, leaving a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'run_id' documented in the schema as 'The run ID from wisepanel_start'. The description does not add any additional meaning beyond this, such as format examples or validation rules, so it meets the baseline of 3 where the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Poll a running Wisepanel deliberation for new events') and resource ('Wisepanel deliberation'), distinguishing it from siblings like wisepanel_start (initiates), wisepanel_cancel (terminates), and wisepanel_result (retrieves final results). It precisely defines the tool's function as retrieving incremental updates during an active deliberation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Poll a running Wisepanel deliberation for new events'), implying it should be used during an active deliberation started with wisepanel_start. However, it does not explicitly state when not to use it (e.g., after deliberation ends) or name alternatives like wisepanel_result for final outcomes, which would elevate it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish a completed deliberation to the Wisepanel Commons (wisepanel.ai/commons). Makes the deliberation publicly viewable and shareable. Only works for runs that completed successfully in this session.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | The run ID of a completed deliberation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the tool 'Makes the deliberation publicly viewable and shareable' and has a prerequisite ('Only works for runs that completed successfully in this session'), adding useful context. However, it lacks details on permissions, rate limits, or error handling, leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and outcome, followed by a critical constraint. Both sentences earn their place by providing essential information without redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with no annotations and no output schema), the description is reasonably complete. It covers the purpose, usage context, and outcome, but lacks details on return values or error cases, which would be helpful for an agent invoking it. This slight gap prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'run_id' documented as 'The run ID of a completed deliberation'. The description does not add any additional meaning beyond this, such as format examples or constraints, so it meets the baseline for high schema coverage without compensating further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Publish') and resource ('a completed deliberation to the Wisepanel Commons'), distinguishing it from siblings like 'wisepanel_list_runs' or 'wisepanel_cancel'. It specifies the target platform and the outcome ('publicly viewable and shareable'), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: only for 'runs that completed successfully in this session'. However, it does not explicitly mention when not to use it (e.g., for incomplete runs) or name alternatives like 'wisepanel_result' for viewing results without publishing, which keeps it from a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the full result of a completed Wisepanel deliberation. Only needed if you did not poll the run to completion (e.g., a run from a previous session). If you polled it live, you already have the data.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | The run ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies this is a read-only operation ('retrieve'), which is helpful, but doesn't specify other traits like authentication needs, rate limits, or error handling. The description adds some context about when data is available, but lacks details on response format or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, consisting of two sentences that efficiently convey the tool's purpose and usage guidelines. Every sentence earns its place by providing essential information without redundancy, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, 100% schema coverage, no output schema), the description is fairly complete. It covers purpose and usage well, but lacks details on behavioral aspects like response format or error cases. Since no output schema exists, the description could benefit from mentioning what the 'full result' includes, but it's adequate for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'run_id' parameter documented as 'The run ID'. The description doesn't add any meaning beyond this, such as explaining what a run ID is or where to find it. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieve the full result of a completed Wisepanel deliberation.' This specifies the verb ('retrieve') and resource ('full result of a completed Wisepanel deliberation'), making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'wisepanel_poll' or 'wisepanel_list_runs', which could provide overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: 'Only needed if you did not poll the run to completion (e.g., a run from a previous session). If you polled it live, you already have the data.' This clearly states when to use this tool (for previously completed runs not polled live) and when not to use it (if already polled), effectively distinguishing it from alternatives like 'wisepanel_poll'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a Wisepanel deliberation. Convenes a panel of AI models (Claude, Gemini, Perplexity) to debate a question from assigned perspectives. Returns run_id immediately. After starting, poll with wisepanel_poll every 10-15 seconds. When an agent_response event appears, briefly summarize that panelist's key argument to the user before polling again. Each panelist participates in multiple conversation nodes, so total responses will exceed panel size. When status is "completed", provide a final synthesis of all perspectives, then ask the user if they'd like to publish to the Wisepanel Commons using wisepanel_publish. Do NOT call wisepanel_result after polling — you already have all the data from poll events.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | The question or topic for the panel to deliberate | |
| topology | No | Panel size: small (faster for exploration), medium (balanced speed & coverage), large (slow but thorough). Default: small | |
| model_group | No | Model selection: mixed (random assignment), smart (most intelligent), fast (quick responses), cheap (cost-optimized), informed (search-capable), large (largest context). Or single provider: openai, anthropic, google, perplexity. Default: mixed | |
| rounds | No | Deliberation rounds (1-5). More rounds deepen the debate. Default: 1 | |
| context | No | Additional context to frame the deliberation | |
| compression | No | Context compression: none (higher token usage), moderate (balanced), aggressive (lower token usage). Default: aggressive | |
| short_responses | No | Request concise panelist responses. Default: false |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behaviors: it returns a run_id immediately, requires polling every 10-15 seconds, handles agent_response events with summaries, and indicates completion status triggers a synthesis. It could improve by mentioning error handling or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose and then detailing usage steps. Every sentence adds value, though it could be slightly more streamlined by reducing repetition in polling instructions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (7 parameters, no output schema, no annotations), the description is largely complete, covering purpose, usage flow, and behavioral aspects. It could be enhanced by briefly mentioning the output format or error cases, but it adequately supports agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds no additional parameter semantics beyond what the schema provides, such as explaining interactions between parameters or practical examples, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool 'Start a Wisepanel deliberation' with specific verbs ('convenes', 'debate') and resources ('panel of AI models'), clearly distinguishing it from sibling tools like wisepanel_poll or wisepanel_publish by focusing on the initiation phase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (to start a deliberation) and when not to (e.g., 'Do NOT call wisepanel_result after polling'), and names alternatives for subsequent steps (wisepanel_poll, wisepanel_publish), including polling frequency and event handling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0wisepanel_cancelwisepanel_list_runswisepanel_pollwisepanel_publishwisepanel_resultwisepanel_startScored across 6 tools
Each tool has a clearly distinct purpose with no overlap: start initiates a deliberation, poll monitors progress, result retrieves final data, publish shares it, list_runs shows history, and cancel stops a run. The descriptions explicitly differentiate them, preventing misselection.
All tools follow a consistent 'wisepanel_' prefix with descriptive action suffixes (e.g., start, poll, result), using snake_case uniformly. This predictable pattern makes the set easy to navigate and understand.
With 6 tools, the server is well-scoped for managing Wisepanel deliberations, covering the full lifecycle from start to publish, plus monitoring and cancellation. Each tool earns its place without bloat or gaps.
The toolset provides complete coverage for the deliberation domain: start, monitor (poll), retrieve (result), publish, list runs, and cancel. There are no obvious gaps, enabling agents to handle all expected workflows seamlessly.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for building and testing AI agents with multi-model experimentation and insights.
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.
One MCP endpoint for Claude, GPT & Gemini: 100+ tools + no-code connectors + agent workers.
Hosted MCP server for live public-data APIs and Skills for AI agents.
