Estimate payments abroad: fees, exchange rates, receiving accounts and payout coverage
Scored across 11 tools
Most tools target a clearly distinct question (rates, countries, banks, legal docs, stablecoins, quotes), and the descriptions add scoping hints like "use it only when" for the stablecoin pair. The only soft overlaps are get_receiving_accounts vs get_receive_quote and get_payout_options vs get_send_quote, where one lists capabilities and the other prices a specific payment; the wording does enough to separate them, but an agent could still pick the wrong one for a vague "can I get paid in EUR?" question.
All names are snake_case with a get_/list_ verb prefix, and list_ is used consistently for enumerations while get_ covers retrievals and quotes. The only wobble is the receive/receiving mismatch between get_receive_quote and get_receiving_accounts, which slightly breaks the otherwise predictable pattern.
Eleven tools is comfortably in the well-scoped range, and each one maps to a distinct user question (signup requirements, receiving, sending, payouts, banks, rates, stablecoins, legal). Nothing looks redundant or padded.
For an informational payments surface the lifecycle is well covered: eligibility, onboarding requirements, receiving/sending/payout pricing, bank reach, rate history, stablecoin rails and legal documents. Minor gaps remain — no live/current mid-market rate lookup (only historical series), no personal-account signup requirements parallel to the business one, and no transfer-status or support tool for someone mid-flow.
Shows what a business in a country is asked for when it signs up: the company types its registry recognises and what that registry calls the standard documents. Use it when a business owner asks what they need to get started.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered and the description needn't repeat it. What the description adds is the shape of the answer — per-country company types and document naming conventions — which genuinely helps an agent decide whether this answers the user's question. It says nothing about coverage gaps (e.g. what happens if a country is unsupported), which would be the useful extra for a closed-world lookup.
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, no filler, and the return-content sentence leads before the usage cue. The middle clause about registries is slightly dense but every part of it maps to something the tool returns, so little is wasted.
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?
There is no output schema, so the description must carry the return contract, and it does so at a high level but not exhaustively — it never mentions the country-code format, country coverage, or the failure mode for an unrecognised country. For a simple one-parameter lookup that is close to adequate, but the input-format omission is a real gap.
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% and the single required parameter is constrained by a regex (^[A-Z]{2}$) that is nowhere explained. The description says only 'a business in a country', which does not tell the agent that an ISO 3166-1 alpha-2 uppercase code is required — the exact thing most likely to cause a failed call. With low schema coverage the description should have compensated and does not.
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 names a concrete resource (business sign-up requirements per country) and even enumerates the payload: recognised company types and the registry's names for standard documents. That is far more specific than a restatement of the title. It stops short of a 5 because it never contrasts itself with the closest siblings, get_supported_countries and list_legal_documents, which an agent could plausibly confuse it with.
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?
"Use it when a business owner asks what they need to get started" gives a real, actionable trigger tied to a user intent rather than a vague 'use for retrieving data'. No exclusion or negative case is stated (e.g. when to prefer list_legal_documents), which keeps it below 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists where money can be paid out to a bank account: the country, the currency it arrives in, the method, the fee, the largest amount and how fast it arrives, for personal and business accounts. Give a country, a currency or both. Use it when someone asks whether they can send money to a country, what it costs or how long it takes.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | ||
| currency | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description adds useful context beyond that: both filters are optional and combinable, and it enumerates what the result rows contain in lieu of an output schema. No pagination, ordering, or result-size behavior is mentioned.
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 returned fields, then the input rule, then the usage trigger. The field enumeration is dense but every item is meaningful, and there is 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, describing the result columns is exactly the right compensation, and annotations cover the safety/mutation profile. The remaining gap is the input format (country/currency code conventions) and what happens when both filters are omitted.
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 the description must carry the load. 'Give a country, a currency or both' establishes validity when omitted and that they combine, but it never says the values are ISO-style codes (the ^[A-Z]{2}$ / ^[A-Z]{3}$ patterns imply this but the description doesn't), nor whether names are accepted.
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?
Specific verb+resource ('Lists where money can be paid out to a bank account') plus an enumeration of the returned fields (country, currency, method, fee, max amount, speed). It is clearly distinguishable from quote-oriented siblings like get_send_quote/get_receive_quote, though it never names an alternative explicitly.
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?
Explicit when-to-use trigger: 'Use it when someone asks whether they can send money to a country, what it costs or how long it takes.' No when-not cases or named alternatives are given, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shows how the mid-market exchange rate from US dollars to another currency has moved over the last 24 hours, 7 days, 30 days, 90 days or a year. Mid-market is the rate before any fees, so it is not the rate a payment is priced at, and a past series is no forecast. Use it when someone asks how a currency has moved against the dollar.
| Name | Required | Description | Default |
|---|---|---|---|
| range | Yes | ||
| currency | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the description is free to add domain semantics — that the series is mid-market, pre-fee, and historical rather than predictive. It does not describe the shape of the returned series, which matters somewhat since there is no output schema.
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 tight sentences: what it shows and its scope first, then the caveats, then the trigger. Every sentence earns its place 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?
For a two-parameter read tool with full annotation coverage, the definition is essentially complete on inputs, semantics, and safety. The one remaining gap is that with no output schema, the description never says what the returned history looks like (series of points, granularity), leaving the return value underspecified.
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 carries the burden and largely does: 'from US dollars to another currency' fixes the base currency as USD so 'currency' is clearly the target, and the range list spells out the enum values in human terms. It does not state the expected format for the currency code beyond what the 3-letter regex implies.
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?
States a specific verb and resource ('Shows how the mid-market exchange rate ... has moved') plus the exact scope (24h/7d/30d/90d/1y). The clarifying line that mid-market is not the rate a payment is priced at separates it from the quote-pricing siblings 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?
'Use it when someone asks how a currency has moved against the dollar' gives a concrete trigger, and 'it is not the rate a payment is priced at' plus 'a past series is no forecast' rules out two misuse cases. It stops short of naming the alternative tools (get_send_quote/get_receive_quote) for pricing questions, so routing is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimates how many US dollars arrive in a Poplin account when someone pays into its receiving bank account in another currency, with the rate, the fees and the deposit limits, for personal and business accounts at standard pricing. Use it when someone asks what they would receive for a payment in a currency such as EUR or GBP. It is an estimate; the final terms are shown in the Poplin app.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | ||
| currency | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds meaningful non-obvious context: the result is an estimate and final terms appear in the Poplin app, which tells the agent how to frame the answer. It does not discuss rate freshness or fee breakdown structure, keeping it below a 5.
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 the core estimate and followed by the usage trigger and estimate caveat. Minimal waste, though the pricing/account-type clause slightly crowds the opening sentence.
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, but the description tells the agent what the result contains (rate, fees, deposit limits) and warns it is non-binding. The main remaining gap is the ambiguity over which currency the amount is expressed in, which an agent could misread.
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 carry parameter meaning. It implies currency is the source payment currency ('such as EUR or GBP') but never clarifies that amount is denominated in that source currency, nor that currency follows ISO-4217 format. Partial compensation only.
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?
States a specific verb ('estimates') and a precisely scoped resource: the USD amount received when a payment arrives in another currency, including rate, fees, and deposit limits. The inbound direction ('pays into its receiving bank account') clearly distinguishes it from the sibling get_send_quote.
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?
Gives a concrete usage trigger ('Use it when someone asks what they would receive for a payment in a currency such as EUR or GBP') with examples. It stops short of explicitly naming get_send_quote as the alternative for outbound quotes, leaving that inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the currencies Poplin can open a receiving bank account in, whether the account takes payments from other people, and the fee and deposit limits for personal and business accounts. Pass a country to see whether people living there can open each account. Use it when someone asks how to get paid by bank transfer, in which currencies, or what it costs.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | ||
| currency | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real value beyond that by enumerating what the response contains (currencies, third-party payment capability, fees, deposit limits, split by personal/business) and explaining what the country filter does behaviorally — a residency eligibility check.
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, each doing distinct work: what is listed, what the optional filter does, and when to reach for the tool. The core payload is front-loaded and there is no filler or restatement of the title.
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 only two optional parameters, rich annotations and no output schema, the definition is nearly sufficient: it describes the returned dimensions so the agent knows what to expect. The remaining gap is the undocumented currency parameter and the absence of any note on result shape or whether both personal and business rows always appear.
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 the description must carry the parameter burden. It explains the country parameter well — pass a country to learn whether residents there can open each account — which is meaning beyond the bare two-letter pattern. The currency parameter is never mentioned in either the schema or the description, leaving half the parameters undocumented.
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 uses a specific verb (Lists) and names the resource and its contents precisely: currencies for receiving bank accounts, whether third-party payments are accepted, and fee/deposit limits for personal vs business accounts. It is clearly distinct from siblings like get_rate_history or list_banks, though it never explicitly names the closest alternative (get_payout_options / get_receive_quote) to sharpen the boundary.
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?
"Use it when someone asks how to get paid by bank transfer, in which currencies, or what it costs" gives concrete triggering questions, which is strong context. However, it offers no exclusions — an agent cannot tell from this text whether a pricing question belongs here or in get_receive_quote or get_payout_options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimates paying a bank account from a Poplin account: how much is sent in US dollars, how much arrives in the other currency, the rate, the fees, the limits and how fast it arrives, for personal and business accounts at standard pricing. Use it when someone asks what a payment would cost or how much the recipient would get. It is an estimate; the final terms are shown in the Poplin app before anything is confirmed.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | ||
| country | No | ||
| currency | Yes | ||
| amount_is | No | sent |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the description's main added value is the estimate-versus-commitment distinction: "the final terms are shown in the Poplin app before anything is confirmed." That is genuinely useful behavioral context an agent needs before quoting numbers to a user. It does not mention pricing assumptions beyond 'standard pricing' being fixed, or any auth/rate-limit behavior.
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 with the capability stated first, the usage trigger second, and the caveat last — a sensible front-loaded order. The enumeration of rate/fees/limits/speed is informative rather than padding, though the opening sentence is dense enough that it could be split for scanability.
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 usefully enumerates what comes back (sent amount, received amount, rate, fees, limits, speed), which is exactly what an agent needs to know before calling. The remaining gap is the currency/amount direction ambiguity noted above; otherwise nothing essential for a read-only estimation 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?
Schema description coverage is 0%, so the description carries the full burden, and it only partially compensates. The phrasing "how much is sent in US dollars, how much arrives in the other currency" gives conceptual meaning to the amount_is enum (sent vs received), but it never clarifies ISO format expectations for currency/country or, critically, whether `currency` is the source or destination currency. Field names alone still leave the source-currency assumption ambiguous.
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?
States a specific verb (estimates) and a precisely scoped resource: paying a bank account from a Poplin account, broken down into amount sent, amount received, rate, fees, limits and speed. The send direction and 'personal and business accounts at standard pricing' scope make it separable from siblings such as get_receive_quote and get_stablecoin_transfer_quote without opening any schema.
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?
"Use it when someone asks what a payment would cost or how much the recipient would get" gives an explicit trigger condition, and the closing sentence clarifies that this is pre-confirmation estimation only. It stops short of naming the alternative tools (e.g. get_receive_quote for inbound) or stating when not to use it, so it is clear context without full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the networks that stablecoins such as USDC can be received from and sent to, with the fee and speed for each, and Poplin's home network. Use it only when someone asks about stablecoin deposits or sends.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare this as read-only, idempotent, non-destructive, and closed-world, so the safety profile is clear. The description adds useful behavioral context by stating that the result includes fee, speed, and Poplin's home network, though it does not discuss auth or pagination concerns.
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 two tight clauses with no waste. The core purpose comes first, followed immediately by the usage restriction.
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 parameterless read-only listing tool with no output schema, the description gives enough detail about what the list contains. An agent can call it correctly and understand the expected result shape without further specification.
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 tool has zero parameters, so there is no parameter semantics burden and the baseline is 4. The description correctly does not invent input arguments.
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 uses a clear verb and resource: it 'lists the networks' and specifies what each entry includes (fee, speed, and Poplin's home network). This is specific enough for an agent to distinguish it from quote-oriented siblings like get_stablecoin_transfer_quote.
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 an explicit usage boundary: 'Use it only when someone asks about stablecoin deposits or sends.' However, it does not name the alternative tools or clarify when to prefer a stablecoin quote endpoint instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimates the fee and speed of sending USDC from Poplin to another network, such as Base or Ethereum, for a fast and a standard transfer. Use it only when someone asks about sending stablecoins to another network.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | ||
| network | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds that the quote returns fee and speed for both a fast and a standard option, which is genuinely useful, but says nothing about amount units, limits, or quote validity/expiry.
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, both load-bearing, with the capability stated before the usage restriction. No redundant restatement of the title.
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 two-parameter read-only quote tool with no output schema, the description covers what is computed (fee and speed, two tiers) and the domain restriction. Minor gaps remain around amount formatting and whether the returned quote is time-bound.
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 the description must compensate. It does partially: it establishes that the amount is denominated in USDC and that the network is the destination chain. It stops short of format guidance (e.g. amount as string decimal, maxLength 40) or whether the network must come from get_stablecoin_networks.
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?
Specific verb+resource: estimates fee and speed for sending USDC from Poplin to another network, and names the fast and standard tiers. It implicitly separates itself from get_send_quote by scoping to stablecoin-to-another-network, but never names that sibling explicitly.
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?
'Use it only when someone asks about sending stablecoins to another network' is an explicit when-to-use clause with a clear exclusion. It does not, however, point at the alternative to use for fiat sends or network listings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Says which countries people can sign up to Poplin from, including any regions that are excluded, and which countries money can be sent to. Pass a country to check one. Use it when someone asks whether Poplin works where they live or where they want to send money.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that by disclosing that exclusions are included and that the tool answers two distinct questions (signup eligibility versus payout destinations), though it says nothing about the response shape.
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 tight sentences with no filler: what is returned first, how to narrow it second, when to reach for it last. The most decision-relevant information is front-loaded.
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 annotations present and no output schema, the remaining burden is modest, and the purpose and usage coverage are solid. Still, the description leaves the accepted argument format and the shape of the returned data (list of countries? exclusion flags?) unstated, which an agent needs in order to call and interpret 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 coverage is 0%, so the description carries the full burden for the single `country` parameter. "Pass a country to check one" implies the argument is optional and that omitting it lists everything, but the required code format (the schema's ^[A-Z]{2}$ ISO alpha-2 pattern) is never stated, leaving an agent to infer it from the schema regex 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 names a specific verb-and-resource pair and splits it into two concrete facets: countries people can sign up from (including exclusions) and countries money can be sent to. That is a clear distinction from sibling tools like get_payout_options or get_receiving_accounts, though those siblings are never named explicitly.
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?
"Use it when someone asks whether Poplin works where they live or where they want to send money" gives explicit triggering conditions tied to the user's question. It does not name an alternative tool or state when to prefer a sibling instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the banks a bank payout can reach in a country, with the other names people know them by. Use it when someone asks whether a particular bank is supported. Only some countries have a bank list.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | ||
| currency | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds one genuinely useful caveat — 'Only some countries have a bank list' — implying possible empty or unsupported results. It says nothing about what happens for an unsupported country or what the response contains, leaving the main behavioral question unanswered.
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 short sentences, front-loaded with the core purpose and followed by usage and a caveat. No padding, though the final caveat sentence is placed where a parameter note would have been more valuable.
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 and zero parameter documentation, the description should at minimum explain the country/currency inputs and what a returned bank entry looks like. It covers purpose and one caveat adequately but leaves the agent guessing about the currency parameter's effect and about failure modes for unsupported countries.
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 carries the full burden for both parameters, yet neither is mentioned. The description never says that 'country' is a required two-letter code or what the optional 'currency' parameter changes about the result set, which is the one thing an agent could easily get wrong here.
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?
States a specific verb and resource — 'Lists the banks a bank payout can reach in a country' — and adds the alias detail, so an agent knows this is a bank directory lookup rather than a payout options list. It doesn't explicitly contrast itself with nearby siblings such as get_payout_options or get_supported_countries, which keeps it below a 5.
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?
'Use it when someone asks whether a particular bank is supported' gives a concrete triggering scenario, which is stronger than most definitions. It names no exclusions or alternative tools, so the agent is not told what to call instead when the question is about payout methods generally.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists Poplin's published legal documents, such as the terms of service, privacy policy and risk disclosure, with a link to the full text of each. Use it when someone asks about Poplin's terms, policies or what it doesn't allow. It returns links, not summaries.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds the non-obvious behavioral caveat that the output is references only ('returns links, not summaries'), which prevents the agent from fabricating content. It does not discuss size limits or pagination, but for a fixed, small document set that is a minor omission.
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 short sentences: what it lists, when to use it, and what it returns. The resource definition and examples are front-loaded, and the final sentence is a high-value constraint rather than 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?
There is no output schema, so the description must convey return values, which it does ('a link to the full text of each', 'returns links, not summaries'). For a zero-parameter, read-only list tool this is everything an agent needs to invoke it and interpret the result.
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 tool takes zero parameters, so the baseline is 4 and there is nothing for the description to compensate for. The description correctly spends no words on nonexistent inputs.
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?
States a specific verb and resource ('Lists Poplin's published legal documents') and enumerates concrete examples (terms of service, privacy policy, risk disclosure). It is unmistakably distinct from every get_*/list_banks sibling, which all return account, rate, or country data rather than policy text.
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?
Gives an explicit trigger condition: 'Use it when someone asks about Poplin's terms, policies or what it doesn't allow.' It also implicitly excludes a misuse case by noting it returns links, not summaries. No competing alternative tool is named, but none of the listed siblings could substitute.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_business_requirementsget_payout_optionsget_rate_historyget_receive_quoteget_receiving_accountsget_send_quoteget_stablecoin_networksget_stablecoin_transfer_quoteget_supported_countrieslist_bankslist_legal_documentsExchange rates, where Morse can send money, and indicative transfer quotes. No login needed.
Cross-border payment & banking intelligence for AI agents: SWIFT/BIC, IBAN, sanctions, FX, tracking.
Estimate dividend and interest withholding-tax refunds, treaty rates and filing deadlines.
Cheapest way to get paid: every route ranked by fee, from providers' own pricing pages, dated.
Add one secure layer between your agents and this server.
