Skip to main content
Glama
Platano78

Smart-AI-Bridge

by Platano78
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript

council

Send one prompt to multiple AI backends in parallel and collect their responses for synthesis. Use for architectural trade-offs or controversial decisions where diverse perspectives matter.

Instructions

Pose one prompt to several AI backends in parallel and return all of their responses for Claude to synthesize. Backend selection is driven by topic, which maps to a declared capability rather than to any lane name: the usable lanes declaring that capability are preferred, and the remaining usable lanes fill the rest of the seats. An operator-configured roster for a topic overrides that entirely. confidence_needed controls how many backends are queried — high (4), medium (3), low (2). Use for architectural trade-offs, controversial calls, or anywhere dissent surfaced cheaply (~1-2s for 2-3 backends) is more useful than a single answer. For a single backend query, use ask. Read-only: makes N parallel HTTP calls; never writes to disk. Returns: {success, topic, strategy, confidence_needed, backends_queried:[names], backends_responded:[names of those that succeeded], responses:[{backend, success, content, response_time, error?}], processing_time_ms, metrics, synthesis_hint (suggestion to Claude on how to synthesize)}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topicYesTopic category — determines which capability the council prefers when picking lanes, never which lane by name: coding → code_specialized, reasoning and architecture → deep_reasoning, security → security_focus, performance and creative → fast_generation, general → no preference (any usable lane). Lanes declaring the wanted capability are seated first; other usable lanes fill the remaining seats, so a council still convenes when only one lane matches.
promptYesThe question or topic for the council to deliberate on
max_tokensNoMaximum tokens per backend response
num_backendsNoOverride number of backends to query (optional - auto-calculated from confidence_needed)
confidence_neededNoRequired confidence level - determines number of backends: high (4 backends), medium (3 backends), low (2 backends)medium

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.15.0
    • changedInput schema / properties / topic / description
      Previous value: -"Topic category - determines which backends are consulted: coding (nvidia_glm, local), reasoning (nvidia_deepseek), architecture (nvidia_deepseek, nvidia_glm), general (gemini, groq), creative (gemini, nvidia_glm), security (nvidia_deepseek, nvidia_glm), performance (nvidia_deepseek, local)"New value: +"Topic category — determines which capability the council prefers when picking lanes, never which lane by name: coding → code_specialized, reasoning and architecture → deep_reasoning, security → security_focus, performance and creative → fast_generation, general → no preference (any usable lane). Lanes declaring the wanted capability are seated first; other usable lanes fill the remaining seats, so a council still convenes when only one lane matches."
  2. Changed1 schema field changed
    • changedInput schema / properties / topic / description
      Previous value: -"Topic category - determines which backends are consulted: coding (nvidia_qwen, local), reasoning (nvidia_deepseek), architecture (nvidia_deepseek, nvidia_qwen), general (gemini, groq), creative (gemini, nvidia_qwen), security (nvidia_deepseek, nvidia_qwen), performance (nvidia_deepseek, local)"New value: +"Topic category - determines which backends are consulted: coding (nvidia_glm, local), reasoning (nvidia_deepseek), architecture (nvidia_deepseek, nvidia_glm), general (gemini, groq), creative (gemini, nvidia_glm), security (nvidia_deepseek, nvidia_glm), performance (nvidia_deepseek, local)"
  3. Addedv1.2.2
  4. Removedv2.2.0
  5. Addedv2.2.1
  6. Removedv1.3.1
  7. Addedv1.3.2

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and meets it fully: it states 'Read-only: makes N parallel HTTP calls; never writes to disk,' discloses the capability-based selection mechanism and roster override, and documents the exact return envelope. It also notes performance characteristics (~1-2s for 2-3 backends). There is no annotation contradiction.

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 dense and front-loaded with the core action, then flows logically through selection, confidence levels, use cases, safety, and return format. Every sentence earns its place; the only minor deduction is for slight redundancy with schema-provided confidence counts (high/medium/low) and the length, which is still justified by tool complexity.

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 parameter-rich tool with no annotations and no output schema, the description is remarkably complete. It defines the input semantics that matter (topic→capability, confidence→count), states the read-only side effect, names the sibling to avoid, and provides an explicit return structure. Nothing an agent needs to invoke 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?

The input schema already covers 100% of parameters, so the baseline is 3. The description adds value beyond the schema by explaining that `topic` maps to a capability rather than a lane name, describing the operator-configured roster override (not present in the schema), and reinforcing the `confidence_needed` → backend count mapping. It doesn't add prose for `max_tokens` or `num_backends`, but those are self-explanatory in 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 opens with a precise verb+object pair: 'Pose one prompt to several AI backends in parallel and return all of their responses for Claude to synthesize.' It clearly differentiates from the sibling `ask` by framing council as multi-backend and naming `ask` as the single-backend alternative, so an agent can distinguish them without opening schemas.

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?

The description explicitly says when to use the tool: 'Use for architectural trade-offs, controversial calls, or anywhere dissent surfaced cheaply...' It also names the alternative: 'For a single backend query, use `ask`.' This is explicit when/when-not guidance.

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