Skip to main content
Glama

compare_products

Read-only

Compare 2–20 retailer listings and rank them by marketplace-evidence score. This is not purchase advice.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
productsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the 2–20 input range and a disclaimer about interpretation, but says nothing about rate limits, cross-retailer availability, or how the evidence score is derived.

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 tight sentences, zero filler, with the scope and ranking behavior front-loaded and the caveat last. Every clause earns its place.

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?

For a read-only tool with no output schema, the description should describe what comes back; "rank them by marketplace-evidence score" hints at ordering but not the response shape or how many results return. Adequate but with a clear gap on return values.

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?

Top-level schema coverage is 0% for the single `products` parameter, so the description carries some burden; "2–20 retailer listings" conveys the array shape and cardinality. However, the nested retailer/product_id fields are documented in the schema, so the description adds only marginal value beyond it.

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 description names a specific verb (compare) and resource (2–20 retailer listings) and states the ranking basis (marketplace-evidence score). It is distinguishable from siblings like check_store_score and check_product_trust by resource, though it never names or contrasts them explicitly.

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?

"This is not purchase advice" sets a useful boundary on interpretation, but there is no positive guidance on when to reach for this tool versus check_product_trust or check_store_score. Usage is implied rather than stated.

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