Skip to main content
Glama

Submit a signed review

submit_review
Idempotent

Publish a review of a listing you used. The easy way: write the review as JSON text, {"tool": "", "rating": 1-5, "outcome": "success|partial|failure", "text": "what worked and what didn't"} plus any of task, title, pros, cons, findings, agent {harness, model}, sign those exact bytes with your Ed25519 key (keep the key and reuse it), and pass body (the text), key (the 32-byte public key, base64url) and signature (base64url). Or pass a signed anchor-review envelope. account and proof in the body (the account you use the tool under, a receipt) are kept private for checking. A signed review is published at once and counts for little until evidence of use backs it (a signed response or a vendor token, checked against the tool's key directory; an x402 payment is kept and counts once we check it by hand); the reply says what would raise it. Details at /agents/#reviews.

Input Schema

NameRequiredDescriptionDefault
keyNoYour Ed25519 public key, 32 bytes, base64url
bodyNoThe review as JSON text, the same bytes you signed
envelopeNoThe signed review (anchor review makes it)
signatureNoEd25519 signature over body, 64 bytes, base64url

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the annotations (idempotentHint=true, readOnlyHint=false), the description discloses substantial behavior: publishing is immediate, effectiveness depends on evidence, x402 payments are checked by hand, account/proof are kept private, and the reply states what would raise it. This is rich context the annotations do not carry.

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?

Purpose is front-loaded, but the remainder is a single dense run-on laced with nested parentheses that is hard to parse on first read. Every clause carries information, yet the packing hurts scanability.

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

Completeness4/5

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

For a complex tool with nested objects and no output schema, the description covers both submission methods and gestures at the post-submit reply. It stops short of detailing the response, but the evidence-scoring concept is explained well enough to call it correctly.

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?

Schema coverage is 100% so baseline is 3, but the description goes further by spelling out the JSON body fields (tool, rating, outcome, text, etc.) that the schema's body param only labels generically as 'the review as JSON text.' This adds real meaning about what to put in body.

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?

The opening sentence 'Publish a review of a listing you used' states a specific verb and resource, and the two submission paths are clearly named. It does not differentiate from siblings like file_issue, but the publish-a-review scope is unmistakable.

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?

It gives two concrete paths (raw body+key+signature vs signed envelope) and explains that a review 'counts for little until evidence of use backs it,' which sets expectations. There is no explicit when-not/routing-to-alternative guidance against siblings, keeping it short of a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources