SCVD General Store

Look at a Door — what we hold about it

look_at_door

Read-onlyIdempotent

What this store holds about an x402 door, now and before now, in one free call. One unpaid probe (the same single probe as preflight_endpoint, same budget) folded with what the signed chain holds about the host: rounds probed out of rounds since we first met it, the passport tier with its fraction and its rows, the last probed round with its failed checks and the catalog's agreement, the passport decision, the shared-wallet fact. Then one comparison, stated as same, changed, no_prior or not_comparable with both sides named: did the door answer now the way the last signed round saw it. A reproduce block sets the live probe against one signed row (the last probed, or the week named with since), classed by the rule at /criteria#result-class, the row cited. Never a score, a rank or a safety threshold; counts travel with their denominators. A host the chain never met comes back as never met. Signed, dated version of the live half: buy_observation service_audit; a fresh census look folded into the passport: passport_refresh.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`url`	Yes	The https x402 door you are asking about.
`since`	No	Optional. A signed week, to reproduce against that week's row.

Output Schema

TableJSON Schema

Name	Required	Description
`now`	Yes	The live half: the preflight verdict, failed checks, advisories, and the whole preflight report.
`held`	Yes	The held half: counts with denominators, the tier with its fraction and rows, the last probed round, the passport decision, when it was derived.
`headline`	Yes	One derived sentence: what the door answered now and what the chain holds.
`reproduce`	No	The live probe against one signed row: the class, both sides, the failed checks added and cleared, the citation.
`now_against_held`	Yes	same \| changed \| no_prior \| not_comparable, with both sides named.
`what_this_is_not`	No	Not a score, a rank, or a safety threshold — the standing caveat.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed3 schema fields changedSep 6, 2026

changedInput schema / properties / since / description

Previous value: -"Optional. A signed week, e.g. 2026-W34, to reproduce against that week's row."New value: +"Optional. A signed week, to reproduce against that week's row."

addedInput schema / properties / since / examples
```
Added value: +[
+  "2026-W34"
+]
```
addedInput schema / properties / since / pattern
```
Added value: +"^\\d{4}-W\\d{2}$"
```

First observedSep 6, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds rich behavior beyond annotations: it is free and unpaid, uses the same probe budget as preflight_endpoint, never returns a score/rank/safety threshold, always reports denominators, returns 'never met' for unknown hosts, and defines comparison states (same, changed, no_prior, not_comparable). No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense, multi-clause, and packed with domain jargon ('passport tier', 'shared-wallet fact', 'catalog's agreement', 'reproduce block'). It is front-loaded with the core purpose and every sentence adds information, but it is not concise or easily skimmable. It would benefit from tighter structuring or bullet points.

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?

Given the tool's complexity, the output schema, and the annotations, the description is complete: it covers cost (free), probe equivalence, comparison categories, reproduce semantics, what happens for unknown hosts, explicit exclusions (no score/rank/safety threshold), and redirects to related services. An agent has sufficient information to invoke it correctly.

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% and the schema already documents url and since. The description adds meaningful default behavior for the reproduce block ('the last probed, or the week named with since'), which clarifies the since parameter's role beyond the schema's standalone wording. This extra nuance justifies a score above baseline.

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?

The description opens with 'What this store holds about an x402 door, now and before now, in one free call' and then enumerates the exact contents (rounds, passport tier, last probed round, comparison, reproduce block). It also distinguishes itself from siblings by referencing preflight_endpoint and buy_observation, so an agent can tell it apart from other tools.

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?

The description gives clear context ('one free call', 'same single probe as preflight_endpoint') and names alternatives: 'Signed, dated version of the live half: buy_observation service_audit; a fresh census look folded into the passport: passport_refresh.' This routes the agent to the right alternatives, though there is no crisp 'use this when / don't use this when' conditional.

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

All SCVD General Store tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.