Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@CurrencyTransfer MCP Server show me my account balances"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for the CurrencyTransfer API. Lets AI assistants trade FX, manage beneficiaries, check balances, request quotes, and configure rate alerts, market orders and RSI alerts/market orders.
Node.js 18 or newer
A CurrencyTransfer account with API credentials
Related MCP server: Mono Banking MCP Server
git clone https://github.com/currencytransfer/mcp-currencytransfer.git
cd mcp-currencytransfer
npm install
npm run buildVariable | Required | Description |
| Yes | Your CurrencyTransfer account ID (Basic auth username) |
| Yes | Your CurrencyTransfer API key (Basic auth password) |
| No | API base URL. Defaults to |
This server uses stdio transport. Your MCP client will start it automatically — you do not need to run it in a terminal.
Add the following to your client's MCP config file. The JSON structure is the same across most clients; only the file location differs:
Client | Config file |
Cursor |
|
Claude Desktop |
|
VS Code |
|
Windsurf |
|
{
"mcpServers": {
"currencytransfer": {
"command": "node",
"args": ["<git-repo-clone-location>/mcp-currencytransfer/dist/index.js"],
"env": {
"CT_API_KEY": "your-account-id",
"CT_API_SECRET": "your-api-key",
"CT_BASE_URL": "https://stage.currencytransfer.com/api/v1"
}
}
}
}Restart your MCP client after saving the config. The server should then appear in the client's MCP settings or tool list.
The server exposes tools for:
Currencies — tradable pairs, RSI pairs, payment methods, cut-off times
Countries — supported countries and payment methods
User — authenticated user profile and permissions
Quotes — FX quote requests
Trades — create, list, and manage trades and documents
Beneficiaries — manage payment beneficiaries
Balances — account balances
Rate alerts — standard and RSI (MOEX) rate alerts and market orders
Checks if a payment purpose is required when creating a payment to a specific beneficiary.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | UUID of the beneficiary |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It implies a read-only operation but omits details such as error behavior for invalid UUIDs or side effects. The description is minimal and does not address potential edge cases.
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 of 15 words. It is concise and to the point, with no superfluous 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?
For a simple check tool with one parameter and no output schema, the description is adequate but lacks information about the return value (e.g., boolean indication). Completeness is average given no additional details are provided.
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 description adds meaning beyond the schema by specifying that the payment is created 'to a specific beneficiary', clarifying the role of the UUID parameter. The schema already has 100% coverage, but the context enriches 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?
The description clearly states the tool's function: checking if a payment purpose is required for a specific beneficiary. The verb 'checks' and the specific resource 'payment purpose requirement' make it distinct from sibling tools that create or manage payments or beneficiaries.
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?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, conditions, or suggest when not to use it, leaving the agent without context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a new beneficiary (recipient bank account).
| Name | Required | Description | Default |
|---|---|---|---|
| nickname | Yes | Unique alias for the beneficiary | |
| type | Yes | ||
| currency | Yes | 3-letter ISO 4217 currency code | |
| bank_account_country | Yes | 2-letter ISO 3166-1 country code | |
| first_name | No | Required if type is individual | |
| last_name | No | Required if type is individual | |
| company_name | No | Required if type is company | |
| No | Email for payment dispatch notifications | ||
| iban | No | ||
| bic_swift | No | ||
| account_number | No | ||
| sort_code | No | ||
| aba | No | ||
| bsb | No | ||
| routing_number | No | ||
| line1 | No | Beneficiary address line 1 | |
| line2 | No | Beneficiary address line 2 | |
| city | No | ||
| country | No | 2-letter ISO 3166-1 country code | |
| state | No | Required if country is CA or US | |
| postal_code | No | Required if country is CA or US |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action without disclosing behavioral traits like validation, idempotency, required permissions, or impact on existing data.
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 with no wasted words. However, it could be better structured (e.g., listing key requirements) for clarity.
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 complexity (21 parameters, conditional logic based on type and country), the description is too brief. It omits any summary of parameters or behavioral notes, leaving the schema to do all the work.
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 57%, so the schema already describes many parameters. The description adds no extra meaning beyond the schema, meeting the baseline for moderate coverage.
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 explicitly states the action ('Creates') and the resource ('new beneficiary (recipient bank account)'), distinguishing it from sibling tools like update_beneficiary or delete_beneficiary.
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 no guidance on when to use this tool versus alternatives, such as create_beneficiary_email_request or validate_beneficiary. No context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sends an email to a beneficiary asking them to provide their bank account details.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email address of the beneficiary | ||
| currency | Yes | 3-letter currency code for the bank account | |
| bank_account_country | Yes | 2-letter country code for the bank account | |
| nickname | No | Nickname to assign to the beneficiary once they respond |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of behavioral disclosure. It only states the tool sends an email but does not explain side effects (e.g., whether a request record is created), idempotency, or required permissions. The description is too minimal for safe invocation.
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 directly states the tool's purpose without unnecessary words. It is front-loaded and 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?
Given the simple tool and full schema coverage, the description provides the core action. However, it omits critical context such as whether the beneficiary must exist prior to sending, what the response contains (e.g., request ID), and whether this is a one-time email or creates a pending beneficiary record.
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 100%, so each parameter is documented. The tool description adds no additional semantic value beyond what the schema already provides. Baseline of 3 is appropriate per scoring rules.
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 sends an email to a beneficiary requesting bank account details, specifying the verb and resource. It distinguishes from sibling tools like create_beneficiary (which creates a beneficiary) and update_beneficiary_email_request (which modifies requests).
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 no guidance on when to use this tool versus alternatives like create_beneficiary or validate_beneficiary. It does not mention prerequisites (e.g., whether the beneficiary must already exist) or scenarios where this tool should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a quote for a currency exchange. Returns broker quotations valid for 15 seconds. Use refresh_quote to get new quotations after expiry.
| Name | Required | Description | Default |
|---|---|---|---|
| sell_currency | Yes | 3-letter ISO 4217 currency code the client has (e.g. EUR) | |
| buy_currency | Yes | 3-letter ISO 4217 currency code the client wants (e.g. USD) | |
| side | Yes | Whether the amount refers to the sell or buy currency | |
| amount | Yes | Amount to exchange | |
| delivery_date | Yes | Delivery date in YYYY-MM-DD format | |
| reason | Yes | Transfer reason. Allowed chars: [a-zA-Z0-9\s\-/?:().,'+] | |
| only_from_brokers | No | Optional list of broker codes to restrict quotations to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the 15-second validity but doesn't mention persistence, authentication needs, or side effects.
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 succinct sentences: first states purpose, second provides guidance. No wasted words and 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?
Explains return value is broker quotations valid for 15 seconds, but lacks details on structure (e.g., quote ID, rate). Adequate for simple use, but could be richer.
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 100%, so the description adds minimal value beyond contextualizing the 'only_from_brokers' parameter. Baseline 3 is appropriate.
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 creates a quote for currency exchange and mentions the 15-second validity period, distinguishing it from sibling tools like create_trade and refresh_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?
Explicitly advises using refresh_quote after expiry, providing an alternative. However, it doesn't specify when not to use this tool or contrast with similar tools like create_trade.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a rate alert. When the market rate reaches target_rate, you are notified. If book=true the trade is automatically booked.
| Name | Required | Description | Default |
|---|---|---|---|
| sell_currency | Yes | 3-letter currency code the client has (e.g. EUR) | |
| buy_currency | Yes | 3-letter currency code the client wants (e.g. USD) | |
| side | Yes | ||
| amount | Yes | Amount in the side currency | |
| target_rate | Yes | The exchange rate that triggers the alert | |
| book | No | If true, automatically book a trade when target rate is reached (default: false) | |
| reason | No | Required if book=true. Transfer reason. | |
| delivery_date | No | Fixed delivery date in YYYY-MM-DD format (useful for forward contracts) | |
| expiration_date | No | Alert expiry date in YYYY-MM-DD format (max 30 days; defaults to max) | |
| note | No | Optional note to attach to the alert | |
| broker_code | No | Restrict auto-booking to a specific broker |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Clearly mentions notification on rate reached and auto-booking if book=true. Could be improved by noting if alerts are recurring or one-time, but overall sufficient.
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: first states the purpose, second adds the key auto-booking behavior. No redundant information, every word 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?
Description covers core purpose and key behavior, but lacks information about what the tool returns (e.g., alert ID or confirmation). No output schema exists, so description should compensate for missing return value details.
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 91%, high. Description adds value beyond schema by explaining notification behavior ('When the market rate reaches target_rate, you are notified') and auto-booking trigger, which are not fully captured in parameter descriptions.
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 'Creates a rate alert' with specific verb and resource. Distinguishes from sibling tools like list_rate_alerts, delete_rate_alert, and create_rsi_alert by focusing on creation and auto-booking behavior.
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?
Usage is implied: set up a rate alert for a target rate. No explicit guidance on when to use versus alternatives like create_trade or create_rsi_alert, nor when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates an RSI (MOEX) market order. Triggers when the RSI indicator for the currency pair reaches target_rsi. Optionally auto-books the trade and splits the total amount into tranches.
| Name | Required | Description | Default |
|---|---|---|---|
| sell_currency | Yes | 3-letter currency code the client has (e.g. EUR) | |
| buy_currency | Yes | 3-letter currency code the client wants (e.g. USD) | |
| side | Yes | ||
| amount | Yes | Total amount | |
| target_rsi | No | RSI threshold to trigger (default: 70) | |
| book | No | Auto-book when RSI threshold is reached (default: false) | |
| reason | No | Required if book=true | |
| expiration_date | No | Expiry date YYYY-MM-DD (max 30 days) | |
| delivery_date | No | ||
| minimal_rate | No | Minimum acceptable rate — trade only books if RSI AND rate conditions are both met | |
| book_remaining_amount_on_expiration | No | If true, books remaining unexecuted amount when the alert expires | |
| beneficiary_uuid | No | Assign a beneficiary — auto-creates a payment when trade is booked | |
| payment_reference | No | Required if beneficiary_uuid is provided | |
| payment_purpose | No | Required if beneficiary_uuid is provided | |
| splits | No | Split total amount into tranches, each executed when RSI triggers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the trigger condition and optional auto-booking/splitting but does not disclose side effects, permissions, or behavior in edge cases (e.g., partial fills, expiration handling).
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 core purpose, no wasted words. Efficient and clear.
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 absence of an output schema and 15 parameters, the description covers the primary behavior but lacks details about expiration, beneficiary integration, and conditional booking rules. Some of this is in parameter descriptions, but the description could be more comprehensive.
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 high (87%), but the description adds meaningful context by explaining that the alert triggers on RSI, auto-books, and splits into tranches. This goes beyond the schema's individual parameter descriptions.
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 creates an RSI market order triggered by the RSI indicator, with optional auto-booking and splitting. It uses a specific verb and resource, and distinguishes from sibling tools like create_rate_alert and create_trade.
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 for RSI-based triggers but does not explicitly say when to use this tool versus alternatives (e.g., create_rate_alert). No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Books a trade using a broker quotation UUID. The client must agree to terms. Broker quotations expire after 15 seconds — use refresh_quote if needed.
| Name | Required | Description | Default |
|---|---|---|---|
| broker_quotation_uuid | Yes | UUID of the broker quotation to book | |
| agree_to_terms | Yes | Must be true — client agrees to terms and conditions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses expiration (15 seconds) and agreement requirement, but lacks post-conditions (e.g., what happens after booking: trade state, confirmation). This moderate disclosure earns a 3.
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-load the main action, with no wasted words. Every sentence serves a purpose: defining action and providing critical constraint (expiration + alternative).
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 (two params, no output schema), the description covers preconditions and constraints well. It lacks details on return values or trade confirmation, but overall it's suitably complete for the complexity level.
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 100% with parameter descriptions. The description adds value by linking 'agree_to_terms' to the client agreement requirement and explaining the expiration context for the UUID, going beyond schema basics.
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 it books a trade using a broker quotation UUID, which is a specific verb+resource pair. It also distinguishes from sibling tool 'refresh_quote' by mentioning expiration and alternative action.
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?
Provides explicit when-to-use context (book a trade) and an alternative tool ('refresh_quote') for expired quotations, meeting the criteria for high usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a payment for a trade, allocating funds to a beneficiary.
| Name | Required | Description | Default |
|---|---|---|---|
| trade_uuid | Yes | UUID of the trade | |
| beneficiary_uuid | Yes | UUID of the beneficiary to pay | |
| amount | Yes | Payment amount in the buy currency | |
| reference | No | Payment reference | |
| payment_date | No | Payment date in YYYY-MM-DD format | |
| payment_type | No | ||
| reason | No | Payment reason |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states the basic action. It does not disclose side effects, authorization requirements, or irreversible consequences, which is a significant gap for a write operation.
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?
A single sentence clearly conveys the core purpose without unnecessary words. It is appropriately sized for a simple creation tool.
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 complexity (7 parameters, no output schema), the description lacks details about prerequisites, what happens after creation, or how this fits into the payment workflow. Incomplete for effective use.
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 86% schema description coverage, the schema already documents most parameters. The description adds no additional semantic value, so it meets the baseline but does not exceed it.
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 action (creates), the resource (payment for a trade), and the purpose (allocating funds to a beneficiary), effectively distinguishing it from siblings like update_trade_payment or delete_trade_payment.
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?
No guidance on when to use this tool vs alternatives such as validate_trade_payment or create_beneficiary_payment (not listed but implied). Lacks context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Soft-deletes a beneficiary.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | UUID of the beneficiary to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description bears full responsibility for behavioral disclosure. While it discloses that the action is a 'soft-delete' (implying reversibility), it omits details on authorization requirements, side effects (e.g., cascading to payments), or return behavior. For a mutation tool, this is insufficient.
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 extremely concise: a single, front-loaded sentence that conveys the core action without extraneous words. Every word contributes value, making it easy for an agent to quickly parse.
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?
Despite the tool's simplicity (one param, no output schema), the description lacks completeness. It does not explain success/error behavior (e.g., returns an empty response, throws if not found), nor does it clarify the implications of 'soft-delete' (e.g., visibility in future lists). The agent is left with unanswered questions.
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 provides a 100% description coverage for the single parameter 'uuid', explaining it as the 'UUID of the beneficiary to delete'. The tool description does not add further semantics but there is no need given the schema's completeness. Baseline score of 3 is appropriate.
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 action ('soft-deletes') and the resource ('beneficiary'), effectively distinguishing it from siblings like 'delete_beneficiary_email_request'. However, it does not elaborate on what 'soft-delete' entails, such as marking as inactive versus removal.
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 no guidance on when to use this tool versus alternatives (e.g., update_beneficiary, delete_beneficiary_email_request). It does not mention prerequisites, such as ensuring the beneficiary exists or is not linked to active trades, nor does it state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancels a pending beneficiary email request.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | UUID of the beneficiary | |
| request_uuid | Yes | UUID of the email request to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description lacks disclosure of side effects, permissions needed, or what happens post-cancellation. No annotations 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?
Single sentence, concise, no wasted 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?
Misses details on prerequisites, return values, error conditions, and state of the request. Given no output schema, more context needed.
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 100% description coverage; description adds no extra meaning beyond 'UUID of the beneficiary' and 'UUID of the email request to delete'.
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 'Cancels a pending beneficiary email request' with specific verb and resource. Distinguishes from siblings like create_beneficiary_email_request and update_beneficiary_email_request.
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?
No guidance on when to use this tool versus alternatives. Lacks context on prerequisites or conditions like 'request must be pending'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancels and deletes a rate alert.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | UUID of the rate alert to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions 'cancels and deletes' implying mutation but lacks details on side effects (e.g., irreversible?), error states (e.g., alert not found), or authorization needs. Minimal disclosure for a destructive operation.
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?
Single concise sentence, front-loaded with the key action. No wasted words, but could afford a bit more context without losing conciseness.
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 (one parameter, no output schema), the description is minimally adequate. However, without annotations or usage guidance, it leaves the agent without behavioral context for a destructive action. Could be improved with idempotency or error info.
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 100% (uuid documented as 'UUID of the rate alert to delete'). The description adds no extra meaning beyond the schema. Baseline 3 is appropriate as schema does the heavy lifting.
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 action ('Cancels and deletes') and the resource ('rate alert'), making it distinct from sibling tools like create_rate_alert or update_rate_alert. The verb-resource pairing is specific and unambiguous.
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?
No guidance on when to use this tool versus alternatives (e.g., delete_rsi_alert) or conditions for deletion (e.g., existing active alert). The description provides no prerequisites, context, or restrictions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancels and deletes an RSI (MOEX) market order.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | UUID of the RSI alert to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the core action (canceling and deleting) but lacks details about side effects, permissions, irreversibility, or impact on related data. Without annotations, more behavioral context is expected.
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, which is concise but lacks structure such as bullet points or separation of purpose and usage. It is minimal but not well-organized.
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 is a deletion action with no output schema and no annotations, the description should provide more context about consequences or prerequisites. It falls short of being 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?
Schema coverage is 100% for the single parameter 'uuid', and the description does not add meaning beyond the schema's own description. Baseline score applies as schema is sufficient.
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 it cancels and deletes an RSI market order, but the tool name refers to an 'rsi_alert', creating potential confusion between an alert and a market order. The verb and resource are partially clear but could mislead.
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?
No guidance is provided on when to use this tool versus alternatives like delete_rate_alert or update_rsi_alert. The description does not include any usage context or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deletes an attached invoice or proof of settlement document from a trade.
| Name | Required | Description | Default |
|---|---|---|---|
| trade_uuid | Yes | UUID of the trade | |
| uuid | Yes | UUID of the document to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It indicates deletion but does not mention irreversibility, permission requirements, side effects (e.g., impact on trade state), or error conditions. The lack of detail leaves the agent underinformed about consequences.
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, clear sentence with no wasted words. It front-loads the action and resource, making it easy to parse quickly.
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 (two parameters, no output schema), the description is mostly complete. However, it omits information about success/failure responses (e.g., whether it returns a status or confirmation), which would be helpful for an agent expecting feedback.
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 100%, but the description adds value by specifying the document types ('invoice or proof of settlement'), which clarifies the scope beyond the schema's generic 'document' description. This helps the agent understand what kind of UUID is expected.
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 action ('Deletes') and the specific resource ('attached invoice or proof of settlement document from a trade'). It effectively distinguishes from sibling tools like delete_beneficiary or upload_trade_document by specifying the document type and context.
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 no context on when to use this tool versus alternatives, no prerequisites, and no exclusions. It only implies usage via the action but fails to guide the agent on decision-making between related tools like delete_trade_payment or upload_trade_document.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deletes a payment from a trade.
| Name | Required | Description | Default |
|---|---|---|---|
| trade_uuid | Yes | UUID of the trade | |
| uuid | Yes | UUID of the payment to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully convey behavior. It only states the action but lacks details on irreversibility, side effects, permission requirements, or error states. As a destructive operation, more transparency is needed.
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, but it could be expanded slightly to include more useful context without losing conciseness.
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 delete operation, the description is minimally adequate, but it lacks information on idempotency, return values, and error handling, especially given no output schema. More details would improve completeness.
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?
Both parameters have descriptions in the input schema (100% coverage), so the description adds no new meaning. Baseline score of 3 applies since schema already documents the parameters adequately.
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 action 'Deletes' and resource 'payment from a trade', distinguishing it from sibling tools like create_trade_payment, update_trade_payment, and get_trade_payment.
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?
No guidance on when to use this tool versus alternatives, no prerequisites mentioned, and no context for when not to use it. The description is too brief to provide any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns address requirements for all countries.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the tool is simple with no parameters. The description does not disclose any behavioral traits such as return format or performance, but the lack of complexity reduces the need.
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 single sentence is concise but could include brief context (e.g., output scope) without becoming verbose.
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?
Adequate for a simple retrieval with no parameters, but lacks explanation of output format or limitations, especially given the existence of a more specific sibling.
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 schema coverage is 100%. The description adds no extra semantic value beyond the schema, meeting the baseline of 3.
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 address requirements for all countries, but does not differentiate from the sibling tool get_address_requirements_by_country, which suggests a more targeted use case.
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?
No guidance on when to use this tool versus the more specific get_address_requirements_by_country. The agent has no context to decide between the two.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns address requirements for a specific country.
| Name | Required | Description | Default |
|---|---|---|---|
| country_code | Yes | 2-letter ISO 3166-1 country code (e.g. GB, US) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description has the full burden of behavioral disclosure. It does not specify whether the tool is read-only, what happens if the country code is invalid, or the structure of the returned data. The description is too minimal to convey behavioral traits.
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 concise and front-loaded, conveying the core purpose in a single sentence. However, it could benefit from additional context without becoming verbose.
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 has one parameter and no output schema, the description is somewhat complete but lacks detail on the format or structure of the return value. It is adequate for a simple query but could be more informative.
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 schema provides 100% coverage with a clear description of the 'country_code' parameter. The description adds no new information beyond the schema, so a baseline score of 3 is appropriate.
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 address requirements for a specific country, which is direct and informative. However, it does not distinguish itself from the sibling tool 'get_address_requirements', which may have a similar 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 no guidance on when to use this tool versus alternatives, such as 'get_address_requirements' or other related tools. There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns bank account details for depositing funds to top up a balance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the function and does not mention safety (e.g., read-only), rate limits, or any side effects. Minimal transparency.
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 unnecessary words. It efficiently conveys 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?
The tool has no output schema and no annotations, so the description should elaborate on return values or field details. It only says 'bank account details' without any specifics, making it incomplete for an agent to understand the output.
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 zero parameters (100% coverage), so the description adds no parameter information. Per rubric, baseline of 3 is appropriate when schema coverage is high and no params need explanation.
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 bank account details for depositing funds to top up a balance, using a specific verb and resource. It distinguishes from siblings like list_balances or initiate_balance_payment, but does not specify whose balance (e.g., user's own), leaving slight ambiguity.
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?
No guidance is provided on when to use this tool versus alternatives, such as initiate_balance_payment. The description does not indicate prerequisites or typical workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns required bank account fields per currency and country combination.
| Name | Required | Description | Default |
|---|---|---|---|
| currency | No | 3-letter ISO 4217 currency code to filter by | |
| bank_account_country | No | 2-letter ISO 3166-1 country code to filter by |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description should disclose behavioral traits. It only states a simple query operation but lacks information on rate limits, authorization needs, or side effects.
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 with no unnecessary words. Efficient but could include more context without sacrificing brevity.
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, no annotations, and parameters are optional despite description implying both are needed. Incomplete context for the agent to understand behavior when no parameters are provided.
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 100%, and the description adds no additional meaning beyond what the schema already provides for the two 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 the tool returns required bank account fields filtered by currency and country. It differentiates from sibling tools focused on beneficiaries, trades, etc.
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?
No usage guidelines are provided. The description does not indicate when to use this tool over alternatives like get_address_requirements or get_supported_countries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns detailed information about a specific beneficiary.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | UUID of the beneficiary |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavioral traits. It only states 'Returns detailed information', but does not mention that the operation is read-only, what happens if the UUID is invalid (e.g., error or null), or any authorization requirements. The minimal description leaves significant uncertainty about 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?
The description is a single sentence, concise and front-loaded. However, it is perhaps too sparse; additional context could be added without harming conciseness. It earns a 4 for efficiency but loses a point for under-specification.
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 (one required parameter, no output schema, no annotations), the description is adequate but incomplete. It doesn't explain what 'detailed information' includes or how to handle errors (e.g., non-existent UUID). A more complete description would list typical response fields or error scenarios.
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 parameter 'uuid' with a clear description. The tool description adds no additional meaning beyond the schema. Since schema description coverage is 100%, a baseline score of 3 is appropriate – the description does not improve parameter understanding but also does not detract.
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 action ('Returns') and resource ('detailed information about a specific beneficiary'). It distinguishes from sibling tools like list_beneficiaries (which returns a list) and create/delete/update. However, it does not explicitly mention that the beneficiary is identified by a UUID, though the schema makes that clear.
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?
No guidance is provided on when to use this tool vs alternatives. For example, it doesn't indicate that this should be used when you have a specific beneficiary's UUID, or that list_beneficiaries is for browsing. The description lacks any usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns holidays for each currency that affect settlement dates.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral information. It states the output is 'holidays for each currency that affect settlement dates', which is clear but lacks details on format, caching, or side effects. This is adequate but not exemplary.
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 of 8 words. It is front-loaded with the verb 'Returns' and contains no unnecessary 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 has no output schema, the description minimally tells what the tool returns but does not hint at the return structure (e.g., fields like currency code, holiday date). This is adequate for a simple tool but could be more helpful.
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 no parameters, so the baseline score is 4. The description does not need to add parameter information, and it correctly omits any.
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 holidays for each currency that affect settlement dates. This distinguishes it from sibling tools like get_supported_currencies or get_currency_pairs, which serve 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?
No explicit guidance on when to use this tool versus alternatives is provided. The purpose implies it should be used before operations sensitive to settlement dates, but no conditions or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns currency pairs the user is allowed to trade and the earliest delivery date for each pair.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions returning data but does not disclose any behavioral traits such as whether it is read-only, requires authentication, or has rate limits. For a tool with no annotations, this is minimal disclosure.
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 focused sentence that conveys the essential information without any fluff. It is front-loaded and 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?
Given no parameters, no output schema, and no annotations, the description adequately explains the tool's primary function. It could be improved by hinting at the output structure or data format, but for a simple list retrieval it is nearly 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?
There are no parameters, so schema coverage is 100% trivially. The description adds value beyond the empty input schema by explaining what the tool returns (currency pairs and earliest delivery date). This compensates for the lack of parameter details.
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 currency pairs the user is allowed to trade, along with the earliest delivery date. It uses a specific verb ('returns') and resource ('currency pairs'), and distinguishes itself from sibling tools like 'get_rsi_currency_pairs' which are RSI-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?
No explicit guidance on when to use this tool versus alternatives. The description implies it is for retrieving allowed currency pairs, but does not specify exclusions or prerequisites. Given the many sibling 'get' tools, some usage context could help, but the purpose is straightforward enough for a basic understanding.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns details of a specific rate alert.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | UUID of the rate alert |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits beyond the basic read operation. It does not mention error handling (e.g., what happens if the UUID is invalid), authentication requirements, or rate limits. Since no annotations are provided, the description carries the full burden.
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, clear sentence with no extraneous words. It is appropriately concise for a simple get operation.
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 is too minimal. It does not explain what 'details' are returned, nor does it provide context about possible error conditions or the expected response format. With no output schema, the agent lacks sufficient information to fully understand the tool's behavior.
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 100% description coverage with a clear description for the 'uuid' parameter. The tool description adds no additional meaning beyond what the schema already provides.
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 action ('Returns details') and the resource ('a specific rate alert'). It distinguishes from sibling tools like list_rate_alerts and create_rate_alert, but does not explicitly differentiate.
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?
No guidance is provided on when to use this tool versus alternatives. For example, it does not note that this tool requires a known UUID, unlike list_rate_alerts which retrieves all alerts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns details of a specific RSI (MOEX) market order.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | UUID of the RSI alert |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. The phrase 'Returns details' implies a read-only operation, which is sufficient. However, it does not disclose any additional behavioral traits such as authentication requirements, rate limits, or side effects. The description is minimal but not contradictory.
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 of 9 words, front-loading the purpose efficiently. No extraneous information is present.
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 no output schema, so the description should provide information about the return value. It simply says 'details' without specifying what fields or structure to expect. This is adequate for a simple retrieval but lacks completeness for an agent to anticipate the response format.
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 100% for the sole parameter 'uuid,' which is described as 'UUID of the RSI alert.' The description adds no further meaning beyond the schema, so the baseline score of 3 is appropriate.
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 'Returns details of a specific RSI (MOEX) market order,' clearly indicating a read operation on a single resource. The verb 'Returns' and the resource 'specific RSI market order' distinguish it from sibling tools like list_rsi_alerts (list multiple) and create/update/delete (mutations).
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 does not explicitly state when to use this tool versus alternatives. However, the context of 'specific' implies it should be used when a UUID is available, contrasting with list_rsi_alerts. No explicit 'when-not' or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns currency pairs the user is allowed to create RSI (MOEX market order) alerts with.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description is minimal and does not disclose any behavioral traits (e.g., cost, rate limits, side effects). As a simple read operation, more context would be helpful.
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?
One concise sentence that clearly conveys the tool's purpose. No fluff.
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 retrieval tool with no parameters and no output schema, the description is adequate. It states what is returned, though format is not specified.
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. Description adds no param info, but none 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?
Description clearly states the verb 'returns' and resource 'currency pairs' with specific context 'user is allowed to create RSI (MOEX market order) alerts with.' This distinguishes it from sibling tools like get_currency_pairs.
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?
No explicit guidance on when to use or when not to use. Implies use for retrieving pairs for RSI alerts, but does not mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns information about supported same-currency transfer options.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states it 'returns information,' which implies a read operation, but it does not explicitly confirm read-only behavior, mention authentication needs, rate limits, or any other behavioral traits.
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 that directly states the tool's purpose without any extraneous words. It is efficiently front-loaded and 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?
Despite the tool's simplicity (0 params, no output schema), the description is vague by using 'information' without specifying the nature of the output (e.g., list, details). Without an output schema, the description could be more informative, such as indicating if it returns a list of options or a single object.
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 no parameters (0 params, 100% coverage), so the description does not need to add parameter detail. The baseline for no-param tools is 4, and the description does not contradict or add unnecessary 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 states the tool returns information about supported same-currency transfer options, which clearly identifies the resource (same-currency transfer options) and action (returns information). It distinguishes from sibling tools like get_supported_currencies or get_beneficiary which deal with different resources.
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?
No guidance is provided on when to use this tool versus alternatives. With many sibling 'get_' tools, the description does not mention any conditions, prerequisites, or exclusions, leaving the agent to infer usage without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns all countries supported by the platform.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must provide behavioral context. It only states that it returns countries, with no mention of filtering, pagination, rate limits, or result format. Minimal transparency beyond the obvious read operation.
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?
Single sentence, no redundancy, immediately states the purpose. Every word 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?
For a simple list with no parameters and no output schema, the description minimally covers what the tool does. However, it could hint at the return format (e.g., country codes) to be more complete. Adequate but not thorough.
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, and schema description coverage is 100%. Baseline score of 3 is appropriate as the description adds no parameter information beyond what the schema provides (which is nothing).
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 verb 'Returns' and the resource 'all countries supported by the platform'. It is specific and unambiguous, but does not differentiate from sibling tools like get_supported_currencies.
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?
No guidance on when to use this tool versus alternatives. Among many sibling tools, no context about use cases or prerequisites is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns all currencies supported by the platform.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It accurately describes the read-only nature and the scope of data returned. For a simple listing tool, this is sufficient transparency.
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 unnecessary words. It is concise and front-loaded with the key action.
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 zero parameters, no output schema, and the tool's simplicity, the description fully covers what the tool does without missing information.
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 100% (no parameters), so baseline is 3. The description adds no extra parameter meaning, which is acceptable as there are no parameters to describe.
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 verb 'Returns' and the resource 'all currencies supported by the platform'. It uniquely identifies the tool's purpose among siblings like get_currency_pairs or get_supported_countries.
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 indicates this tool is for retrieving the full list of supported currencies, but it provides no explicit guidance on when to use it versus alternatives or any preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns detailed information about a specific trade including settlement accounts and documents.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | UUID of the trade |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as read-only nature, authentication requirements, or potential errors. It only states what it returns, not how it behaves.
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?
One sentence of 16 words, front-loaded with the main purpose. No redundant or verbose content.
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 mentions settlement accounts and documents but omits other possible details (e.g., status, dates). Without an output schema, more specifics would help, but for a simple tool it's marginally 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?
Schema coverage is 100% with the single 'uuid' parameter described as 'UUID of the trade'. The description adds no additional semantics beyond the schema, so baseline score 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 clearly states it returns detailed information for a specific trade, including settlement accounts and documents. This distinguishes it from siblings like list_trades (listing) and create_trade (creation).
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 for retrieving details of a specific trade, but does not explicitly state when to use it versus alternatives (e.g., list_trades for all trades). No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns metadata for a specific trade.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | UUID of the trade |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose behavioral traits such as idempotency, side effects, or authentication needs. Only states it returns data, but no further details.
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?
Short one-sentence description, but could be more informative. No wasted words, but lacks sufficient detail.
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; description does not specify what metadata is returned, nor any error conditions or usage context. Incomplete for a tool with one parameter.
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 100% with one parameter 'uuid' already described. Description adds no extra 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?
Description states it returns metadata for a trade, but 'metadata' is vague. Does not differentiate from sibling 'get_trade' which likely returns full trade data.
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?
No guidance on when to use this tool versus alternatives like 'get_trade' or 'get_trade_payment'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns details of a specific payment within a trade.
| Name | Required | Description | Default |
|---|---|---|---|
| trade_uuid | Yes | UUID of the trade | |
| uuid | Yes | UUID of the payment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Returns details' without mentioning that the operation is read-only, whether authentication is required, rate limits, or what happens if the payment is not found (e.g., error response). This is insufficient for a tool with no annotation safety net.
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 immediately states the tool's purpose with no extraneous words. It is optimally front-loaded and all content 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?
Given that there is no output schema, the description does not explain the return format, possible error states, or any other contextual details beyond the basic function. For a simple retrieval tool this is adequate, but lacks completeness for an agent to fully understand behavior without guessing.
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 100%, so baseline is 3. The description does not add any meaning beyond the schema; it only restates that the payment is 'within a trade' which is already implied by the parameter names and descriptions. No additional guidance on parameter formats or constraints is provided.
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 verb 'Returns', resource 'details of a specific payment', and context 'within a trade'. It effectively distinguishes from sibling tools like list_trade_payments (which lists multiple payments) and update_trade_payment (which modifies).
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 for when to use the tool (to retrieve details of a specific payment given its UUID and the trade UUID), but it does not explicitly state when not to use it or mention alternative tools. No exclusions or comparisons are given, which would merit a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns information about the current authenticated trading user, including permissions, activated features, and relationship manager details.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions the tool is for the 'current authenticated trading user', hinting at authentication but not explicitly stating requirements or side effects. Since no annotations are provided, the description should more clearly disclose that authentication is required and that the call is read-only and idempotent.
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 immediately conveys the action and output. No unnecessary words or repetition.
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 no parameters and no output schema, the description is adequate but could be more complete. It lists the categories of returned data but does not specify the structure or format, leaving the agent to guess the exact response shape.
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 zero parameters, so parameter semantics are not a concern. The baseline for 0 parameters 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 precisely states the tool returns information about the current authenticated trading user, listing specific data types (permissions, activated features, RM details). It clearly distinguishes itself from sibling tools, which mostly deal with other entities like beneficiaries or trades.
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?
No explicit guidance on when to use the tool versus alternatives, nor any exclusions or prerequisites. The use case is implied as retrieving current user info, but the description does not mention when not to use it or contrast with other tools like get_beneficiary or get_trade.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initiates a payment from a balance account.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | UUID of the balance account to pay from | |
| beneficiary_uuid | Yes | UUID of the beneficiary to pay | |
| amount | Yes | Amount to pay | |
| reference | No | Payment reference | |
| reason | No | Payment reason |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is minimal and does not disclose important behavioral traits like whether the payment is immediate, requires authorization, or what happens upon success or failure. No annotations are present to compensate.
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 (6 words), but at the cost of being too minimal. It lacks important details, making it less effective than a slightly longer but more informative description.
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 payment initiation tool with 5 parameters and no output schema, the description is incomplete. It does not explain return values, error handling, prerequisites, or how it fits into the broader workflow.
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 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; it does not explain, for example, the currency of 'amount' or the purpose of 'reference.'
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 'Initiates' and identifies the resource 'payment from a balance account.' It clearly conveys the main action, but does not differentiate it from sibling tools like 'create_trade_payment' which might also initiate payments.
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?
No guidance is provided on when to use this tool vs. alternatives such as 'create_trade_payment' or 'list_beneficiary_payments.' The agent has no context to choose between similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns balance information for all accounts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It does not disclose behavioral traits like read-only nature, authentication requirements, or rate limits. Only states basic function.
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?
Single sentence, no wasted words. Efficiently conveys the core 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?
No output schema and no annotations. Description is minimally adequate but does not specify what fields are in the balance information (e.g., currency, amounts). Leaves some ambiguity.
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?
Tool has zero parameters, so schema coverage is 100%. Baseline of 4 is appropriate as no additional parameter info is 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?
Description states 'Returns balance information for all accounts' which is a clear verb+resource. However, it does not differentiate from sibling tools like list_beneficiaries or list_trades, which could also return lists of objects.
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?
No guidance on when to use this tool vs alternatives, or any prerequisites. The description simply states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a paginated list of beneficiaries.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| per_page | No | Results per page (default: 25), or "all" to fetch all | |
| currency | No | Filter by 3-letter currency code | |
| order | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says 'returns a paginated list' without disclosing default behavior, sorting, rate limits, or whether it's read-only. Lacks 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?
Single sentence with no waste, but front-loads the core purpose. Could be expanded without losing conciseness.
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 has 4 parameters and no output schema, the description omits pagination details, filtering, sorting, and defaults. Incomplete for effective use.
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 50% and description adds no meaning to parameters. Does not explain 'page', 'per_page', 'currency', or 'order' fields beyond what schema provides.
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?
Clearly states it returns a paginated list of beneficiaries. Distinguishable from sibling tools like 'get_beneficiary' or 'create_beneficiary'.
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?
No guidance on when to use this tool vs alternatives like 'get_beneficiary' for a single record or other list tools. Does not indicate prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns email requests sent to a beneficiary asking them to provide bank account details.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | UUID of the beneficiary |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the return type but does not mention read-only nature, authentication needs, rate limits, or any side effects.
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?
One sentence of 12 words, no fluff, and the key information is front-loaded. Every word 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?
Lacks output schema and does not describe the structure of returned data (list details, fields included). Also missing error scenarios or pagination info, which are important for a list tool.
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 100% (single parameter 'uuid' with description). The description does not add extra meaning beyond the schema, so baseline 3 is appropriate.
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 email requests sent to a beneficiary for bank account details. It uses a specific verb 'returns' and resource 'email requests', and distinguishes from siblings like create/delete email requests.
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 wanting to view pending email requests for a beneficiary, but provides no explicit when-to-use, when-not-to-use, or prerequisites (e.g., beneficiary must exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a list of payments made to a specific beneficiary.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | UUID of the beneficiary | |
| page | No | ||
| per_page | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states 'returns a list' which implies read-only but lacks details on pagination, sorting, performance, or data freshness. Minimal transparency beyond the tool name.
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?
Single sentence of 9 words, highly concise and front-loaded. However, it may be too minimal for clarity.
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, no annotations, and low param coverage. Description does not explain return format, pagination behavior, or any limitations. Incomplete for a list tool that likely returns paginated results.
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 only 33% (uuid only). Description adds no parameter-level details beyond what schema provides. Page and per_page parameters have no description in either schema or tool 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?
Description clearly states the verb 'returns' and resource 'list of payments' with qualifier 'to a specific beneficiary'. It distinguishes from sibling tools like list_beneficiaries and list_trade_payments by specifying beneficiary focus.
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?
No guidance on when to use or not use this tool versus alternatives. Does not mention pagination constraints or comparison with list_trade_payments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a list of rate alerts (target-rate market orders). Active alerts auto-book a trade when the target rate is reached if book=true.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| per_page | No | ||
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavior. It mentions auto-booking for active alerts, but does not explain pagination behavior, data freshness, rate limits, or whether the operation is read-only.
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: one sentence with two clauses. It is front-loaded with the core purpose and adds a key behavioral detail without extraneous 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?
Given no annotations, no output schema, and three undocumented parameters, the description provides insufficient context. It omits return format, pagination details, and parameter usage, leaving the agent to infer or guess.
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 does not explain any of the three parameters (page, per_page, status), leaving their purpose and acceptable values entirely to the schema. This fails to compensate for the lack of parameter descriptions.
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 a list of rate alerts and defines them as target-rate market orders, with an important behavioral note about auto-booking. This distinguishes it from sibling tools like list_rsi_alerts.
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?
While the description explains what rate alerts are, it offers no guidance on when to use this tool instead of get_rate_alert, create_rate_alert, or other list tools. It does not mention filtering capabilities despite the status parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a list of RSI (MOEX) market orders. These trigger automatically when the RSI indicator reaches the target_rsi threshold.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| per_page | No | ||
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It mentions automatic triggering but lacks info on read-only nature, pagination, authentication requirements, or rate limits. Minimal behavioral disclosure.
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?
Only two sentences, front-loaded with main action. Concise but missing essential parameter descriptions; structure is adequate but not optimized for quick scanning.
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, so description should explain return format or pagination. It does not. The tool has 3 parameters but description is insufficient for an agent to use correctly without additional context.
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%, but description provides zero explanation for any of the three parameters (page, per_page, status). Agent must rely solely on parameter names and enum values.
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 a list of RSI market orders triggered by RSI threshold. It distinguishes from sibling tools like 'get_rsi_alert' (single alert) and 'list_rate_alerts' (different alert type). However, it does not explicitly mention MOEX context or contrast with all siblings.
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?
No guidance on when to use this tool versus alternatives. No prerequisites, exclusions, or when-not-to-use mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a list of payments associated with a trade.
| Name | Required | Description | Default |
|---|---|---|---|
| trade_uuid | Yes | UUID of the trade | |
| page | No | ||
| per_page | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose key behavioral traits: pagination behavior, ordering, whether it's read-only, or any limitations. It only states it returns a list, offering minimal transparency.
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, front-loaded sentence with no wasted words. However, it sacrifices too much detail for brevity.
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 lack of annotations, no output schema, and three parameters (two undocumented), the description is severely incomplete. It does not explain return format, pagination, error handling, or any operational details.
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 low (33%), and the description adds no meaning to the parameters. The 'page' and 'per_page' parameters are completely undocumented in both schema and description, leaving their semantics unclear.
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 verb 'Returns' and the resource 'list of payments associated with a trade', matching the tool name and distinguishing it from sibling tools like list_beneficiary_payments, create_trade_payment, etc.
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?
No guidance is provided on when to use this tool vs alternatives such as get_trade_payment or list_beneficiary_payments. The description lacks context about prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a paginated list of trades.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default: 1) | |
| per_page | No | Results per page (default: 25), or "all" to fetch all | |
| buy_currency | No | Filter by buy currency | |
| sell_currency | No | Filter by sell currency | |
| status | No | ||
| created_at_from | No | Filter trades created on or after this date (YYYY-MM-DD) | |
| created_at_to | No | Filter trades created on or before this date (YYYY-MM-DD) | |
| with_beneficiaries | No | Include beneficiary information in response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'paginated list' without detailing side effects, read-only nature, rate limits, or pagination mechanics. This is insufficient for an agent to understand behavior beyond the basic function.
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 directly conveys the tool's purpose. While minimal, it is not verbose and front-loads key 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?
The tool has 8 parameters with no output schema and no annotations. The description omits details about pagination behavior (e.g., default page size, response format) and does not clarify the structure of the returned list. An agent would lack sufficient context to use the tool effectively without additional assumptions.
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 88%, meaning most parameters are well-described in the schema. The tool description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
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 'Returns a paginated list of trades' clearly states the action (returns) and the resource (list of trades), distinguishing it from siblings like 'get_trade' (single trade) and 'list_trade_payments' (payments).
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 no guidance on when to use this tool versus alternatives such as 'get_trade' for a specific trade or other list operations. No context about filtering or pagination usage is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Refreshes broker quotations for an existing quote after the 15-second validity window has expired.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | UUID of the quote to refresh |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the timing constraint but fails to mention side effects (e.g., whether the quote is modified or a new one created), required permissions, or behavior if called too early. This is a moderate gap.
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 of 12 words, front-loaded with the verb and resource, and contains no redundant information. Every word 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?
Given the tool simplicity (1 parameter, no output schema), the description is adequate but missing expected output or behavior on success/failure. Without an output schema, agents would benefit from knowing what is returned.
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 schema already describes the uuid parameter with 100% coverage. The description does not add further parameter-specific meaning beyond the schema. Baseline 3 is appropriate.
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 action ('Refreshes'), the resource ('broker quotations for an existing quote'), and a specific condition ('after the 15-second validity window has expired'), making it distinct from sibling tools like create_quote or get_same_currency_transfers.
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 when to use (after validity window) but does not explicitly state when not to use (e.g., before expiration) or suggest alternatives. The context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates an existing beneficiary.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | UUID of the beneficiary to update | |
| nickname | No | ||
| No | |||
| line1 | No | ||
| line2 | No | ||
| city | No | ||
| country | No | ||
| state | No | ||
| postal_code | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'updates' implying mutation, but does not mention authorization requirements, partial update behavior, or side effects. The description is insufficient for an AI agent.
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 short (one sentence), which is concise but lacks structure and fails to add value beyond the tool name.
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 complexity (9 parameters, no output schema, no annotations), the description is incomplete. It does not specify which fields are updatable, constraints, or consequences of the update.
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 9 parameters with only 'uuid' described. Schema description coverage is 11%, and the description adds nothing about the semantics of the other parameters. The agent has no help understanding fields like nickname, email, or address components.
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 updates an existing beneficiary, providing a specific verb and resource. However, it does not differentiate from sibling tools like create_beneficiary or delete_beneficiary.
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?
No guidance is given on when to use this tool versus alternatives such as create_beneficiary or verify_beneficiary. The description lacks context for usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates and resends a pending beneficiary email request.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | UUID of the beneficiary | |
| request_uuid | Yes | UUID of the email request to update | |
| No | |||
| currency | No | ||
| bank_account_country | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It says 'updates and resends' but does not disclose whether updates overwrite fields, what happens if the request is not pending, or any side effects like rate limits or authentication requirements. Minimal behavioral context is 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?
The description is a single sentence front-loaded with purpose, but it lacks important details. While concise, the brevity sacrifices clarity on parameters and behavior. It could be more structured without being verbose.
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 has 5 parameters, no output schema, and no annotations, the description is insufficient. It does not explain what fields can be updated, the required state (pending), return values, or error scenarios. The tool context (siblings) is not leveraged to clarify scope.
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 40% (only uuid and request_uuid have descriptions). The tool description adds no parameter-level information, leaving three undocumented parameters (email, currency, bank_account_country) without semantic guidance. It fails to compensate for the schema 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 updates and resends a pending beneficiary email request. The verb 'updates' and noun 'email request' indicate the action and resource. However, it does not explicitly differentiate from sibling tools like create_beneficiary_email_request or delete_beneficiary_email_request, though the purpose is distinct by context.
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?
No explicit guidance on when to use this tool versus alternatives. The description implies it is for updating an existing pending request, but does not specify prerequisites, when-not to use, or mention of other tools like create_beneficiary_email_request for new requests.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates an existing rate alert.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | UUID of the rate alert to update | |
| target_rate | No | ||
| expiration_date | No | ||
| note | No | ||
| book | No | ||
| reason | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden for behavioral disclosure. It only states the action 'Updates' without mentioning side effects, idempotency, permissions, or whether changes trigger notifications.
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 communicates the core purpose. It could be expanded with structure (e.g., bullets) to include parameter details, but is not overly verbose.
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 6 parameters, low schema coverage, and no output schema or annotations, the description is insufficient for an agent to correctly invoke the tool. Missing parameter semantics, usage context, and behavioral info.
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 low (17%), with only UUID described. The description adds no parameter information, failing to clarify what target_rate, expiration_date, etc., mean or their formats.
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 'Updates an existing rate alert' clearly specifies the verb 'updates' and resource 'rate alert', distinguishing it from create/delete siblings implicitly. However, it does not explicitly differentiate from other update or mutation tools.
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?
No guidance on when to use this tool versus alternatives like create_rate_alert or delete_rate_alert. The description does not mention any prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates an existing RSI (MOEX) market order.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | UUID of the RSI alert to update | |
| expiration_date | No | ||
| minimal_rate | No | ||
| book_remaining_amount_on_expiration | No | ||
| beneficiary_uuid | No | ||
| payment_reference | No | ||
| payment_purpose | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states 'Updates' but provides no information about side effects, permissions, error conditions, or what happens to the order. Minimal 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?
The description is a single short sentence, which is concise but lacks necessary detail. It does not earn its place as it omits essential 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 no output schema, no annotations, and low schema coverage, the description is severely incomplete. It fails to explain the tool's behavior, parameters, or return values for a complex 7-parameter tool.
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 only 14% (only uuid has a description). The tool description does not clarify any other parameters like expiration_date or minimal_rate, leaving their meaning to inference. Description adds zero value 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 states it updates an existing RSI (MOEX) market order, clearly specifying the resource and action. However, it does not differentiate from sibling tools like update_rate_alert, which also update alerts, missing a chance to distinguish.
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?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives, nor does it mention prerequisites or restrictions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates an existing payment within a trade.
| Name | Required | Description | Default |
|---|---|---|---|
| trade_uuid | Yes | UUID of the trade | |
| uuid | Yes | UUID of the payment to update | |
| amount | No | ||
| reference | No | ||
| payment_date | No | ||
| payment_type | No | ||
| reason | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only says 'updates' without detailing side effects, idempotency, or required state (e.g., trade must exist). Minimal 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?
Single sentence is concise but too minimal. It conveys purpose but lacks sufficient detail for a 7-parameter tool.
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 7 parameters and no output schema, the description is inadequate. Missing explanations for optional fields and overall behavior.
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 low (29%). Description adds no extra meaning beyond parameter names. 'reason', 'reference', 'amount' lack any semantic guidance.
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 verb 'updates' and the resource 'existing payment within a trade'. It distinguishes from sibling tools like create_trade_payment and delete_trade_payment.
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?
No guidance on when to use this tool versus alternatives (e.g., create_trade_payment). No context about prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Uploads an invoice or proof of settlement document for a trade.
| Name | Required | Description | Default |
|---|---|---|---|
| trade_uuid | Yes | UUID of the trade | |
| category | Yes | Document category | |
| file_name | Yes | File name including extension | |
| content_type | Yes | MIME type (e.g. application/pdf, image/png) | |
| file_base64 | Yes | Base64-encoded file content |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states the basic action ('uploads') without mentioning side effects, permissions, size limits, or validation. The mutation nature is implied but not elaborated.
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 with no waste. It directly conveys the core action and resource without unnecessary elaboration.
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 complexity of a file upload tool with 5 required params and no output schema, the description is too brief. It lacks information on success behavior (e.g., returned document ID), error conditions, or required prior steps (e.g., trade existence).
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 100% description coverage, so baseline is 3. The description adds minimal extra meaning by specifying 'invoice or proof of settlement' for the category, but this is already defined in the enum. No additional semantic value 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 verb 'Uploads' and the specific resource 'invoice or proof of settlement document for a trade'. It distinguishes the tool from siblings like delete_trade_document by focusing on creation.
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 no guidance on when to use this tool versus alternatives (e.g., delete_trade_document). No context on prerequisites or exclusions is given, leaving the agent to infer usage solely from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates beneficiary parameters before creating. Returns any validation errors.
| Name | Required | Description | Default |
|---|---|---|---|
| nickname | No | ||
| type | No | ||
| currency | No | ||
| bank_account_country | No | ||
| first_name | No | ||
| last_name | No | ||
| company_name | No | ||
| iban | No | ||
| bic_swift | No | ||
| account_number | No | ||
| sort_code | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It states it returns validation errors and implies it is non-destructive (validation step), but lacks details on side effects, security requirements, or whether it modifies state.
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?
Single sentence is concise but lacks structure: no front-loading of key information, no separation of purpose from details. Every sentence earns its place but could be structured better.
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 11 parameters, no output schema, and no annotations, the description is inadequate. It does not explain parameter dependencies, required combinations, or validation rules, leaving the agent underinformed for complex inputs.
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%; description provides no explanation for any of the 11 parameters, leaving the agent to infer meaning solely from names and schema. This is a critical gap.
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?
Clearly states it validates beneficiary parameters before creating, distinguishing it from sibling tools like 'create_beneficiary' and 'verify_beneficiary'. Uses specific verb 'validates' and resource 'beneficiary parameters'.
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 says 'before creating', guiding the agent to use this tool prior to creation. However, no explicit when-not-to-use or alternatives among siblings for validation of other resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates rate alert parameters before creating or updating. Returns any validation errors.
| Name | Required | Description | Default |
|---|---|---|---|
| sell_currency | No | ||
| buy_currency | No | ||
| side | No | ||
| amount | No | ||
| target_rate | No | ||
| delivery_date | No | ||
| expiration_date | No | ||
| uuid | No | Pass to validate an existing alert being updated |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it validates and returns errors but does not explicitly confirm that the operation has no side effects (e.g., does not create or update). The behavior regarding checking existing resources (e.g., with uuid) is unclear.
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 only two short sentences, front-loaded with the main action. Every word is essential and there is no wasted text. It effectively communicates the tool's purpose and outcome.
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 complexity (8 parameters, no output schema, no annotations), the description is too brief. It lacks details about the return format, error structure, and whether validation checks against existing data. The agent needs more context to handle responses properly.
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 only 13% (only uuid has a description). The description adds no parameter meaning beyond the generic 'validates parameters.' It does not explain parameters like sell_currency, amount, etc., despite low schema coverage.
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 validates rate alert parameters for creation/updating and returns errors. It distinguishes from sibling create/update tools by indicating it's a pre-check, and from other validation tools by specifying 'rate alert parameters'.
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 says 'before creating or updating,' providing clear context for when to use this tool. However, it does not explicitly exclude alternatives or state when not to use it, but the purpose is sufficient for an AI agent to understand the usage scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates payment parameters before creating a payment for a trade.
| Name | Required | Description | Default |
|---|---|---|---|
| trade_uuid | Yes | UUID of the trade | |
| beneficiary_uuid | Yes | UUID of the beneficiary | |
| amount | Yes | Payment amount | |
| reference | No | ||
| payment_date | No | ||
| payment_type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only says 'validates', which implies a read-only operation, but does not disclose what happens on success/failure, validation rules, or side effects. Minimal behavioral insight.
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, which is concise, but it lacks structure and depth. It sacrifices detail for brevity, making it borderline under-specified.
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 has 6 parameters and no output schema, the description is inadequate. It does not explain the validation process, expected response, or constraints, leaving significant gaps for an agent.
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 50% (3 of 6 parameters have descriptions). The description adds no param-specific information beyond what the schema already provides, failing to compensate for undocumented fields (reference, payment_date, payment_type).
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: validating payment parameters before creating a payment. It uses a specific verb ('validates') and resource ('payment parameters for a trade'), but lacks explicit differentiation from sibling tools like create_trade_payment or validate_beneficiary.
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?
No guidance on when to use this tool vs alternatives. The phrase 'before creating a payment' implies a sequence, but there is no explicit when-not or mention of alternative tools like validate_beneficiary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verifies a beneficiary bank account (e.g. CoP check in the UK).
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | No | UUID of an existing beneficiary to verify | |
| account_number | No | ||
| sort_code | No | ||
| iban | No | ||
| bank_account_country | No | ||
| currency | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only says 'verifies', implying a read operation, but does not mention side effects, what the verification entails (e.g., checks bank account existence, format), or any external calls. Lacks essential behavioral details.
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 short (one sentence), but for a tool with 6 parameters and no other guides, it is too terse. It sacrifices necessary detail for brevity, making it harder for the agent to use correctly.
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 complexity (6 parameters, no output schema, no annotations), the description is far from complete. It lacks information on return values, error conditions, and parameter usage, leaving the agent underinformed.
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 low (17%), and the description adds no meaning to parameters. It does not explain how to use uuid, account_number, sort_code, iban, bank_account_country, or currency. The agent must guess their roles, which is insufficient.
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: verifying a beneficiary bank account, with a specific example (CoP check in the UK). It effectively distinguishes from sibling tools like create_beneficiary and validate_beneficiary.
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?
No usage guidelines are provided. The description does not explain when to use this tool over alternatives, such as when to choose verify_beneficiary versus validate_beneficiary, or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a specific resource-action pair (e.g., create_beneficiary, validate_beneficiary, verify_beneficiary). Even closely related tools are differentiated by their verb, leaving no ambiguity.
All tool names follow the verb_noun pattern in snake_case (e.g., create_quote, refresh_quote, get_trade). The convention is strictly applied across all 51 tools.
With 51 tools, the server offers comprehensive coverage of currency exchange operations, but the large number may overwhelm agents and could be modularized into smaller, focused servers.
The tool surface covers core CRUD for beneficiaries, trades, payments, alerts, and metadata queries. Minor gaps exist (e.g., no delete_trade or update_trade, no list_quotes), but the essential workflow is fully supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Live & historical FX rates and currency conversion for AI agents. No API keys.
Connect AI agents to bank accounts, transactions, balances, and investments.
Cross-border payment & banking intelligence for AI agents: SWIFT/BIC, IBAN, sanctions, FX, tracking.
Connect AI agents to financial institution origination, analytics, and compliance workflows.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/currencytransfer/mcp-currencytransfer'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
