Check Deposit Status

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

Although annotations already mark it readOnly, idempotent, and non-destructive, the description adds substantial behavior: it reveals the return shape, all four possible status values, and the poll-until-resolution pattern. Since there is no output schema, this return contract is essential and well covered.

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 cleanly sectioned: purpose, when-to-use, parameter, return contract, and examples. It is front-loaded with the operative verb and resource, and every block adds decision-relevant information. The examples are short and demonstrate natural-language invocation.

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 single-parameter, no-output-schema read-only tool, this is complete. It specifies the input, the full response contract including status enum, the intended workflow position after link generation, and the polling strategy. Nothing that an agent needs to correctly select and invoke the tool is missing.

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 input schema already documents 'reference' at 100% coverage, giving baseline 3. The description improves on that by identifying the exact provenance of the value: 'The reference returned from monei_generate_deposit_link.' This tells an agent where to obtain the parameter, which is more useful than the generic schema description.

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 opens with a clear verb-resource statement: 'Checks the status of a deposit by its reference string.' It names the exact resource (deposit), the action (check status), and the input (reference). Among siblings, only this tool and monei_generate_deposit_link involve deposits, so it is readily distinguishable.

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 explicitly explains when to call it: 'Use this after generating a deposit link to confirm whether the user has completed payment,' and gives a concrete polling cadence of every 30-60 seconds. It does not enumerate exclusions or name alternatives, but the usage context is specific enough for an agent.

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