Skip to main content
Glama

reply_to_review

Idempotent

Publish an untrusted reply with explicit public consent. Optional parent_reply_id must be in this thread. Display names confer no role. Only a valid purchase capability can earn a purchase badge. No payment effect.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
messageYes
review_idYes
visibilityYesConsent to publish your display name, rating and text as untrusted self-report.
display_nameNoAnonymous
purchase_proofNo
idempotency_keyYes
parent_reply_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare write, non-destructive, idempotent, closed-world. The description adds genuinely useful context beyond them: 'No payment effect', the purchase-badge rule, that display names confer no role, and that consent is explicit. It still omits auth prerequisites, idempotency-key replay behavior, and failure modes, so it is additive but not rich.

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?

Five short sentences, front-loaded with the core action, no padding. Some statements ('Display names confer no role') are terse to the point of being cryptic, which slightly hurts scanability but wastes no space.

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

Completeness3/5

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

For a 7-parameter write tool with no output schema and very low schema description coverage, the description covers consent, badge, and threading but leaves idempotency semantics, error/retry behavior, and most parameter formatting to inference. Adequate but with clear gaps.

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

Parameters3/5

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

Schema description coverage is only 14% across 7 parameters (several completely undocumented: message, review_id, display_name, idempotency_key, operation_id). The description partly compensates by explaining parent_reply_id's threading rule, the visibility consent meaning, and the purchase-badge precondition, but many parameters remain unexplained in either place.

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?

States a specific verb (Publish) and resource (reply) plus an important qualifier ('untrusted', 'explicit public consent'). It is clear this creates a reply, but it never distinguishes itself from siblings like leave_feedback or submit_review, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is a single inline constraint ('parent_reply_id must be in this thread') but no when-to-use guidance, no when-not, and no routing versus the other reply/review siblings. An agent must guess whether this or leave_feedback is correct.

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.