ReputeMap

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.

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is safe. The description adds behavioral context about the trailing window (default 30 days) and specific metrics returned, which is valuable beyond the annotations.

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?

A single concise sentence that conveys all essential information without wasted words.

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 no output schema, the description lists the metrics returned, which is adequate. However, it could be more explicit about the structure (e.g., per-location objects vs totals).

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 is 50% (days parameter lacks description in schema). The description adds the default 30 days and the concept of a trailing window. For location_id, both schema and description cover omission for all locations. Description adds some value but does not fully compensate for the missing schema description of days.

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 it provides 'Review stats per location and org totals' listing specific metrics, distinguishing it from sibling tools like list_reviews (individual reviews) and list_locations (just locations).

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 usage for aggregate stats but does not explicitly state when to use this tool vs alternatives like list_reviews for individual reviews or send_review_request for sending requests.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that usage is 'current month' and 'shared between REST API and MCP tools,' which provides some context beyond annotations. However, it does not describe output format or potential rate limits.

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?

A single, clear sentence that is front-loaded and contains no redundant information. Every word adds value.

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?

For a parameterless tool with annotations covering safety, the description sufficiently explains what the tool returns (current month usage, org-level, shared). No output schema exists, so a bit more detail on return format could be added, but it is adequate.

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?

The tool has zero parameters and schema coverage is 100%. Per guidelines, baseline is 4. Description does not need to add parameter meaning since there are none.

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 tool returns the current month's API credit usage for the organization, specifying the resource (usage credits) and verb (get). It distinguishes itself from siblings like get_review_stats and list_locations, which deal with different data.

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 does not provide any guidance on when to use this tool versus alternatives. It simply states what it does without context for selection among siblings.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description adds minimal behavioral context beyond stating it returns a list. It does not contradict annotations and provides the scope ('every business location this ReputeMap org manages').

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 a single sentence that conveys purpose and key detail (IDs for other tools) without unnecessary words. It is front-loaded and efficient.

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?

Given the tool has no parameters, no output schema, and is a simple listing operation, the description provides sufficient context: it lists all locations managed by the org and highlights the usefulness of IDs. Sibling tool names clarify the tool's distinct role.

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?

There are no parameters, and schema coverage is 100%, so the description does not need to elaborate. The mention of 'ids' pertains to the output, not parameters, and 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 uses the specific verb 'list' and clearly identifies the resource as 'business locations'. It also mentions the purpose of providing IDs for other tools, which distinguishes it from sibling tools that operate on reviews, stats, or requests.

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 that this tool should be used first to obtain location IDs for use in other tools, but it does not explicitly state when not to use it or provide comparisons to siblings. The context is clear but could be more directive.

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

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

Annotations already indicate a safe read operation (readOnlyHint, idempotentHint). The description adds value by revealing ordering, inclusion of reply text, and filter capabilities, which are behavioral details not present in annotations.

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-loaded with the main purpose, and every word adds value. There is no superfluous information.

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?

The description covers ordering, reply text, and filters, but omits pagination details (limit/offset, default limit, maximum results) and does not specify the full return structure in the absence of an output schema. Adequate but with gaps.

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 description coverage is 43%, so the description partially compensates by grouping filter categories (location, star-rating, replied/unreplied, trailing days). However, it does not add details for limit, offset, or rating_min/max beyond what the schema provides, missing an opportunity to clarify default behavior.

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 ('List'), the resource ('Google reviews for the org'), ordering ('newest first'), and includes that reply text is inlined. It also lists filtering options, distinguishing it from siblings like get_review_stats or list_locations.

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 the tool is for listing reviews with various filters, providing clear context. However, it does not explicitly state when to use alternatives like get_review_stats or when not to use this tool, so it lacks explicit exclusions.

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

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

Annotations already mark destructiveHint=true, but the description adds critical context: the action is public and customer-visible, and if the publish fails, the text is preserved with a manual fallback status. This reassures the agent that no data is lost, going well beyond the structured annotations.

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-loaded with the action verb and key constraint. Every sentence adds value: the first states the purpose and approval requirement, the second covers failure behavior. No word is wasted.

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?

For a destructive, open-world action with no output schema, the description provides sufficient context: it explains the public nature, the approval condition, and the failure fallback. It tells the agent what happens on both success and failure, making the tool's behavior predictable.

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 is 100%, with both parameters ('text' and 'review_id') already described clearly. The tool description does not add new parameter-level details; it reinforces the 'exact text' requirement already present in the schema. Baseline 3 is appropriate since the schema carries the parameter semantics.

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 starts with the specific verb 'PUBLISH' and clearly identifies the resource: 'a reply to this review's public Google profile.' It distinguishes from sibling draft_reply by explicitly marking this as the publish action, and adds the important qualifier that it is customer-visible.

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 gives an explicit when-to-use condition: 'call it ONLY when the user has explicitly approved this exact text.' It also explains the fallback behavior if Google rejects the publish, helping the agent understand the outcome and alternative path. This effectively tells the agent not to call it without approval.

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

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

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description discloses that it emails a real person, respects unsubscribes and suppression lists, and explains return statuses including 'already_requested' with no second email or credit spent. This is rich behavioral context for a side-effectful tool.

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?

Two sentences, front-loaded with the core action and immediately followed by the critical caveat and return statuses. Every word earns its place, no redundancy.

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?

Given no output schema, the description sufficiently explains the possible return values and side effects. It covers when to use, what happens (respects suppression), and important outcomes (already_requested prevents duplicate sends). The location_id prerequisite is covered in the schema.

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 description coverage is 100% (all three parameters have descriptions), so the description adds no additional parameter meaning. Baseline 3 applies; the description's mention of statuses does not directly clarify parameter usage beyond the schema.

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 tool sends a single review-request email to a real customer via ReputeMap's campaign engine. The verb 'Send' plus the specific resource 'review-request email' makes it distinct from the sibling read-only tools (get_review_stats, list_reviews, etc.).

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?

It explicitly states 'only use it when the user explicitly asks to request a review,' providing a clear condition for use. It does not name an alternative tool, but the guidance is strong enough to prevent misuse.

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