Skip to main content
Glama

decide

Which models fit this job? Call decide early. Returns answer, ranked results, may_qualify, reading and recovery hints, decision_id and snapshot. Never add a gate or constraint the user didn't state. Relax only constraints the user stated, one at a time, and say what was relaxed and why. Prefer the answer's own relax suggestions. A tie stays a tie. Don't promote a member by knowledge from outside the response. Cite only evidence in the response. Never add benchmark figures from memory. Tied or partial answer: report the tie and caveats, pick no member; a null answer names no pick and says what's missing. A null cost is unknown. Never show it as $0.00 or "free". One vocabulary lookup per unknown facet, then decide. Read next before another call. Size task_tokens from the user's own task, and say what you assumed. Don't copy the guide's example sizes. Template weights are examples, not requirements. If the evidence basis or board does not match the task, say so: Arena web-dev evidence does not establish chat quality. p_best is the probability of ranking best under the Spec and evidence uncertainty, not the probability of matching the user's task or satisfying its requirements. Read reading when present. Present answer.kind=tied among all answer.members, including with_estate; tie-breakers are conditional. State requirements in reading.not_applied or error.issues that were not applied, including requirements removed after a rejected call. A retry does not verify them. Report estimates as estimates: fits_hardware membership is not measured fit for a specific quantization and context workload. Follow reading.do_not_claim. Never claim a rank the response does not show. Present summary_for_user to the user unchanged and keep every must_mention item. When next_move is present, offer it instead of a pick. Needs an API key (Authorization: Bearer). Costs 1 or 2 credits a call; $0.0053–$0.02 per credit by plan or pack (https://modelspec.dev/pricing/). Not a router: call once per job or role, not per request; route among its chosen models. Proxies POST https://api.modelspec.dev/v1/decide. MCP decide returns a bounded answer of at most 16 KB, summary included. Drill down with evidence_for. Complete rows need fields:null; explanation.fetch names what was removed and how to fetch it. With explain unset or "none": explain=none, limit=10, fields=model_rank,cost_per_task,estimates,p_best. summary/full adds contributions and evidence. omitted counts removed records; explain=none skips eliminations. Explicit fields, including null, pass through. Oversize responses use a trimmed notice with explanation.fetch. decision_id is a citation, not a stored lookup. task free text is rejected; where is an array. Examples, recovery and budgets: https://modelspec.dev/agents.md. Null means unresearched or unpublished, never a guess. Sourced card values include a URL and read date. Returns the origin JSON and URL without invented fields. Example. Answer: status partial, answer.kind tied (a/x, b/y), next_move.kind decide_by_testing. Right report: summary_for_user verbatim, each must_mention item, then next_move.steps for its candidates. Wrong: "Start with a/x", a shortlist, or a ranked table.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and delivers: auth (Bearer key), cost (1–2 credits, $0.0053–$0.02/credit), endpoint, a 16 KB response bound, trim/oversize behavior, retry semantics, and null-cost semantics ('A null cost is unknown... never show it as $0.00'). It also discloses failure modes (null answer, tied answer, partial status) and what a rejected call does to prior requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in one sentence, but the remainder is a wall of ~500 words of output-formatting and prompting policy that reads like a system prompt pasted into a tool description. Rules repeat ('Never add benchmark figures', 'Never claim a rank the response does not show', the $0.00 warning) and an inline worked example ('Right report... Wrong: ...') bloats it further.

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 high-complexity decision engine with no output schema, the description is unusually complete: it outlines the response shape, explain modes and their defaults, size limits and trimming, citation and evidence rules, and null/unresolved semantics. Nothing an agent needs to interpret a call result appears absent.

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?

At 100% schema coverage the baseline is 3, but the description adds real meaning beyond the schema: task_tokens should be sized from the user's own task and the assumption stated, template weights are examples not requirements, 'Complete rows need fields:null', and default behavior for explain/limit/fields. It also asserts 'task free text is rejected; where is an array', which sits uneasily beside the schema's string|null type for `task` — a discrepancy worth resolving.

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?

Opens with a clear question framing the job ('Which models fit this job?') and enumerates what comes back (answer, ranked results, may_qualify, reading, recovery hints, decision_id, snapshot), so the resource and output are identifiable. It differentiates itself from a request-level router, but never names any of the actual siblings (rank, compare_models, hardware_fit, policy_check), so sibling selection still requires inference.

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?

Gives explicit invocation policy: 'Call decide early', 'call once per job or role, not per request', 'One vocabulary lookup per unknown facet, then decide', 'Read `next` before another call'. It also states a negative ('Not a router'), but it never names an alternative sibling tool or the condition that would select one, so routing among peers is left implicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.