Skip to main content
Glama

HirePulse

agentic_shelf_schema_comparator

Read-only

Use to compare a brand and up to 3 competitors as machine-readable shopping schema: prices, ratings, availability, shipping and return evidence. Samples one product per store and does not predict agent selection. $0.02 USDC per comparison via x402.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainYesPublic domain without scheme, path or port.
competitor_domainsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainYes
statusYes
storesNo
comparisonNo
limitationsNo
error_reasonNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover readOnlyHint and openWorldHint, and the description adds genuinely useful behavior beyond them: one-product-per-store sampling, an explicit non-goal (does not predict agent selection), and a per-call cost of $0.02 USDC via x402. The pricing and sampling traits are exactly the kind of context annotations cannot carry.

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 with the action front-loaded and no filler. The cost and limitation notes each carry weight; nothing is redundant.

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?

An output schema exists, so return values need not be explained, and annotations carry the safety profile. The description still supplies cost, sampling behavior, and scope limits, leaving little an agent needs missing to invoke it correctly.

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 50%, and the schema already documents the domain format ('public domain without scheme, path or port') and the array bounds. The description maps concepts to parameters (brand=domain, up to 3 competitors=competitor_domains) but adds no format or syntax detail beyond the schema, so baseline 3 is appropriate.

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 (compare) and resource (a brand vs up to 3 competitors as machine-readable shopping schema), and enumerates the compared dimensions: prices, ratings, availability, shipping, return evidence. It is clearly a comparison/audit tool, though it does not name a specific sibling to contrast against.

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 'Use to compare...' opener gives implied usage context, and the description clarifies scope by stating it samples one product per store and does not predict agent selection. However, it names no alternative tool and gives no explicit when-not guidance, so an agent must infer positioning among the many trust/audit siblings.

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