Delegated Keys

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

Annotations declare readOnlyHint=false and destructiveHint=true, so the mutating/revoking nature is already covered. The description adds meaningful behavioral context beyond annotations: the CALL-ONLY restriction, the capability allowlist mechanism, and the daily MESH spend cap. It doesn't state what happens to active delegated keys on revoke, but given annotations already flag destructiveness, this adds good supplementary value.

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 tight two-sentence block that front-loads the core action (mint/list/revoke CALL-ONLY keys), then grounds the security model in a concrete example. Every sentence earns its place—no filler or redundant restating of the tool name. The 'Safe agent-hires-agent' tagline is memorable and communicates the intended use case in one phrase.

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 5 params (80% schema-covered), an action enum, and destructiveHint annotation, the description completes the picture well: it explains the key's restriction model, the daily spend cap, and the security boundary (can't list/buy/refer/mint keys). No output schema exists, so no return-format obligation. Minor gap: it doesn't clarify what 'MESH' currency is or whether revoke requires the original key, but these are ambient domain concepts.

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 80% with 5 parameters, all already described inline in the schema (id for revoke, allow for capability slugs, label as purpose, action enum, daily_cap for MESH spend). The description reinforces the allow/cap semantics ('capabilities you allow', 'capped at a daily MESH spend') but adds little beyond what the schema provides. Baseline 3 is appropriate given high schema 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?

The description states a specific verb set (Mint, list, or revoke) with a specific resource (CALL-ONLY delegated keys), and clearly delimits what the sub-key can and cannot do ('can't list, buy, refer, or mint further keys'). It also differentiates from siblings like mesh_refer and mesh_publish by framing this as an agent-hires-agent delegation mechanism. The key's restricted nature is made explicit.

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 conveys when to use this tool—when handing a sub-agent a restricted key—and describes the security context (sub-key limited to allowed capabilities and daily spend cap). It doesn't explicitly name a sibling alternative or state when NOT to use it, but the unique delegation purpose sits clearly apart from the sibling tools, which are mostly account/profile operations. No explicit exclusions, hence slightly below 5.

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