Skip to main content
Glama

Submit a verified review

submit_verified_review
DestructiveIdempotent

Publishes the shopper's rating and review after a provider-verified completed Square checkout. Requires reviews:write scope and must be called by the original booking shopper. One review per booking; repeated calls return the original review without modification. This tool publishes public content visible to all shoppers.

Input Schema

NameRequiredDescriptionDefault
bodyYes
ratingYes
booking_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=true, openWorldHint=true), the description adds that the content is publicly visible to all shoppers, that only the original shopper may call it, and that repeated calls return the original review without modification. This gives valuable behavioral context, though it doesn't elaborate on the destructive nature of publishing public content.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four tight sentences, front-loaded with the core action and followed by the most important prerequisites. Every sentence adds useful information without repetition.

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 mutation tool with no output schema and existing annotations, the description covers authentication scope, caller identity, idempotency, and public visibility. The main gap is that parameter semantics are not explained, but the schema still provides types and constraints.

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

Parameters2/5

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

With schema description coverage at 0%, the description needs to compensate but largely does not. It mentions 'rating and review' and links booking_id to 'one review per booking', but it provides no detail on parameter formats, constraints (e.g., rating 1-5, body max 500 characters), or what each parameter expects.

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?

The description uses a specific verb ('Publishes') and resource ('rating and review'), and states the key precondition ('after a provider-verified completed Square checkout'). This clearly distinguishes it from the read-only sibling list_verified_reviews.

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 states clear prerequisites: a completed Square checkout, reviews:write scope, and the original booking shopper. It also implies when not to use it (one review per booking; repeated calls are no-ops). It doesn't explicitly name alternatives, but the only sibling for reviews is list_verified_reviews, which is obviously for reading rather than publishing.

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