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

Beyond the annotations, it discloses the non-obvious side effect that calling it makes MCPify check deposit addresses every few seconds for the next few hours. It also explains the deposit lifecycle stages, though it does not discuss auth, limits, or whether the polling can be stopped.

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 sentences are used well: trigger first, returned content second, side effect third. Every sentence contributes selection or behavioral context with no filler.

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 no output schema, the description still explains what the tool returns: all in-progress deposits with steps and exact amounts below the minimum, plus recent finished deposits through the lifecycle. Combined with the fully documented limit parameter, an agent has enough to call it correctly.

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?

There is one optional limit parameter, and the schema already documents it fully with default, min/max, and the note that in-progress deposits are always listed. The description does not add parameter-specific meaning beyond the schema, so baseline 3 applies.

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 gives a specific verb and resource ('Lists their deposits') and scopes it to deposits in progress and recent finished deposits, including the lifecycle stages returned. That is enough to separate it from get_my_deposit_addresses (addresses) and preview_deposit (previewing) even without naming them.

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 triggering situations: the user says they sent a deposit or asks where their money is. It does not explicitly name alternatives or say when to use get_my_deposit_addresses/preview_deposit instead, so it stops short of full routing guidance.

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