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

With no annotations, the description carries the full burden of behavioral disclosure. It incorrectly claims to block access before correctly stating it resumes access, creating confusion about the actual behavior. It mentions the admin privilege requirement but does not disclose side effects, reversibility, or return value details beyond a generic JSON object.

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 not concise due to the contradictory and unnecessary first line 'Temporarily blocks access to the wallet', which wastes space and misleads. The @param and @return structure is somewhat redundant with the schema and not well integrated.

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?

Despite having an output schema, the description lacks critical context: it doesn't resolve the contradiction between blocking and resuming, doesn't clarify the exact effect on the wallet, and doesn't mention any prerequisites beyond admin privileges. This is insufficient for a tool with no annotation support.

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?

The description adds some value to the parameters by stating that api_key must have administrator privileges and that wallet_fk refers to the wallet to resume. However, with 0% schema description coverage, it only provides minimal clarification and does not explain constraints, formats, or additional context beyond the schema.

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 'Resumes access to a paused wallet' which is clear, but the opening line 'Temporarily blocks access to the wallet' directly contradicts the intended action and the tool name. This makes the purpose confusing and potentially misleading for an agent.

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 clearly implies when to use the tool (when a wallet is paused and needs to be resumed) and specifies a prerequisite (api_key with administrator privileges). However, it doesn't explicitly exclude other use cases or compare with sibling tools like access_pause or access_recover.

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