Skip to main content
Glama

ModelSpec

decide

Which models fit this job? 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; a credit costs $0.0053–$0.02 depending on the plan or pack (https://modelspec.dev/pricing/). Not a router: call it once per job or role, not per request, then route among the models it recommends. Proxies POST https://api.modelspec.dev/v1/decide. Call decide early with a template-based Spec; refine from reading and recovery hints. Put Musts in where: these gates exclude. Put Prefers in optimize.weights: weights rank and never exclude. Unknown values go to may_qualify. Pin snapshot for reproducibility. 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 or full also sends contributions and evidence. omitted counts removed records; explain=none does not compute eliminations. explicit fields, including null, is sent as given. Over 16 KB the body is a trimmed notice and explanation.fetch says how to resend. decision_id is a citation, not a stored lookup. task free text is rejected; where is an array. Call shape, examples, recovery and budgets: https://modelspec.dev/agents.md. Null means not researched or not published, never a guess. Every sourced value on a card carries a URL and a read date. This tool returns the origin's JSON plus the origin URL; it does not invent 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

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/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 discharges it: it discloses the auth requirement ('Needs an API key (Authorization: Bearer)'), per-call credit cost and dollar pricing, the concrete endpoint, the 16 KB response bound, decision_id being 'a citation, not a stored lookup,' that 'task free text is rejected,' and that nulls mean unresearched. It also spells out failure/trim behavior and links to recovery docs. This is unusually rich beyond any structured field.

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, but the body is an undifferentiated ~700-word wall that interleaves output rules, epistemological cautions, pricing, HTTP details, and a worked example with no headings or grouping. Much content is valuable, yet the density and repetition (repeated 'never claim/never show/never add' rules) make it hard to scan, and much of it is report-style guidance rather than tool-selection information.

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?

This is a complex tool with no annotations and no output schema, and the description compensates thoroughly: it enumerates the answer components, output size limits, default and expanded field sets, error/trim handling, cost model, auth, and snapshot pinning, plus a concrete right/wrong reporting example. An agent has essentially everything it needs to call the tool and interpret the response.

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

Parameters5/5

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

Schema coverage is already 100%, yet the description still adds real semantic meaning: 'Put Musts in where: these gates exclude. Put Prefers in optimize.weights: weights rank and never exclude. Unknown values go to may_qualify,' plus 'explicit fields, including null, is sent as given' and the explain=none defaults (limit=10, fields model_rank, cost_per_task, estimates, p_best). It clarifies the gating-vs-ranking distinction that the raw schema does not convey, well above the baseline 3.

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?

The opening names the job concretely — 'Which models fit this job?' with 'Returns answer, ranked results, may_qualify, reading and recovery hints, decision_id and snapshot' — so the agent knows it is a spec-driven model-selection/decision tool. It also draws a behavioral boundary against generic routing ('Not a router: call it once per job or role, not per request'). It never contrasts itself with the adjacent siblings rank, compare_models, or policy_check, so the purpose is clear but not fully sibling-differentiated.

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?

Usage context is explicit: 'Call decide early with a template-based Spec; refine from reading and recovery hints,' 'call it once per job or role, not per request,' 'Read `next` before another call,' and 'One vocabulary lookup per unknown facet, then decide.' It also says how to route requirements into where vs optimize.weights vs may_qualify. What it lacks is explicit when-not-to-use guidance relative to siblings such as rank, compare_models, or policy_check.

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.