Generate 2-3 reply drafts for one review using ReputeMap's tuned generator (the same one the app uses), and save the draft so it appears in the app's editor. NEVER publishes anything - drafts only.
| Name | Required | Description | Default |
|---|---|---|---|
| review_id | Yes | UUID from list_reviews |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no strong hints (readOnlyHint false, destructiveHint false, etc.), so the description carries the transparency burden. It discloses that the tool saves drafts (a side effect) and never publishes—key behavioral traits. It does not detail idempotency or overwriting behavior, but sufficient context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the primary action, and concisely adds a safety note. Every word earns its place; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter and no output schema, the description covers the core purpose, outcome, and constraints. It lacks an explicit statement of return value, but the action of generating and saving drafts implies the result. Overall, the description is sufficiently complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for review_id is 100% with a clear description ('UUID from list_reviews'). The tool description adds minimal value by specifying 'for one review,' but the schema already clarifies the parameter's purpose. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: generates 2-3 reply drafts for a single review, and saves them to appear in the editor. It explicitly contrasts with publishing by stating 'NEVER publishes anything - drafts only,' which distinguishes it from sibling publish_reply.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for generating drafts, not for publishing, with the explicit exclusion 'NEVER publishes anything - drafts only.' It does not explicitly name alternatives like publish_reply, but the context and exclusion are clear enough for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct action or resource: listing locations, listing reviews, aggregated stats, drafting vs. publishing replies, review requests, and usage tracking. The two reply tools are clearly separated by internal vs. public visibility.
All tools follow a consistent verb_noun pattern (list, get, draft, publish, send) with clear, descriptive nouns. No mixed conventions or vague verbs.
Seven tools provide a focused but complete set for the core reputation management workflows. Each tool serves a distinct purpose without redundancy or bloat.
Covers the main lifecycle: list locations/reviews, draft and publish replies, send review requests, and view stats. Minor gaps like direct editing of existing drafts or reply history are possible but not critical for core functionality.
