Skip to main content
Glama
Sign In
posterly-mcp-server

posterly-mcp-server

by awpthorp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

manage_google_business_review

Destructive

Generate brand-aware AI reply suggestions for Google Business Profile reviews, then post, update, or delete owner replies with preview-and-confirm safety.

Instructions

Act on Google Business Profile reviews. action=suggest_reply (star_rating, optional review_text): short, brand-aware AI reply suggestions; uses the AI Caption Assist allowance and never posts. action=reply (review_name, comment): post or update the owner reply. action=delete_reply (review_name): delete the owner reply. reply and delete_reply use preview then confirm: call without confirm to get a preview and preview_id (it repeats the review name, location, and exact reply text; show the reviewer, rating, and review text alongside it), then call again with confirm=true and that preview_id.

Input Schema

NameRequiredDescriptionDefault
toneNo
countNo
actionYessuggest_reply, reply, or delete_reply.
commentNoreply: exact owner reply text to post.
confirmNoreply and delete_reply: leave out to get a preview; true only with the preview_id after the user approved it.
account_idNoGoogle Business account ID from list_accounts (optional brand voice context for suggest_reply).
preview_idNoreply and delete_reply: the preview_id from the preview call. Required with confirm: true.
location_idNoGoogle Business numeric location id (the location_id/platform_user_id from list_accounts, e.g. "197940849675145390"). NOT the ChIJ... Place ID from list_google_business_reviews view=review_link. Prefer account_id.
review_nameNoreply and delete_reply: review_name from list_google_business_reviews.
review_textNosuggest_reply: review text. Leave empty for rating-only reviews.
star_ratingNosuggest_reply: review rating from 1 to 5.
workspace_idNoFilter to a workspace ID from whoami.
business_nameNo
reviewer_nameNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.55.1

TDQS

A4.4/5.0
Behavior4/5

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

Goes well beyond the annotations (destructive=true, openWorldHint=true, idempotent=false) by disclosing that suggest_reply consumes the AI Caption Assist allowance and never posts, and by specifying the preview/confirm safety gate with preview_id and what the preview echoes. It does not state auth/permission needs or what happens on replying to an already-replied review or deleting a nonexistent reply.

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?

Front-loaded with the purpose, then organized action-by-action with the workflow constraint last; virtually no filler. The final sentence is long and stacks parentheticals, which makes it harder to parse than necessary.

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 14-parameter, no-output-schema mutating tool this covers the essentials: what each action does, which parameters each action consumes, the destructive consequences, quota consumption, and the preview/confirm return shape. An agent can drive the full two-call flow from this description alone.

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?

At 71% schema coverage the description still adds real routing value by mapping parameters to actions (star_rating/review_text for suggest_reply, review_name/comment for reply, review_name for delete_reply) and explaining the confirm/preview_id pairing. It leaves tone and count entirely to the schema, so those params have no explanation of effect anywhere in the description.

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?

Opens with a specific verb+resource ("Act on Google Business Profile reviews") and immediately enumerates the three concrete operations: suggest_reply, reply, delete_reply. The read counterpart (list_google_business_reviews) is named as the source of review_name, so the agent can tell this mutating tool apart from the listing sibling without opening either schema.

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?

Each action is given a clear condition: suggest_reply for AI draft help (never posts), reply to post/update an owner reply, delete_reply to remove one, plus an explicit two-step preview→confirm protocol for the mutating actions. What is missing is an explicit "don't use this when..." case or guidance on which action to prefer when a reply already exists.

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

Deploy Server

Other Tools