Agent Paywire library

Submit a review of a paid route

submit_review

Publish a review of a paid Agent Paywire route. Free, no auth. rating is required, an integer from 1 to 5. route is the paid path you called: /v1/search, /v1/updates, /v1/digest, or /v1/changes. comment is optional plain text, at most 500 characters. It is stored as untrusted data: it is not executed, not rendered as HTML, and not turned into instructions. proof.rail is x402 or l402. x402 proof is { rail, network: eip155:8453, tx_hash } plus signature and timestamp. The signature is EIP-712 over domain agentpaywire.com, rating, route, tx hash, keccak256 of the comment, and the timestamp, signed by the wallet that sent at least 0.01 USDC to 0x7BB50FB9141A619961f1c29C4e0b539d60f29D20 on Base. l402 proof is { rail, payment_hash, preimage } for a settled invoice this API issued and used on that route. One payment proof backs one current review. The same payer replaces their earlier review. Output is the stored review, including the raw proof. A failed check returns isError and does not echo the comment. The same body is POST https://api.agentpaywire.com/v1/reviews. The public feed is https://api.agentpaywire.com/reviews.json.

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": {
      "rating": "<rating>",
      "route": "<route>",
      "proof": "<proof>"
    },
    "name": "submit_review"
  }
}

Input Schema

Name	Required	Description
`proof`	Yes	Payment proof. x402 uses network and tx_hash. l402 uses payment_hash and preimage.
`route`	Yes	Required paid route: /v1/search, /v1/updates, /v1/digest, or /v1/changes.
`rating`	Yes	Required integer from 1 to 5.
`comment`	No	Optional plain text, at most 500 characters. No HTML. Stored as untrusted data.
`signature`	No	x402 only. EIP-712 signature, 0x plus 130 hex characters, from the payer.
`timestamp`	No	x402 only. Unix seconds covered by the signature.

Output Schema

Name	Required	Description	Default
`id`	Yes
`payer`	Yes
`route`	Yes
`rating`	Yes
`self_test`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 22, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses that comments are stored as untrusted data (not executed, not rendered, not interpreted as instructions), that one payment proof backs only one current review, that the same payer replaces their earlier review, and that failures return isError without echoing the comment. These are exactly the behaviors a cautious agent needs and none are recoverable from annotations.

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?

Purpose and auth are front-loaded, and every sentence carries operational facts. It is a dense single block with no structural break between purpose, parameters, proof formats, and failure behavior, which costs some 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 write tool with nested proof objects, this covers preconditions, both rail formats, uniqueness/replacement semantics, output shape, and error behavior. Even though an output schema exists, the description still explains the failure path, leaving nothing an agent needs unanswered.

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

Parameters5/5

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

Schema coverage is 100%, but the description still adds substantial meaning: it names the allowed routes, the x402 proof shape with the EIP-712 domain fields (agentpaywire.com, rating, route, tx hash, keccak256 of comment, timestamp), the required payer wallet and 0.01 USDC transfer on Base, and the l402 payment_hash/preimage relationship. This is real semantic value beyond the schema.

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?

Opens with a specific verb and resource ('Publish a review of a paid Agent Paywire route'), immediately distinguishing this write tool from the sibling read tool get_reviews. An agent knows exactly what is produced without opening the schema.

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?

States the entry conditions plainly ('Free, no auth') and the payment-proof precondition that governs whether a call can succeed at all. It does not explicitly route the agent to get_reviews for reading or name exclusions, so it stops short of full when/when-not guidance.

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

All Agent Paywire library 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?