ARC (arcreport.ai): can an agent reach checkout?

Compare stores

compare

Read-onlyIdempotent

Call this when you must choose between a few stores for the same item and want the one where an agent is most likely to reach checkout. Pass 2 to 10 store domains or URLs. Returns one short row per store (reaches_checkout, best_route, checked_at, grade), and pick: among stores whose saved check reaches checkout on a fresh check, the one with the best current Agent Readiness Grade (expired after current of the same letter, not graded last); null when no store has fresh evidence. Rows are ordered only by saved checkout evidence, its freshness and published grade, never by anything else. Example: compare({"stores":["allbirds.com","gymshark.com"]}) → {"pick":"allbirds.com","stores":[…]}. Each store counts as one precheck read. Saved checks only: no store fetch, no scan, no login. Advisory; ARC stops before payment. Errors: {error:{code, message, next_step}}.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "stores": "<stores>"
    },
    "name": "compare"
  }
}

Input Schema

Name	Required	Description	Default
`stores`	Yes	2 to 10 store domains or URLs.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent/non-destructive annotations: it discloses the cost model ('each store counts as one precheck read'), the evidence source (saved checks, no live fetch), the ordering semantics, the tie-breaking rule (expired same-letter grade, ungraded last), the null case, and even the error envelope shape.

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?

Front-loaded with the calling condition and input contract before the return semantics, which is the right order. It is dense and packs many clauses into the pick-ordering sentence, but nearly every clause carries decision-relevant information rather than filler.

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

Completeness5/5

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

There is no output schema, and the description compensates by naming the returned row fields (reaches_checkout, best_route, checked_at, grade), the 'pick' field, the null case, and the error shape. Nothing an agent needs to call it or interpret the result is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds value: it clarifies that entries may be domains or URLs and provides a concrete example invocation with a sample response, which the schema alone does not convey. The 2-10 bound is repeated from the schema rather than extended.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (compare stores), the exact decision it supports ('choose between a few stores for the same item... most likely to reach checkout'), and the selection rule used for the 'pick'. That distinguishes it clearly from siblings like precheck, find_agent_ready_stores, or store_card.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to call it ('when you must choose between a few stores for the same item'), what input shape is expected (2-10 domains or URLs), and what it will not do ('saved checks only: no store fetch, no scan, no login'). It also states the advisory boundary ('ARC stops before payment'), so an agent knows the limits of the recommendation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All ARC (arcreport.ai): can an agent reach checkout? tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?