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

The description adds meaningful behavioral context beyond the annotations: credentials/config stay in the local MCP process (a security disclosure), and write methods require an exact one-call confirmation (a mutation guardrail). These align with openWorldHint=true and readOnlyHint=false, and there is no contradiction with destructiveHint=false.

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?

Three dense sentences with no filler: the core action is front-loaded, followed by a security note and a safety requirement. Every sentence earns its place, and the structure makes the most critical behavioral constraints immediately visible.

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 powerful open-world tool with 5 parameters, nested objects, and no output schema, the description covers the safety contract (local credentials, write confirmation) and channels, but it omits what the return value looks like, how method discovery works, and error/timeout behavior. The complexity is high enough that these gaps leave the agent partly under-informed.

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 only 40% (productId and writeConfirmation have descriptions), so the description must compensate for methodId, extensionId, and arguments. It clarifies that exactly one method is invoked and reinforces the exact write-confirmation format, but it adds no meaning for the arguments object or the format/length constraints of methodId and extensionId.

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 names a specific verb (execute), a precise resource (one method from an owned Pack), and the execution channels (HTTPS API, nested MCP server, local-skill child process). Combined with the title's 'auditioned client-owned extension,' it clearly differentiates this from siblings like run_ai_pack (whole-pack execution) and run_ai_pack_audition (pre-ownership evaluation).

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 context: the extension must be owned and auditioned (from the title), and the method-level granularity distinguishes it from whole-pack tools. However, it never explicitly names alternatives or states when NOT to use this tool versus run_ai_pack or prepare_local_ai_pack_run, leaving the agent to infer the routing.

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