Arzbin MCP Server

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, ensuring the agent knows it's safe and non-destructive. The description adds that it uses 'latest Arzbin indicative market data' and includes a disclaimer 'Not financial advice.' This additional context about data source and advisory nature goes beyond annotations, though no contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: the first states the core function, and the second adds a disclaimer. It is front-loaded and contains no unnecessary words. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (3 required parameters, no nested objects) and the existence of an output schema, the description is largely complete. It covers the data source, estimated nature, and disclaimer. However, it does not mention what happens with invalid asset codes or limits, but such details may be implied by the schema.

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 describes all three parameters (code, amount, assetType) with clear descriptions, achieving 100% schema coverage. The description adds no further semantic meaning beyond what is in the schema. Therefore, per the rubric, a baseline 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 converts fiat, crypto, or gold amounts to an estimated Toman value using market data. The verb 'converts' specifies the action, and the resource (amounts) and target (Toman) are explicit. Sibling tools like get_latest_fiat_rates provide rates, not conversion, distinguishing this tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool is for conversion when you have an amount and need Toman value, while siblings are for rate lookups. However, it lacks explicit when-to-use and when-not-to-use guidance, such as mentioning that for direct rates without conversion, one should use the siblings.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds the condition 'where available', indicating not all currency codes may have data, which provides some behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear 12-word sentence with no redundant information. It is front-loaded and efficient, earning its place without waste.

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, output schema present, rich annotations), the description is sufficient. It explains the core functionality, and the output schema covers return details, so no further elaboration is 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_description_coverage is 100%, so the schema already fully documents the parameter. The description does not add any additional meaning beyond what the input schema provides, meeting the baseline.

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 Arzbin source comparison data for a fiat currency code, using a specific verb and resource. It distinguishes itself from sibling tools like get_latest_fiat_rates, which return rates, not source comparisons.

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 suggesting get_latest_fiat_rates for general rates. It only states the tool's function without context or exclusions.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds that data is indicative and not financial advice, but does not disclose additional traits like recency or rate limits. The added caveat is useful but limited.

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 purpose with no unnecessary words. Every sentence adds value: the first states the action and output, the second adds a caveat.

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 a simple input schema, comprehensive annotations, and an output schema present, the description covers the essential aspects. It could mention case sensitivity or data freshness but is largely complete for this 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% and the schema description of the 'symbols' parameter is clear. The tool description does not add significant meaning beyond what the schema provides, 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 the verb 'Returns' and the resource 'latest curated Arzbin crypto prices in Toman and USD', which distinguishes it from siblings like get_latest_fiat_rates and get_latest_gold_rates. It also specifies the currency scope.

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 current crypto rates and notes the option to omit symbols for all rates, but lacks explicit guidance on when not to use this tool or comparisons to siblings like get_market_history.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety traits. The description adds the valuable disclaimer 'Data is indicative market data, not financial advice', which provides quality context. However, no additional behavioral details (e.g., rate limits, caching, typical update frequency) are given.

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: one for core purpose, one for disclaimer. Zero waste, front-loaded information, and each sentence serves a distinct role. Highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (1 optional parameter, output schema exists), the description is adequate. It specifies the currency (Toman) and data quality. No need to explain return values due to output schema. Minor improvement could be mentioning that omitting codes returns all fiat rates, but that is already in schema description.

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 parameter 'codes' is fully documented in the schema. The tool description does not add any parameter-specific information beyond what the schema provides. 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?

Description clearly states 'Returns latest Arzbin fiat currency rates in Toman', specifying the verb (returns), resource (fiat rates), and unique scope (in Toman). This distinguishes it from siblings like get_latest_crypto_rates and get_latest_gold_rates.

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 use for fetching latest fiat rates, but does not explicitly compare with siblings or mention when not to use it. For example, it does not contrast with convert_to_toman (for conversions) or get_fiat_rate_sources (for source metadata). Usage is clear but guidance is implicit.

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

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

Annotations already declare readOnlyHint and idempotentHint, indicating safety. The description adds that data is 'indicative market data, not financial advice,' which provides useful behavioral context about data quality.

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 concise sentences, front-loaded with the core purpose, and no unnecessary words. The disclaimer is placed after the main function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple input (optional array), existing output schema, and annotations covering safety, the description provides sufficient context. It explains the data source, currency, and cautionary note.

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%, and the schema already describes the 'types' parameter well. The tool description does not add extra meaning beyond the schema, so baseline of 3 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 'Returns latest Arzbin gold and coin rates in Toman,' specifying the verb, resource, and currency. The name and sibling tool list (e.g., get_latest_crypto_rates, get_latest_fiat_rates) help distinguish it from other rate 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?

The description implies usage for gold and coin rates, and the sibling tools provide context for when to use alternatives. However, there is no explicit guidance on when not to use this tool or prerequisites.

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

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

Annotations already provide readOnlyHint, idempotentHint, destructiveHint (false). The description adds the constraint that days are clamped to 1-365, which is useful. However, it does not disclose further behavioral traits like data ordering or return format. For a read-only tool with annotations, this is sufficient but not rich.

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 sentences states purpose, second adds a key constraint. No redundant words, information 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 presence of an output schema (not shown but noted), the description adequately covers the input purpose and a key constraint. It could optionally clarify if the OHLC data is daily or intraday, but this is a minor gap. Overall, it provides enough context for an agent to understand its 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?

The input schema has 100% description coverage, so each parameter is already documented well. The description does not add new semantic meaning beyond what the schema provides, achieving the baseline.

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 ('OHLC history'), and scope ('for a fiat, gold, or crypto market'). It distinguishes itself from sibling tools which focus on latest rates or conversions, making the purpose 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 explicit guidance on when to use or when not to use. The description implies usage when historical OHLC data is needed, but does not mention alternatives or exclusions. This is adequate but not exemplary.

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