delegate_to_workbuddy

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

Annotations already indicate readOnly=false and destructive=false. The description adds valuable behavioral context: it sends a task to an external WorkBuddy, only routes risk=low, and requires the main agent to verify the returned result. This goes beyond the annotations and discloses a key operational requirement.

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 tight and well-structured. It front-loads the core purpose, then enumerates kinds, constraints, and the verification note. Each sentence adds necessary information without fluff, and the list of supported kinds is presented clearly.

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 7 parameters, no output schema, and annotations that only cover safety hints, the description is incomplete. It does not explain the required workspace parameter, the dry_run behavior, or the format of the returned result. The existence of a sibling workbuddy_read_result suggests the result retrieval mechanism should be mentioned, but it is not.

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?

With 0% schema description coverage, the description must compensate. It explains kind via the supported list, risk via 'Only risk=low', and text/files via 'explicit relative files or short provided text'. However, it does not explain the workspace (required), dry_run, or the instruction length constraint beyond 'bounded', leaving gaps for those parameters.

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 states a specific action ('Send one bounded low-risk text task to the user's installed WorkBuddy') with a clear resource and scope, and enumerates supported kinds. This clearly distinguishes it from siblings like workbuddy_status or workbuddy_plan, which handle different concerns.

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 gives clear context: use only for low-risk, bounded text tasks, and it notes the main agent must verify the result. However, it does not explicitly reference sibling tools or state when NOT to use it, so exclusions are absent but the scope is well-defined.

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