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
`url`	Yes	The https x402 door you are asking about.
`model`	No	Optional. The model running you, as you would name it: claude-opus-5, gpt-5.6, a local model. Counted, never printed on the certificate.
`since`	No	Optional. A signed week, to reproduce against that week's row.
`client`	No	Optional. The harness or framework you run in: claude-code, cursor, openai-agents, langgraph, custom. Counted, never on the certificate.
`operator`	No	Optional. Who runs you: a name, handle, company or URL. Stored as your claim, marked unverified, never published, never on the certificate.
`came_from`	No	Optional. Where you learned this door exists: a URL, a directory, a skill name, memory, another agent. Referrers never reach us; this does.
`operator_kind`	No	Optional. solo: one person runs you. company: a team does. research: a study. self: you act for yourself.
`prior_cert_id`	No	Optional. A cert_ id from an earlier purchase here. A payer match with this payment marks you a returning buyer; no account needed.

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.

Changed6 schema fields changedSep 18, 2026

addedInput schema / properties / came_from

Added value: +{
+  "description": "Optional. Where you learned this door exists: a URL, a directory, a skill name, memory, another agent. Referrers never reach us; this does.",
+  "maxLength": 160,
+  "type": "string"
+}

addedInput schema / properties / client

Added value: +{
+  "description": "Optional. The harness or framework you run in: claude-code, cursor, openai-agents, langgraph, custom. Counted, never on the certificate.",
+  "maxLength": 64,
+  "type": "string"
+}

addedInput schema / properties / model

Added value: +{
+  "description": "Optional. The model running you, as you would name it: claude-opus-5, gpt-5.6, a local model. Counted, never printed on the certificate.",
+  "maxLength": 64,
+  "type": "string"
+}

addedInput schema / properties / operator

Added value: +{
+  "description": "Optional. Who runs you: a name, handle, company or URL. Stored as your claim, marked unverified, never published, never on the certificate.",
+  "maxLength": 120,
+  "type": "string"
+}

addedInput schema / properties / operator_kind

Added value: +{
+  "description": "Optional. solo: one person runs you. company: a team does. research: a study. self: you act for yourself.",
+  "enum": [
+    "solo",
+    "company",
+    "research",
+    "self"
+  ],
+  "type": "string"
+}

addedInput schema / properties / prior_cert_id

Added value: +{
+  "description": "Optional. A cert_ id from an earlier purchase here. A payer match with this payment marks you a returning buyer; no account needed.",
+  "maxLength": 64,
+  "type": "string"
+}

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.4/5.0

Behavior5/5

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

The description goes well beyond the annotations: it states that the call is free, that the probe is 'unpaid,' that the comparison statuses are same, changed, no_prior, or not_comparable, and that 'never a score, a rank or a safety threshold' is returned. It also explains the unknown-host behavior ('A host the chain never met comes back as never met') and mentions that counts travel with denominators. This richly discloses output semantics and limitations.

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 description is longer than minimal, but every sentence carries distinct information: cost, the probe, the comparison, the reproduce block, the no-score rule, unknown-host behavior, and sibling alternatives. It is front-loaded with the core purpose. A slight deduction for density and jargon ('folded with what the signed chain holds'), but overall it is efficiently structured for the tool's complexity.

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 output schema exists and annotations cover readOnly/openWorld/idempotent hints, the description completes the picture: it explains what data is included, how the comparison is named, what reproduce does, how to handle hosts never met, what is never returned, and where to go for signed or fresh versions. Nothing essential for calling this tool correctly is missing.

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?

The input schema already covers all 8 parameters with descriptions, so the baseline is 3. The description adds little beyond the schema: it mentions that 'since' selects a signed week's row and that 'url' is the x402 door, but these are already in the schema. It does not need to compensate because schema coverage is 100%.

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 a specific and meaningful statement: 'What this store holds about an x402 door, now and before now, in one free call.' It clearly names the resource (x402 door), the action (look at what is held), and the scope (current and historical). It also distinguishes itself from siblings by explicitly cross-referencing preflight_endpoint, buy_observation, and passport_refresh.

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 useful context: this is one free probe with the same budget as preflight_endpoint, and it explicitly notes when a different tool is appropriate ('Signed, dated version of the live half: buy_observation service_audit; a fresh census look folded into the passport: passport_refresh'). It does not formulate a strict 'when to use vs when not to use' rule, but it offers enough directional guidance for an agent to choose sensibly.

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

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.