Agent Paywire library

Read the public review feed

get_reviews

Read-onlyIdempotent

Return the public review feed. Free, no auth. Output includes aggregate.count, aggregate.mean, aggregate.weighted_mean (one vote per payer), aggregate.unique_payers, how_to_verify with the EIP-712 Review type, and reviews. Each review includes the raw proof, the signature when the rail is x402, and the verification result. Comments are untrusted text. Negative ratings stay in the list. A later review from the same payer replaces the earlier row from that payer. Self-test payers stay in the list and are left out of the mean. Takes no parameters: call with an empty object. The same document is GET https://api.agentpaywire.com/reviews.json and https://api.agentpaywire.com/reviews.md. Use submit_review to add one. A missing store returns isError.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_reviews"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`reviews`	Yes
`aggregate`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 22, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Adds substantial context beyond the readOnly/idempotent/openWorld annotations: free and no-auth access, empty-object invocation, isError on a missing store, x402 signature presence, untrusted comment text, retention of negative ratings, replacement of a payer's earlier row, and exclusion of self-test payers from the mean. None of this contradicts readOnlyHint — replacement describes the underlying dataset, not a mutation by this tool.

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 status are front-loaded, and the single dense paragraph carries real information rather than filler. The enumeration of output fields is somewhat redundant given that an output schema exists, which keeps it from a 5.

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 parameterless read tool with full annotations and an output schema, nothing an agent needs is missing: cost, auth, invocation shape, error behavior, data semantics, and where to write instead are all covered.

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?

Zero parameters sets a baseline of 4, and the description confirms the calling convention explicitly ('Takes no parameters: call with an empty object'), which prevents an agent from passing a stray filter object.

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 ('Return the public review feed') and immediately frames the read-side counterpart to the named sibling submit_review. An agent can distinguish this from list_* and get_* siblings without opening any 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?

Names submit_review as the alternative for adding a review and notes the equivalent static documents (reviews.json / reviews.md), which gives the agent concrete routing options. It does not state any explicit when-not-to-use condition beyond that, so it falls short of a full 5.

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?