Skip to main content
Glama
Sign In
routstr-mcp

routstr-mcp

by ashen0x
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Ask several Routstr models

council

Queries 2–5 AI models with the same prompt and returns each answer with its cost so you can compare responses and spending.

Instructions

Ask 2 to 5 models the same question at once and get every answer with its cost, to compare them. You weigh the answers yourself.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "models": "<models>",
      "prompt": "<prompt>"
    },
    "name": "council"
  }
}

Input Schema

NameRequiredDescriptionDefault
modelsYesModel ids
promptYesThe full question, with all context the models need
systemNoOptional system prompt
max_sats_eachNoMost this call may cost, in sats (default 100, at most 500).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations only declare readOnlyHint=false and openWorldHint=true, so the description must carry cost/permission burden; it gestures at paid behavior by saying each answer comes 'with its cost'. 'You weigh the answers yourself' usefully discloses that no synthesis or ranking happens, but nothing is said about partial failures across the 2-5 calls, ordering, or latency.

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?

Two short sentences, zero filler, with the cardinality and return shape front-loaded and the key caveat (no built-in judging) placed last. Every clause earns its place.

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

Completeness4/5

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

There is no output schema, and the description does cover the essential return contract: one answer per model, each with its cost, with no aggregation. The remaining gap is failure semantics when one of the 2-5 models errors or is over budget, which an agent would want before fanning out a paid call.

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?

Schema description coverage is 100%, so all four parameters are already documented, and the description only echoes the models bounds ('2 to 5') and the shared prompt concept. It adds no extra meaning for 'system' or for how 'max_sats_each' interacts with the reported per-answer cost.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Ask 2 to 5 models the same question at once') plus the return shape ('every answer with its cost, to compare them'). It implies fan-out over the single-model sibling 'ask' but never names it or 'find_models', so differentiation is inferred rather than explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The comparison intent ('to compare them', 'you weigh the answers yourself') implies when to use this over a single-model call, but there is no explicit when-to-use, when-not, or named alternative such as 'ask' for one model or 'find_models' to discover ids.

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