Lists all vouchers kept in this wallet's vault.
Lists all vouchers kept in this wallet's vault. These are vouchers issued by any account_fk in this wallet @param api_key: The api key allocated to your application @param token: The wallet_api_token provided by /access/login @param wallet_fk: The wallet_fk provided by /access/login
@return: a json object
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | ||
| api_key | Yes | ||
| wallet_fk | Yes |
Changes observed during successful MCP inspections.
Output schema / (root)Previous value: -{
- "type": "object"
-}New value: +nullDoes the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the read scope (vault contents, all issuers) and the auth prerequisites (api_key, token and wallet_fk from /access/login), but says nothing about pagination, filtering, rate limits, or the actual return shape beyond "a 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 purpose is front-loaded and the text is short, but the opening sentence is duplicated verbatim, which is pure waste and makes the definition look sloppy.
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 annotations and no output schema, the description should do more work. It covers auth sourcing but leaves the return value as an unhelpful "a json object," so an agent lacks detail on what a voucher list entry contains.
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 0%, so the description must compensate. It does name all three params and usefully states where token and wallet_fk come from (/access/login), but gives no type or format detail and leaves wallet_fk's integer type to the schema alone.
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 and resource ("Lists all vouchers kept in this wallet's vault") and adds that these are vouchers issued by any account in the wallet. It is clear what the tool does, but it does not explicitly distinguish itself from voucher-related siblings like netfluid__netfluid_voucher_check or paywall__pay_subscription_with_ott_voucher.
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?
There is no statement of when to use this tool, when not to, or which sibling to use instead. The only usage-adjacent info is that the tokens come from /access/login, which is prerequisite detail rather than routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.