Human-reviewed product feedback for people and AI agents. Submit a product request, track its status, and receive feedback written by a human reviewer. Free to use; review turnaround is a target, not guaranteed.
Scored across 3 tools
Each tool has a clearly distinct purpose: aggregate public statistics, per-request status/feedback lookup, and submission of a new request. The inclusion of the receiptToken requirement in get_review_status makes its boundary versus get_public_stats unambiguous.
All three tools follow a consistent verb_noun pattern (get_public_stats, get_review_status, submit_product_for_review) with uniform snake_case. The verbs (get vs submit) correctly signal read vs write.
Three tools cover the core flow of a review-submission service and none feel redundant, but the surface is at the thin end; a small number of additional operations would round it out without bloat.
Submit, status/read, and public stats cover the primary lifecycle, but there is no way to cancel or withdraw a submitted request, nor to list or recover a lost receiptToken. These are minor gaps an agent can largely work around.
Read the public completed-review count, average turnaround, and target SLA.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden: it at least establishes this is a read-only, public-facing lookup with no side effects. It says nothing about data freshness, caching, rate limits, or availability, which are the meaningful behavioral traits for a stats endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single well-formed sentence with the resource list front-loaded and zero filler. Nothing could be removed without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must name the return values, and it names all three metrics. It falls short only on freshness/as-of semantics that an agent might want before citing the numbers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the schema is empty, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly does not invent input semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description pairs a specific verb ("Read") with concrete resource fields — completed-review count, average turnaround, target SLA — so an agent knows exactly what it returns. It does not explicitly contrast with the sibling get_review_status, leaving the boundary between the two somewhat implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to call this versus get_review_status, no prerequisites, and no exclusions. The word "public" is the only signal, and it is not framed as guidance about auth or audience.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a request or read its completed feedback. Requires both the request ID and its secret receiptToken. Keep the token private.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| receiptToken | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden. It does disclose the key access-control fact — both the ID and a secret receiptToken are mandatory, and the token must be kept private — which is genuinely useful beyond the schema. However, it says nothing about read-only versus mutating behavior, what happens with an invalid or expired token, or whether feedback becomes unavailable at some point.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the action and followed by the hard requirement and the security caveat. Nothing is redundant and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain what comes back — a status value, a feedback payload, or both — and whether results appear only after review completes. It never describes the return shape, so an agent knows how to call it but not what to expect. Adequate for a two-parameter read tool, but with a clear gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so both parameters are undocumented in the schema. The description partially compensates by naming what each parameter is — the request ID and its secret receipt token — which is more than the bare property names give. It still omits where the token originates and any format expectations, so the gap is only half closed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb-and-resource pair: check a submitted request's status or read its completed feedback. It is distinguishable from submit_product_for_review (which creates the request) and get_public_stats (unrelated aggregate data). The phrase 'check a request' is slightly loose, but the intent is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: you call this once you hold both the request ID and its receipt token, typically to poll status or fetch finished feedback. There is no explicit statement of when to prefer it over siblings, no note on repeated polling, and no exclusions. An agent can infer the situation but gets no routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a product for an honest, human-written review. The request starts queued; only a human reviewer completes it. The returned receiptToken is secret and is required to read a private result. Public visibility is off by default.
| Name | Required | Description | Default |
|---|---|---|---|
| focus | No | ||
| product | Yes | ||
| publicOk | No | ||
| contactEmail | No | ||
| submitterName | No | ||
| idempotencyKey | No | ||
| submitterModel | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the queued lifecycle, human-only completion, that receiptToken is secret and mandatory for reading a private result, and that public visibility defaults off. It omits mutating/destructive signalling and idempotency behavior for a write tool with an idempotencyKey parameter, leaving a real gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the action, then the lifecycle, then the token and privacy caveat. No filler, though the token sentence would be clearer if it were explicitly framed as a return value rather than sitting ambiguously among call semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter, nested-object submission tool with no annotations and no output schema, the description covers lifecycle and the key return artifact but leaves the submitter metadata, contact email, idempotency, and focus taxonomy unexplained. It is adequate to know the tool's shape but not to fill the payload confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 7 parameters, including a nested product object with six subfields, so the description must compensate and largely does not. It only indirectly touches publicOk ('public visibility is off by default') and mentions receiptToken, which is not even a parameter; focus, contactEmail, submitterName, submitterModel, and idempotencyKey get no explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('Submit a product for...review') and immediately scopes what kind of review (human-written, honest), which separates it from the read-only siblings get_review_status and get_public_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It conveys implied usage by explaining that the request starts queued and only a human completes it, so an agent understands this is an async handoff. But it never states when to call this versus get_review_status, nor any prerequisites such as what to do after receiving the token beyond a passing mention.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_public_statsget_review_statussubmit_product_for_review
Add one secure layer between your agents and this server.