Skip to main content
Glama

Is this price good

history
Read-only

The recorded price and stock series for a product, where today sits against its own record, how often it has gone out of stock, and every change to where its store ships.

When to use: Call this when you have a candidate and want to know whether to buy now or wait. Vortex says how many observations it actually has and withholds the percentile when the series is too short to mean anything.

Price: US$0.002000 per call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNoHow far back to look.
productYesA product URL exactly as Vortex returned it from find.

TDQS

A4/5.0
Behavior4/5

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

Annotations already mark it read-only and closed-world; the description adds meaningful behavioral detail: how many observations Vortex has, that the percentile is withheld when the series is too short, and that stock-out and shipping changes are covered. No output schema or pagination specifics are provided, but the read-only annotation lowers the bar.

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?

The description is short, front-loaded with the main behavior, and every sentence earns its place: what it returns, when to call it, an edge-case behavior, and price. The phrasing is slightly awkward but structurally efficient.

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?

For a two-parameter read-only tool with complete schema coverage, the description conveys the decision context, the key return categories, and an important edge case. It doesn't spell out exact output shapes, but no output schema exists and the stated information is enough to use 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 100%, so the baseline is 3 even without additional parameter detail. The description mentions 'product' and 'series' but adds no semantic meaning beyond the schema's product URL and days parameters.

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 clearly identifies the tool as returning historical price, stock, and shipping data for a product, including where today's price sits against its own record. It lacks an explicit verb phrase and does not name or differentiate sibling tools, so it stops short of a 5.

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?

"When to use: Call this when you have a candidate and want to know whether to buy now or wait" is explicit about the intended situation. It does not provide when-not-to-use guidance or name alternatives such as watch or report, so it earns a 4 rather than a 5.

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.

TDQS

A4.1/5.0
Disambiguation5/5

Each tool has a clearly distinct role: search (find), reach verification (feasibility), cost breakdown (landed), price history (history), alerts (watch), and account management (identity_create, credit_deposit, whoami). Even the overlapping cross-border tools are differentiated by their focus and explicit when-to-use guidance.

Naming Consistency3/5

Names are all lowercase and readable, but they follow no strong pattern: some are bare verbs (find, report, watch), some are nouns (capabilities, history, feasibility), and two use underscores with different structures (credit_deposit, identity_create). It is not chaotic, but the convention is mixed.

Tool Count5/5

Ten tools is a well-scoped set for a cross-border commerce intelligence service. Each tool covers a distinct operation, from discovery and feasibility to landed cost, monitoring, and account management, without unnecessary redundancy.

Completeness4/5

The core workflow is well covered: find products, check reach, estimate landed cost, review history, watch for changes, and report outcomes. Minor gaps exist, such as no way to list or cancel watches, but the essential lifecycle for the service's purpose is present.

Resources