Skip to main content
Glama

Last Price

check_agent_readiness

Read-onlyIdempotent

Run the free agent-ready check on a store: pass url, the store address. It reports whether shopping agents can check out, whether bot blocking is in the way and whether margin survives an agent's cut. It fetches the store, so it is limited per address and answers 404 while the check is not released. Public: needs no credential.

Input Schema

NameRequiredDescriptionDefault
urlYesThe store address to check.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.9/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses that the tool fetches the store, that calls are rate-limited per address, that it returns 404 while the check is unreleased, and that no credential is required. These are exactly the operational traits (network access, throttling, error behavior, auth) an agent needs before calling.

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?

The action and the resource are front-loaded, and each sentence carries distinct information (purpose, reported signals, fetch behavior/limits, auth). A slightly more compact phrasing would earn a 5, but there is no filler.

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?

With no output schema, the description does the work of describing what the check returns (checkout, bot blocking, margin). Combined with the disclosed 404/rate-limit behavior and public access, an agent has enough to invoke it correctly; only the response shape remains qualitative.

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?

With schema description coverage at 100% and only one parameter, the schema already fully documents 'url'. The description's 'pass url, the store address' restates rather than enriches it, so the baseline of 3 applies.

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 ('Run the free agent-ready check on a store') and enumerates what it reports: checkout capability, bot blocking, and margin impact. An agent can tell this apart from siblings like simulate_agent_cut or get_agent_capabilities, though the description doesn't explicitly name an alternative.

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?

Implies usage context ('free', 'public: needs no credential') and gives the input ('pass url, the store address'), but never says when to prefer this over related checks such as run_agent_behaviour_tests or simulate_agent_cut, nor when not to use it.

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