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

Annotations only declare readOnlyHint=false, so the description carries most of the burden; it usefully discloses the confirm-gated preview behaviour, which is the key operational trait. It does not say what permissions are required, whether the webhook replaces a previously set URL, or what the preview contains, so disclosure is partial.

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?

Two compact sentences, no filler, and the core action plus the access-policy choice are front-loaded ahead of the confirm-gating caveat. Every clause earns its place.

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 5-parameter mutating tool with no output schema and thin annotations, the description covers the gist but omits the semantics of unlockUrl, whether prior configuration is overwritten, and what the preview response looks like. Enough to know roughly what happens, not enough to call it confidently first time.

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%, so the description should compensate, but it only restates the mode enum values (ACTIVE_ONLY/ANY_MEMBER) that the schema already provides. organizationId, kioskId, unlockUrl and confirm meanings — including that organizationId is a gym id and unlockUrl is the endpoint that receives the open request — are left to the schema or undocumented.

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 (configure) and resource (a kiosk's door-unlock webhook plus the member-access policy), which is clearly distinct from create_gym_kiosk, list_gym_kiosks and revoke_gym_kiosk. It is clear what the tool does, though it doesn't explicitly name which sibling it complements.

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 word 'Configure' implies an existing kiosk must already exist, and the mention of kioskId confirms that, but the description never states prerequisites (kiosk must exist, org ownership) or when to use this versus create_gym_kiosk. Usage is implied rather than spelled out.

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