Wever Labs Agentic Rails

Refund path check

wever_refund-path-check

Read-only

Agent Purchases: submit a provider’s stated refund route for failed paid calls (endpoint, process, automatic, contact-us or none, with its window, where the money goes back to and the proof it requires), each step of the route (endpoint, form, email, ticket, chat or dispute, where it happens, what a test of it showed and what the buyer needs to take it), the failed call (reference, amount, when it failed and when the refund is asked for) and the proof the buyer holds. The signed report gives each step as reachable, unreachable, unpublished or untested, and names every block (no route, contact-us alone, a step written down with nowhere to take it, a step tested and failing, a window already closed) and every gap (a step needing an account an agent may not hold, no stated window, credit in place of money, proof the buyer does not hold). What the seller’s refund rules say is wever_refund-rule-check and whether one purchase qualifies under a refund policy is wever_refund-eligibility-check. Verdict no_working_route, route_gaps, route_unverified or route_reachable. POST /api/refund-path-check. Reads only the material in the call: no network request, fetch, money movement, message, sharing, configuration change or external write. Paid URL: 0.10 USDC per call on Base via x402 exact, with the shared 10 signed-wallet free calls per rolling 30 days. Bind X-Wever-Wallet-Proof to the exact JSON arguments and the tool route. Returns a report with an Ed25519 signed receipt. Contract: /api/agent-purchases-contract. Human page: https://weverlabs.com/agent-purchases/.

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": {
      "route": "<route>"
    },
    "name": "wever_refund-path-check"
  }
}

Input Schema

Name	Required	Description
`held`	No	Proof the buyer holds, such as the transaction reference and the signed receipt.
`label`	No	Optional name recorded in the report.
`route`	Yes
`steps`	No	Each step of the route, in order.
`failure`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 10, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds substantial context beyond them: no network request, fetch, money movement, message, sharing, configuration change or external write. It also discloses pricing (0.10 USDC via x402), the free-call allowance, wallet-proof binding, and the Ed25519 signed receipt.

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 purpose is front-loaded, but the body is a dense run-on paragraph packing route, steps, failure, proof, verdicts, pricing and contract links into one block. Every element is relevant, yet the lack of structure hurts scannability.

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?

For a complex nested-input tool with no output schema, the description explains the returned report (per-step reachability, named blocks and gaps, verdicts, signed receipt) and the contract/human-page references. An agent has everything needed to call it and interpret results.

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?

With 60% schema coverage and nested objects, the description meaningfully expands on the schema by explaining the route kinds, the step kinds and what a test shows, the failure fields, and the proof the buyer holds. It stops short of documenting every field (e.g. label, provider), so it is strong but not exhaustive.

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: submit a provider's stated refund route for failed paid calls, enumerating the route, steps, failure and proof inputs. It explicitly distinguishes itself from wever_refund-rule-check and wever_refund-eligibility-check, so an agent can route without opening schemas.

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?

Names the two adjacent siblings and the exact question each answers (what the rules say, whether a purchase qualifies), leaving this tool's scope unambiguous. The verdict vocabulary (no_working_route, route_gaps, route_unverified, route_reachable) further signals the intended use case.

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

All Wever Labs Agentic 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?