send feedback to sync

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

Beyond the annotations it discloses the return shape ("returns only a receipt id"), the review cadence ("the team reviews reports daily"), server-side enrichment ("the server adds the client name and MCP version"), and a strong non-interference guarantee ("Does not change, retry or cancel any job") that pairs with destructiveHint=false. The "once per problem" instruction usefully compensates for idempotentHint=false by discouraging duplicate submissions, though it does not state whether a duplicate report errors or is quietly accepted.

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?

It is front-loaded with purpose, then timing, then exclusions, then parameter advice, then the non-interference guarantee — a sensible priority order with no filler sentences. It is a single dense paragraph, so the behavioral guarantee at the end is easier to miss than it would be as a separate sentence or bullet.

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 seven-parameter reporting tool with an output schema and full annotation coverage, nothing an agent needs is missing: what qualifies, when to send, when not to, which optional fields to populate, what comes back, and what side effects will not occur. Return values are correctly left to the output schema rather than duplicated.

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% so the baseline is 3, but the description goes further by adding cross-parameter guidance the schema cannot express: "Put the exact error text in message and fill tool, errorCode, and generationId or jobId whenever they apply." That resolves which optional identifier to use for which situation, a decision the per-field descriptions leave implicit.

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 opening sentence names a specific verb ("Report friction") and resource ("these sync. tools to the sync. team") and then enumerates concrete triggering categories (confusing error, wrong result, missing capability, extra steps, misleading description). No sibling tool is a feedback channel, so the definition is unmistakably distinct from the surrounding generations/transcriptions/assets tools.

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 states explicit timing ("once per problem after you have finished or stopped the task"), an explicit authorization rule ("without asking the user for approval"), and explicit exclusions ("Not for user support requests, success notes or questions that need an answer"). The alternative behaviors are named with the reason they are excluded (it returns only a receipt id), which is stronger than most definitions.

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