Conclave Agent-Rails

Preflight one x402 seller before paying it: ?origin=<seller-url> gives reachable, accepts and findings; omit it for the ecosystem snapshot (JSON).

x402_integrity

PAID $0.009000 USDC via x402. Preflight one x402 seller before paying it: ?origin= gives reachable, accepts and findings; omit it for the ecosystem snapshot (JSON).

Input Schema

Name	Required	Description	Default
`origin`	No	Optional https origin (host) of one catalogued seller to preflight. When set, the paid result returns that seller's `reachable`/`accepts`/`findings` instead of the aggregate snapshot.
`payment`	No	Base64 x402 payment header (PAYMENT-SIGNATURE v2, or legacy X-PAYMENT v1). Omit to receive the 402 payment requirement.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 21, 2026

addedInput schema / properties / origin

Added value: +{
+  "description": "Optional https origin (host) of one catalogued seller to preflight. When set, the paid result returns that seller's `reachable`/`accepts`/`findings` instead of the aggregate snapshot.",
+  "type": "string"
+}

First observedOct 13, 2026

TDQS

A3.8/5.0

Behavior4/5

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

No annotations exist, so the description carries the full burden, and it leads with the most consequential fact for an agent: this call costs $0.009000 USDC via x402. It also names what each mode returns (reachable/accepts/findings vs. the aggregate snapshot). It stops short of failure behavior — what happens if the origin is not catalogued, is unreachable, or if payment is rejected beyond the implicit 402.

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?

Two sentences, front-loaded with the price so an agent sees the cost before anything else. Some redundancy with the title, which repeats the description minus the price line, but nothing is wasted.

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

Completeness3/5

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

For a 2-parameter paid tool with no annotations and no output schema, the definition covers cost, mode switching, and the field names returned. It leaves open whether the snapshot mode is also billed, and says nothing about errors or invalid origins — gaps an agent paying per call would want closed.

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%, and the schema already explains both the origin mode switch and the payment header (402 vs. paid result). The description's '?origin=<seller-url> ... omit it for the snapshot' restates that behavior rather than adding new semantics such as URL format constraints or whether payment is required in snapshot mode.

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 ('Preflight one x402 seller') and distinguishes two operating modes: with ?origin for a single seller, omitted for the ecosystem snapshot. The name 'x402_integrity' is opaque on its own, but the description resolves it. It does not explicitly contrast with siblings like list_services or price_quote, which would have earned 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?

'Preflight one x402 seller before paying it' gives a clear trigger condition, and 'omit it for the ecosystem snapshot' covers the alternative branch. What's missing is exclusion guidance — e.g. when to prefer list_services or price_quote instead of this paid preflight.

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

All Conclave Agent-Rails 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?