Skip to main content
Glama

Compare models

compare_models
Read-only

Returns the current prices of several models side by side. Amounts in credits are never converted to money, so a credit-billed model is not comparable to a token-billed one. Two dimensions can share a label, so the ones that would collide carry their qualifiers, e.g. 'Web search (context size: high)'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior4/5

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

With readOnlyHint=true the safety profile is already covered, and the description adds genuine behavioral context: credits are never converted to money (a real interpretation constraint) and colliding dimension labels carry qualifiers, e.g. 'Web search (context size: high)'. It stops short of noting rate limits or the exact output structure, but it meaningfully exceeds the annotation.

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?

Three tight sentences, front-loaded with what the tool returns before moving to the two output caveats. Every sentence carries content; the label-collision example is slightly niche but directly aids result interpretation.

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

Completeness3/5

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

There is no output schema, so the description must convey the return shape; it communicates the comparative format, the credit caveat, and label disambiguation, which is helpful. It still leaves the actual compared dimensions and result structure vague, which is a notable gap for a comparison tool with no output schema.

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

Parameters2/5

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

The description says nothing about the single `models` parameter, and per the context signal schema description coverage is 0%, so the description fails to compensate for the documented gap. It does not mention the 2-8 item bounds or the `provider/slug` format that the agent must supply.

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: 'Returns the current prices of several models side by side.' This clearly separates it from single-model retrieval siblings like get_model_price, though it never names those siblings explicitly. An agent can grasp the comparison scope immediately.

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?

Usage is implied by the word 'several' and the side-by-side framing, and the credit-vs-token caveat hints at when results are meaningful. However, no alternative tool is named and there is no explicit when-not guidance, so the agent must infer this is the multi-model counterpart to get_model_price.

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.

Resources