Skip to main content
Glama
Sign In

Blaze

by ai.blaze.app
OverviewDiscussionsAdmin

Send review reply

send_review_reply

Post a public reply to one review under the business's name. The reply appears on the review site right away and is visible to anyone. Confirm the exact text with the user before calling this.

Input: review_id from list_reviews_to_reply and text (the full reply, up to 4000 characters). Works for Google Business Profile reviews and, where enabled, Facebook reviews. Yelp, Angi, Thumbtack, BBB and Reddit reviews, and reviews that already have a reply, are refused; answer those on the review site.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "workspace_key": "<workspace_key>",
      "review_id": "<review_id>",
      "text": "<text>"
    },
    "name": "send_review_reply"
  }
}

Input Schema

NameRequiredDescriptionDefault
textYesThe exact reply to post, as approved by the user.
review_idYesThe review id from list_reviews_to_reply.
workspace_keyYesKey of the workspace to act in. Call list_workspaces to see the workspaces you have access to and their keys.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare the write/open-world/non-idempotent profile, but the description adds material behavior beyond them: the reply is published immediately, is publicly visible to anyone, has a 4000-character cap, and is rejected for certain platforms or already-answered reviews. Those refusal semantics are not derivable from the annotations and directly affect whether a call should be attempted.

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 paragraphs: what happens, an imperative safety instruction, then platform/refusal scope and input contract. The user-confirmation warning is placed before the input details so it is read before an agent acts. No filler sentences.

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

Completeness5/5

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

For a 3-parameter mutation with no output schema, the description covers the side effect, visibility, platform eligibility, refusal conditions, character limit, and a required confirm-with-user step. Nothing an agent needs in order to decide or invoke correctly is missing.

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 the baseline is 3, but the description adds meaning the schema does not: review_id must come from list_reviews_to_reply, and text is bounded at 4000 characters — a constraint absent from the schema field description. It does not explain workspace_key, which the schema does cover, so it falls short of a 5.

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 ('Post a public reply to one review') plus the acting identity ('under the business's name'), which distinguishes it immediately from draft_review_replies and list_reviews_to_reply. An agent can tell what it does and what it does not do without opening the schema.

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

Usage Guidelines5/5

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

Explicitly names the supported surfaces (Google Business Profile, Facebook where enabled) and enumerates the refused cases (Yelp, Angi, Thumbtack, BBB, Reddit, and reviews that already have a reply), with a redirect instruction ('answer those on the review site'). It also adds a hard precondition: confirm the exact text with the user before calling.

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

All Blaze toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources