Send feedback to Camberstack

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

Annotations only say this is a non-destructive, non-read-only, non-idempotent write with no open-world flag. The description goes well beyond that: a human reads it, a reply channel exists via the user's Google email, and a mandatory user-approval step precedes the send. It also discloses a data-minimization constraint (no account IDs, campaign data, or conversation history), which is real behavioral context an agent must respect.

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?

Four sentences, no waste, front-loaded with purpose then usage then safety protocol. Each sentence carries a distinct obligation (what it does, when, approval gate, content restriction).

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 could say what a call returns or how failures surface (e.g., if no Google email is on file to receive the reply). Otherwise complete for a 2-parameter write tool with full annotation coverage.

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 enum and length bounds are already documented; description adds genuine meaning by constraining content ("only what they want said", no account IDs/campaign data/history) and clarifying that the message must be the user-approved text. The `kind` parameter is left entirely to the schema, which is acceptable given full coverage.

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?

States a specific verb and resource ("Sends the user's message to Camberstack's maintainer") plus the recipient's behavior (reads every one, can reply by email). This is unmistakably distinct from every sibling, which are all analytics/merchant/search-console operations.

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?

Gives explicit triggering conditions ("when the user wants to report a bug or ask for something Camberstack doesn't do") and an explicit procedural gate: show the exact message first, send only after they agree. It also specifies what must NOT be included, which is an exclusion rule.

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