Wise

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

Discloses behavior: non-expiring connection via config, session-only via token paste. Annotations (idempotentHint: true) are consistent. No contradictions. Adds context about returning a link when no args provided.

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?

Somewhat lengthy but all sentences are relevant. Front-loaded with audience and main action. Could be slightly tighter, but still efficient for the information conveyed.

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 simple tool with one optional parameter and no output schema, the description covers how to use, what to expect (link or successful auth), and prerequisites. Fully complete.

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?

Despite 0% schema coverage, the description fully explains the sole parameter 'token': it's a JWT from browser login, optional, and its role in session authentication. Adds meaning 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 clearly states the tool is for authentication, detailing two methods: permanent config-based or session-based token paste. It uses specific verbs like 'log in', 'copy', 'paste', and distinguishes from siblings by being the only authentication tool.

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?

Explicitly describes when to use each approach: best to add to config for permanent access, or paste token for session-only. Also explains calling with no args to get the login link, providing clear contextual guidance.

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

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

Annotations already indicate readOnlyHint true and idempotentHint true. The description adds value by detailing the response structure in two states (all connected vs. missing credentials), which aids the agent in understanding behavior without surprise.

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 sentences, front-loaded with purpose, no wasted words. Efficiently conveys the key behavioral distinctions.

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?

Given no parameters, no output schema, and annotations covering safety, the description covers the main states (connected vs missing credentials). It could mention possible errors, but for a simple status endpoint it is sufficiently complete.

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?

No parameters, so baseline is 4 as per guidelines. Schema coverage is 100% for zero parameters, and the description adds no parameter info (none needed). The tool's output logic is explained, which is beyond parameter semantics.

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 clearly states the tool returns connection status and URLs, distinguishing states for connected vs missing credentials. It differentiates from sibling 'authenticate' by focusing on status rather than performing authentication.

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 implicitly guides when to use this tool (to check connection status) and explains expected outputs in different scenarios, but does not explicitly compare to alternatives like 'authenticate' or provide when-not-to-use guidance.

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

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

The description adds significant behavioral context beyond annotations, such as the fact that invoke can run a tool even if not installed, the need for auth/payment links, and the administrative requirements for writes. No contradiction with annotations.

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 well-structured with front-loaded purpose. It is somewhat lengthy but every sentence adds value. Could be slightly more concise without losing information.

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?

Given the tool's complexity (13 parameters, no output schema), the description covers the main workflow and edge cases (auth, payment, admin). Some parameter details are missing, but overall it provides sufficient context for an AI agent to use the tool effectively.

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 explains the meaning of many parameters (action, mcp_id, tool_id, arguments) but leaves some like immediate, tier_slug, conversation, request_name, report_context, request_details undescribed. Adds value but incomplete.

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 clearly states that this is the official mcp.ai marketplace, the first tool to use for finding and running MCPs. It distinguishes itself from siblings like authenticate, connect, etc., by describing the core flow of search, describe, and invoke.

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 provides explicit guidance: use this tool first before external registries, when to use invoke vs install, and notes that writes require owner/admin. It also mentions alternatives like list_tools and describe.

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

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

Annotations already indicate idempotentHint=true and destructiveHint=false, covering safety. The description adds context about including conversation for reproduction but does not disclose other behaviors like ticket creation or notification. Adds some value beyond annotations.

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 a single concise sentence that front-loads the core purpose and immediately provides key usage guidance. No unnecessary words.

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 simple feedback tool, the description adequately explains what to do (include conversation). It lacks detail on post-report behavior but is sufficient given low complexity and 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?

Schema coverage is 0%, so description must compensate. It gives meaning to 'message' (bug/feature/feedback) and 'conversation' (include recent messages). However, 'context' parameter is not mentioned, leaving a gap. Partially compensates but not fully.

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 clearly states the tool's purpose: report a bug, missing feature, or send feedback. It distinguishes itself from sibling tools like authenticate, connect, marketplace, etc., by focusing on issue reporting and feedback.

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 provides explicit guidance to include the conversation array with recent messages for reproduction. It does not mention when not to use or alternative tools, but the context is clear for its specific purpose.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that it returns 'platform and adapter versions', providing specific return value context beyond annotations.

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 a single sentence with no wasted words. It is front-loaded and directly conveys the tool's function.

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?

Given no output schema and no parameters, the description adequately explains the tool's purpose. It could potentially specify the format or list of version components, but for a simple version display, it is complete enough.

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 are no parameters, and schema description coverage is 100%. With zero parameters, the baseline is 4. The description does not need to add parameter information.

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 clearly states 'Show the current MCP platform and adapter versions', using a specific verb ('show') and resource ('versions'). This distinguishes it from sibling tools like 'authenticate' or 'marketplace' which have different purposes.

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 tool has no parameters and is a straightforward read-only operation, so usage context is clear. However, there is no explicit guidance on when not to use it or mention of alternatives, but given its simplicity, the implied usage is sufficient.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds valuable behavioral details about what data is returned (connection status, tool counts), which is beyond the annotations.

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 a single, well-structured sentence that front-loads the purpose ('Returns the current toolkit state') and efficiently lists the returned elements.

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 tool with no parameters and no output schema, the description sufficiently explains the return content. It could be slightly more detailed on format, but is adequate.

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?

No parameters exist, so the baseline is 4 per guidelines. The description correctly omits parameter details as none are needed.

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 clearly states the tool returns 'the current toolkit state' with specific details (installed MCPs, connection status, catalog tool counts). It is a distinct introspection tool compared to siblings like authenticate or connect.

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 implies usage when toolkit state information is needed, but does not explicitly provide when to use or alternatives. Context from sibling names suggests it's for diagnostic purposes, but guidance is lacking.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context: maximum window of 469 days, SCA protection (signing), and that it is the only endpoint for card transactions. No contradictions with annotations.

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 a single paragraph that front-loads the most important information (card transactions) and includes key constraints (469-day window, SCA). It is somewhat dense but efficient, with no unnecessary words. Could be slightly better structured with bullet points or sections.

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?

The tool has 9 parameters, 5 required, and no output schema. The description explains the purpose, key features (card transactions, bulk support), and constraints (window, SCA). However, it lacks details on return format, pagination, error handling, and parameter formats, leaving gaps for an agent to use 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?

Schema has 0% description coverage. The description explains that profile_ids and balance_ids support batch execution and implies interval_start/interval_end define the period, but does not explain parameters like type (COMPACT/FLAT) or account. Given the low coverage, the description adds some meaning but is insufficient for all 9 parameters.

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 clearly states it retrieves a complete balance statement including deposits, withdrawals, conversions, fees, interest, and crucially card transactions. It explicitly distinguishes this endpoint as the only one in the Wise API that exposes card transactions, giving it a clear unique purpose.

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 provides clear context on when to use this tool (to get card transactions) and mentions bulk support with profile_ids and balance_ids. However, it does not explicitly state when not to use it or directly compare with sibling tools like wise_get_card_transaction or wise_list_activities.

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

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

Annotations already declare readOnlyHint and idempotentHint, indicating a safe, read-only operation. The description adds the context that the token is obtained from specific activity or balance statement entries, which is useful but does not disclose additional behavioral aspects like rate limits or authentication requirements.

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 a single sentence plus a parameter specification, conveying essential information without any wasted words. It is front-loaded with the purpose.

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?

Given the tool's simplicity (2 parameters, no output schema), the description provides necessary context for the token but omits return value details. Without an output schema, the agent might benefit from knowing what fields are returned, but the name implies a standard transaction detail structure.

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%. The description explains the 'token' parameter's origin and format, adding significant meaning. However, the optional 'account' parameter is not explained, and the description does not fully compensate for the lack of schema descriptions for both parameters.

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 clearly states it returns details of a Wise card transaction. It specifies the token parameter source, but does not differentiate from sibling tools like wise_get_balance_statement.

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 tells where to obtain the token parameter (from wise_list_activities or wise_get_balance_statement), providing indirect usage context. However, it lacks explicit when-to-use or when-not-to-use guidance relative to other tools.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds value by noting SCA protection (Strong Customer Authentication) and bulk support via profile_ids, which are behavioral traits not covered by annotations. Also states ordering. However, it does not mention pagination or rate limits.

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?

Description is short (two sentences) but suffers from mixed language (Portuguese first, English second), which may reduce clarity for some agents. The structure is reasonable: first sentence describes the feed and content, second sentence adds bulk support. It could be more concise by being entirely in English.

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?

Tool has 9 parameters and no output schema. Description is incomplete: it does not explain the required profile_id parameter, does not describe filtering capabilities (since, until, status, etc.), does not mention pagination (next_cursor), and omits return value structure beyond listing item types. Significant gaps remain for an agent to use this tool fully.

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 description must compensate. It only explains the 'profile_ids' parameter for bulk execution. Other 8 parameters (size, since, until, status, account, profile_id, next_cursor, monetary_resource_type) are left unexplained, providing minimal guidance for an agent to use them correctly.

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?

Description states 'Feed unificado de atividades do profile' (unified activity feed), clearly indicating the tool lists all activity types. The verb 'list' and resource 'activities' are explicit. It distinguishes from sibling tools like wise_list_transfers or wise_list_balances by emphasizing 'unified', but could be more explicit about when to use this specific tool.

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?

Description provides context: 'mais recente primeiro' (most recent first) and 'SCA-protegido' indicating authentication requirements. Mentions bulk support with profile_ids. However, it does not explicitly state when to use this tool over alternatives, nor does it provide exclusions or prerequisites.

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

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

Beyond annotations (readOnly, idempotent, non-destructive), the description adds that each balance has an id used in another tool and mentions bulk execution. No contradictions, and adds useful behavioral context.

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, front-loaded with purpose, then details. No extraneous information. Each sentence 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?

No output schema exists, so description should clarify return values. It only mentions the balance id but not overall structure, pagination, or errors. Adequate for a simple list operation but leaves gaps.

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 describes 'types' (STANDARD vs SAVINGS) and 'profile_ids' for bulk, but does not explain 'account' or the required 'profile_id'. Only partial coverage of 4 parameters.

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 clearly states it lists multi-currency balances of a profile, distinguishes from sibling wise_get_balance_statement by mentioning the balance id is used there, and notes bulk support. The verb 'Lista' and resource 'saldos' are specific.

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 provides usage guidance: default STANDARD, pass 'SAVINGS' for jars/pots, and bulk support with profile_ids. It doesn't explicitly exclude others but implies when to use alternatives via the sibling mention.

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

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

Annotations already provide readOnlyHint=true and idempotentHint=true, indicating a safe read operation. The description adds the specific API endpoint and that it returns all profiles, but does not mention pagination, rate limits, or other behavioral traits. With annotations covering safety, the description provides moderate additional context.

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 sentences, front-loaded with the API call and return value, followed by usage guidance. No redundant or extraneous information. Highly efficient.

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?

The description adequately defines the tool's purpose and high-level behavior, but lacks details about the return format or structure (no output schema) and the parameter 'account' is not explained. Given the tool's simplicity and annotation coverage, completeness is acceptable but has clear gaps.

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 has one optional parameter 'account' with type string and 0% schema description coverage. The description does not mention this parameter at all, leaving its meaning and effect completely undefined. This is a serious gap for parameter understanding.

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?

Description clearly states the tool calls the Wise API /v2/profiles and returns all profiles (PERSONAL/BUSINESS) visible to the Personal Token. The verb 'returns' and resource 'profiles' are specific, and the purpose distinguishes it from sibling tools like wise_list_transfers or wise_list_balances.

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 explicitly says 'Use pra confirmar o profile_id antes de outras tools' (use to confirm profile_id before other tools), providing clear guidance on when to use it. It does not mention when not to use or alternatives, but the usage context is well implied for a prerequisite tool.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds context about SCA protection (authentication requirement) and bulk execution via profile_ids, which are useful behavioral details beyond the annotations.

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 very concise: two sentences that front-load the main purpose and then add filtering and bulk details. Every sentence adds value without redundancy.

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?

Given no output schema, the description covers the input side well with filtering and bulk options. It lacks details on response format or pagination, but for a listing tool, the essentials are present, making it mostly complete.

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?

With 0% schema description coverage, the description compensates by explaining the status CSV format, currency, and date filters, and the profile_ids parameter for bulk. However, many parameters like limit, offset, account, source_currency, and target_currency are not described, leaving gaps.

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 clearly states it lists P2P transfers (both sends and receives) from a profile. It distinguishes from sibling tools like wise_list_balances and wise_list_activities by specifying the resource type and adding filter details.

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 provides guidance on filtering by status, currency, and dates, and mentions bulk support. However, it does not explicitly state when to use this tool versus alternatives, leaving some ambiguity with sibling listing tools.

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