Skip to main content
Glama

MisarSEO MCP Server

delete_gbp_review_reply

DestructiveIdempotent

Removes the owner's published reply from one Google review (reviewId from get_gbp_reviews). The removal is public and immediate. Confirm with the user before calling.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
reviewIdYesReview ID, from get_gbp_reviews.
projectIdYesRequired. The MisarSEO project ID to scope this call to. Get one from list_projects.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered structurally. The description adds genuinely new behavioral context beyond those hints: the removal is public-facing and takes effect immediately, plus a user-confirmation requirement, which the annotations cannot express.

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?

Three short sentences, each carrying distinct information (what is deleted, its visibility/timing, the confirmation requirement), with the core action front-loaded and no filler.

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 two-parameter destructive tool with no output schema and rich annotations, the description supplies what an agent most needs: exact scope, irreversibility via public/immediate framing, and a confirmation gate. Minor omissions (error or permission behavior on an already-deleted reply) are acceptable since the tool is idempotent.

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 100%, so both reviewId and projectId are already documented in the schema, including the get_gbp_reviews provenance that the description repeats. No additional format, constraint, or example is added, so the baseline of 3 applies.

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: 'Removes the owner's published reply from one Google review'. The scope ('one Google review') is explicit and it is distinguishable from the sibling reply_to_gbp_review, which adds or edits a reply rather than deleting one.

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?

Gives the prerequisite for the key parameter ('reviewId from get_gbp_reviews') and an operational caution ('Confirm with the user before calling'), which tells the agent when this call is appropriate. It does not, however, explicitly contrast itself with the alternative reply_to_gbp_review or state when not to use it.

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.