ramzinex-mcp

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

Discloses the endpoint called, auth requirements (none), response format (reachable, pairs_count? or error), and default instance behavior. No hidden side effects mentioned, but as a health check, read-only is clear.

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?

Well-structured with clear purpose, endpoint, and parameter details. The Persian section is slightly redundant but not overly verbose. Front-loads key info.

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 optional param, output schema available), the description is complete enough for an agent to use correctly. Error handling is briefly noted.

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 explains the 'instance' parameter beyond the schema, including default and token requirement. Since schema coverage is 0%, this adds necessary context.

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 checks Ramzinex reachability via a lightweight public endpoint, specifying the exact API path and that no auth is needed. It distinguishes itself from siblings focused on trading or auth.

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?

Implies usage for connectivity checks without auth, but does not explicitly contrast with sibling tools or advise when to prefer this over others. No exclusion criteria given.

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?

Given no annotations, the description effectively discloses that credential values are never returned, only booleans indicating configuration, and specifies the return structure, though it could mention read-only nature explicitly.

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 with the main action and purpose. The inclusion of a Persian phrase may not be essential for an English agent, but it does not detract significantly.

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 covers the tool's function, purpose, and return format well. It does not mention edge cases or error states, but given the simplicity (no parameters), it is fairly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parameters, the baseline is 4. The description does not need to add parameter info, and it appropriately 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 lists configured Ramzinex instances without secrets, and explains its purpose in discovering accepted instance values and their capabilities, distinguishing it from related 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 provides good guidance on when to use the tool (to discover instance values) and clarifies it does not return secrets, but does not explicitly mention when not to use it or contrast with specific sibling tools.

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

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

With no annotations, the description fully discloses behavioral traits: it is a wallet-write action, can fail with 'withdrawals_disabled' error, and is a best-effort implementation with an assumed endpoint. This provides crucial transparency beyond the basic action.

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 front-loaded with action and warning, then prerequisites and implementation notes. It is a bit lengthy with technical endpoint details, but every section adds value. No wasted sentences.

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 3 parameters (1 required) and an output schema, the description covers purpose, prerequisites, error conditions, parameter semantics, and implementation caveats. It is complete enough for an AI agent to use effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description adds rich meaning: network_id must be >0 and discoverable via sibling tool, currency_id is optional numeric, instance is optional. This compensates fully for the schema 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?

The description clearly states the action ('Allocate/generate a deposit address') and the resource ('the wallet'), and provides a Persian purpose. It distinguishes this tool from siblings like ramzinex_get_addresses (read-only) and ramzinex_submit_withdraw (withdrawal).

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

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

The description explicitly lists prerequisites (credentials, enable_withdrawals=true, read_only=false) and warns of error if not met. It implies caution but does not explicitly state when not to use or suggest alternatives. However, the context is clear enough.

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?

With no annotations, description fully discloses behavior: caches token in memory, never returns token, uses POST endpoint, returns success/error structure. Does not mention side effects beyond caching, but adequate for non-destructive auth.

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?

Structure is clear: English summary, Persian purpose, then details, Args, Returns. Front-loaded main purpose. Persian adds length but may aid multilingual agents. Overall concise.

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 single optional parameter and output schema mentioned in description, the description covers return shape and caching behavior. Lacks error detail but sufficient for simple auth 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 0%, so description adds value by explaining 'instance' parameter and default. However, lacks cross-reference to list_instances or details on valid instance 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?

Description clearly states 'Authenticate an instance and cache its bearer token' with specific verb and resource. Includes Persian purpose for clarity. Sibling tools are all functional operations, making this the only authentication tool, so no confusion.

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?

Implies usage before private calls but does not explicitly state 'call this first' or provide alternatives. Describes two authentication methods (api_key vs api_token) but no exclusions or 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.

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 explicitly warns that the tool changes account state and details the error behavior when trading is disabled. This adequately discloses behavioral traits beyond mere functionality.

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 well-structured, with a clear purpose, warning, Persian note, requirements, endpoint mapping, and parameter documentation. Every sentence adds value without redundancy.

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

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

Given the tool's simplicity, the description covers purpose, parameters, prerequisites, error cases, and endpoint mapping. An output schema exists, so return values are not needed. The description is complete and 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?

Schema description coverage is 0%, but the description explains both parameters: order_id is a numeric id and instance is optional with a default. This adds necessary meaning beyond the raw 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 'Cancel' and the resource 'one of my open orders'. It distinguishes from sibling tools like ramzinex_place_limit_order and ramzinex_get_orders by being the cancel 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?

The description specifies prerequisites: a configured API token and enable_trading=true. It warns when the tool will return an error without contacting the API. However, it does not explicitly state when not to use or provide alternative tools.

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

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

No annotations are provided, so the description carries full burden. It warns that the action moves real funds and is irreversible. It also describes the error condition when withdrawals are disabled, providing clear 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 well-structured with a warning, Persian purpose, prerequisites, API mapping, and parameter list. It is slightly verbose but efficient, with no redundant sentences.

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 no annotations and zero schema coverage for parameters, the description provides thorough context: purpose, prerequisites, behavior, parameter details, and the irreversible nature. An output schema exists, so return values need no explanation.

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?

All four parameters are described in detail in the description, including expected content (non-empty for codes, numeric for withdraw_id) and source (from ramzinex_submit_withdraw). The schema has no descriptions (coverage 0%), so the description adds full semantic value.

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 confirms a pending withdrawal with 2FA codes, explicitly warning that it moves real funds and finalizes an irreversible action. It distinguishes from sibling tools like ramzinex_submit_withdraw by mentioning the pending state.

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

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

It explicitly lists prerequisites: configured credentials, enable_withdrawals=true, and read_only=false. It describes error behavior when conditions are not met. However, it does not mention when to avoid using the tool or alternative approaches.

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

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

The description notes that no network call is made and provides a link to external docs, but does not disclose other potential behaviors like authentication requirements or rate limits. Given no annotations, this is adequate but minimal.

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

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

The description is well-structured with a clear purpose, usage guidance, and parameter/return details, though the Persian line adds slight redundancy for an English-speaking agent.

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, the description adequately covers the return value and parameter behavior, providing sufficient context for a documentation 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?

With 0% schema coverage, the description fully explains the single parameter 'topic', including its effect when provided versus omitted, which adds substantial 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 explicitly states it returns offline documentation about Ramzinex and the server's tools, distinguishing it clearly from the sibling tools which are actual API operations.

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

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

It explains when to use the tool (to learn about tools without network calls) and describes the behavior of the optional topic parameter. However, it does not explicitly state when not to use it or name specific alternatives.

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?

No annotations are provided, so the description carries the full burden. It warns that the tool changes 'security-sensitive access settings' and provides the HTTP mapping. It also describes the error response for disabled account control. However, it does not mention whether the change is reversible, immediate, or has side effects beyond the warning. Moderate 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 roughly 6 sentences, front-loaded with purpose and a warning. It follows a logical order: purpose, prerequisite, HTTP mapping, argument details. Every sentence adds value, though the Persian translation is slightly redundant. It could be slightly trimmed but is well-structured.

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 security-sensitive mutation tool with no annotations and an existing output schema (not described), the description covers the key aspects: purpose, prerequisites, error behavior, parameter meanings, and endpoint. It does not explain the return value (acceptable since output schema exists) or immediate effects of changes. Overall, it provides enough context for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate fully. Each parameter is explained clearly: address_free (0/1, controls withdrawals to non-whitelisted addresses), alert (0/1, enables access-change alerts), and instance (default when omitted). This adds significant meaning beyond the schema's type-only definitions.

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 'account-wide API-key general access', using a specific verb and resource. The warning 'account control' and Persian purpose further clarify the scope. It distinguishes from siblings by naming the similar 'ramzinex_edit_private_access' in the sibling list, and the description's focus on 'general access' implies a counterpart for private access.

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

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

Explicit prerequisites are given: requires configured credentials, account_control=true, and read_only=false. It describes the error returned if account_control is disabled, helping the agent decide when to use. However, it does not directly compare to ramzinex_edit_private_access, though the naming implies a distinction.

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?

With no annotations provided, the description fully discloses behavioral traits: the tool is a mutation (changes permissions), requires specific instance configuration, and returns a specific error without contacting the API if conditions are unmet. It also maps to an HTTP endpoint.

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

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

The description is well-organized with a warning, Persian purpose, prerequisites, HTTP mapping, and parameter list. It is slightly verbose (e.g., repeating the endpoint details) but each section adds value and there is 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?

Given the tool's complexity (8 parameters, security implications, output schema exists), the description covers prerequisites, parameter explanations, and behavior. The output schema handles return values, so the description is complete for safe invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description compensates by explaining each parameter's meaning (e.g., 'withdraw: 0 or 1 — allow withdrawals'). It also clarifies the relationship between ip_free and ips. All 8 parameters are covered with clear semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool updates per-key API access permissions, with a specific verb ('edit private access') and resource ('API key'). It implicitly distinguishes from the sibling 'ramzinex_edit_general_access' by focusing on private access.

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

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

The description explicitly states prerequisites (configured credentials, account_control=true, read_only=false) and the error response when conditions are not met. It does not directly compare to alternatives, but the sibling tool names ('edit_general_access' vs 'edit_private_access') provide context.

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?

No annotations are provided, so the description bears full responsibility. It states the tool is read-only, which is a key behavioral trait. However, it does not detail error handling or edge cases, leaving some behavioral aspects uncovered.

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 includes a Persian language note and API endpoint mapping, which may be extraneous. While fairly concise, some content could be trimmed without losing 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?

With an output schema present, the description does not need to detail return values. It covers purpose, parameters, prerequisites, and hints for related tools, providing sufficient context for effective usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description compensates by explaining the 'networks' parameter as a non-empty list and directing to ramzinex_get_networks for discovery. It also clarifies the 'instance' parameter's default behavior, adding 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 'Get my wallet addresses for the given networks (read-only)', specifying the verb (get), resource (wallet addresses), and scope (for given networks). This distinguishes it from sibling tools like ramzinex_get_networks or ramzinex_get_available_balance.

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 mentions required credentials and suggests discovering networks via ramzinex_get_networks. It implicitly indicates usage for querying addresses but does not explicitly exclude scenarios or provide alternatives.

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?

No annotations are provided, so the description carries the burden. It discloses that the tool is public, requires no auth, and maps to a GET endpoint—indicating a safe read operation. However, it does not discuss potential large response sizes, rate limits, or pagination, which are relevant for an all-pairs endpoint.

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: two sentences plus an Args line. No redundant information. Every sentence adds value—purpose, authentication, endpoint mapping, and parameter explanation.

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 simple (one optional parameter) and has an output schema, the description covers the essential purpose and parameter. However, it lacks usage context such as when to prefer this over sibling orderbook tools, and it does not mention typical response size or behavior for large datasets.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description explains the sole parameter 'instance' as 'Configured instance whose public base URL to use (default when omitted).' This adds meaning beyond the schema's type definition, but does not enumerate valid instance values or how they are configured.

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 'Get the orderbooks for all pairs at once.' This specifies a precise verb and resource, and distinguishes it from sibling tools like ramzinex_get_orderbook, which is for a single pair.

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 via 'all pairs at once' and mentions 'Public, no auth,' but does not explicitly contrast with alternatives like ramzinex_get_orderbook, ramzinex_get_orderbook_buys, or ramzinex_get_orderbook_sells. Guidance is implied rather than explicit.

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

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

The description explicitly states this is a read-only operation and maps to a GET endpoint. It mentions authentication requirements. However, no annotations are provided, and the description does not cover error handling, rate limits, or what happens with invalid currency IDs.

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 generally concise, with a clear first sentence and a useful mapping to the API endpoint. The inclusion of a Persian sentence may be extraneous for an English-speaking agent but does not significantly detract from 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 tool's simplicity (single currency balance retrieval) and the presence of an output schema, the description covers the essential aspects: read-only nature, authentication, parameters, and endpoint mapping. It is sufficiently complete for an AI agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description must compensate. It explains that currency_id is a numeric id and that instance is an optional configured instance. This adds basic meaning beyond the schema, but does not provide extensive detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool retrieves the available (free) balance for a specific currency. It includes a Persian translation and maps to the API endpoint. However, it does not explicitly differentiate from sibling tools like ramzinex_get_total_balance or ramzinex_get_balance_summary.

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 mentions that credentials are required and that an optional instance parameter can be used. It implies that this tool is for checking free balance per currency, but it does not provide explicit guidance on when to use this tool versus other balance-related tools.

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

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

No annotations provided, so description carries full burden. It states 'read-only' and requires credentials, but no other behavioral traits like data freshness, caching, or rate limits are disclosed.

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 and front-loaded with purpose, but includes a Persian translation and API endpoint that add minor overhead. Overall 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?

Output schema exists, so return values need not be explained. However, the description doesn't clarify what the summary includes relative to other balance tools, leaving some ambiguity for a simple 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 0%, but the description adds meaning for the single parameter 'instance' by noting it as a configured instance with a default. This is adequate but could be more detailed.

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 'Get the account balance summary (read-only)' with a specific verb and resource. It distinguishes itself from siblings like get_total_balance or get_available_balance by being a 'summary', but does not explicitly differentiate its 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?

No guidance on when to use this tool vs. alternatives such as ramzinex_get_total_balance or ramzinex_get_funds. It mentions requiring credentials but no context on when it is appropriate.

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?

No annotations are provided, so the description carries the full burden. It correctly states 'read-only' but lacks details on error handling, rate limits, or data freshness. The credentials requirement is noted, but overall behavioral context is minimal.

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 verbose with technical notes about the Postman collection, URL assumption, and Persian text. This extraneous information reduces clarity and efficiency for an AI agent.

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?

An output schema exists, so return values are covered. The description adequately explains the tool's purpose and the single parameter. However, the 'best-effort' caveat introduces uncertainty, and no guidance on when to use relative to sibling tools is 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?

With only one parameter (instance) and 0% schema coverage, the description adds value by explaining 'Configured instance to use (default when omitted)'. This compensates well for the lack of schema documentation.

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 'List commission / fee history (read-only)' which specifies the verb and resource. The Persian translation reinforces the purpose. Among siblings like ramzinex_get_rewards and ramzinex_get_turnover, this tool is distinctly about commissions/fees.

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 mentions 'Requires configured credentials' but does not specify when to use this tool over alternatives like ramzinex_get_rewards. The 'BEST-EFFORT PATH' note implies uncertainty, which undermines clear guidance.

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

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

No annotations are provided, so the description must cover behavioral traits. It states the operation is read-only (via GET) and requires no authentication. This is basic transparency but does not disclose details like data volume, rate limits, 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 short (2 sentences plus Args line) and front-loaded with the main purpose. The Persian line is slightly extraneous for an English AI agent, but overall 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 parameter, no required params, output schema exists), the description covers the purpose, endpoint, auth, and parameter. It does not describe the return value, but the output schema handles that. Completeness is adequate for the complexity.

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 has 0% description coverage, so the description must compensate. It explains the 'instance' parameter as 'Configured instance whose public base URL to use (default when omitted)', adding meaningful context beyond the schema's type and default.

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 'List the currencies supported by Ramzinex', providing a specific verb and resource. It distinguishes from sibling tools like ramzinex_get_pairs or ramzinex_get_networks by focusing on currencies generally. The inclusion of the API path adds clarity.

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 mentions 'Public, no auth', indicating when to use the tool (no authentication needed). However, it does not provide explicit guidance on when not to use it or compare to alternatives. Usage context is implied but lacks 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?

No annotations provided, so description carries full burden. States read-only and pagination, but lacks details on authentication failures, rate limits, or error handling. Output schema exists but not described.

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?

Concise overall, but includes a Persian line and API mapping that add minor verbosity. Structure is clear: summary, args. Efficient but could trim non-essential elements.

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

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

Given 4 params, 1 required, no annotations, and presence of output schema, description covers purpose, parameters, pagination, and read-only. Missing error handling details but sufficient 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?

With 0% schema coverage, description fully explains all 4 parameters: currency_id (numeric id), limit (max, range, default), offset (skip, default), instance (configured instance). Adds meaningful context beyond 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?

Clearly states it lists deposits for one currency with pagination and read-only. Distinguishes from siblings like ramzinex_get_deposits (all currencies) and ramzinex_get_deposit (single deposit).

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?

Declares read-only nature and required credentials. No explicit when-not or alternatives, but the currency-specific purpose is clear. Minor gap: not mentioning that for all currencies use get_deposits.

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?

No annotations are provided, so the description bears full responsibility. It identifies the tool as read-only and requires configured credentials, and maps to an HTTP GET. However, it lacks additional behavioral details such as error handling, rate limits, or data freshness.

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 short (4 sentences plus bulleted args) and front-loaded with the core purpose. The Persian line adds little for an English-speaking AI but does not detract significantly. The structure is clear and scannable.

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 read operation with an output schema, the description covers purpose, authorization, endpoint, and parameter details. It ties currency_id to another tool. Minor omissions exist (e.g., error cases), but overall it provides sufficient context for correct invocation.

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 the description's 'Args' section adds crucial meaning: currency_id is a numeric id from ramzinex_get_currencies, and instance is optional with a default. This goes beyond the schema's type-only information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool gets balance details for one currency and is read-only. It uses a specific verb and resource, and the 'one currency' distinction differentiates it from sibling tools like ramzinex_get_funds.

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 mentions that credentials are required and that the currency_id comes from ramzinex_get_currencies, providing a prerequisite. However, it does not explicitly contrast with alternatives like ramzinex_get_funds or ramzinex_get_available_balance, leaving the agent to infer when to use this specific tool.

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

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

No annotations provided, so description carries full burden. It correctly notes 'read-only' and the API endpoint. However, it does not describe the return format or confirm that no side effects occur beyond basic 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?

The description is relatively concise (5 lines) and front-loaded with purpose. The inclusion of Persian text adds redundancy for English-only agents, slightly reducing conciseness. Overall good structure.

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 2 parameters (1 required), 0% schema coverage, and an output schema present, the description covers both parameters adequately, notes read-only and credentials. It is complete for a low-complexity 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 0%, but the description adds meaning by explaining currency_id as 'Numeric id of the currency' and instance as 'Configured instance to use (default when omitted)', which enhances schema semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List my withdrawals for one currency (read-only)', specifying verb (List), resource (withdrawals), and scope (one currency). This distinctly separates it from siblings like ramzinex_get_withdraws (all currencies) and ramzinex_get_withdraw (single withdrawal).

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 mentions 'Requires configured credentials' but does not explicitly state when to use this tool over alternatives or provide exclusions. The context of listing a single currency is implied but not contrasted directly with 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?

With no annotations provided, the description clearly states the tool is read-only and maps to a GET endpoint, indicating no side effects. It also notes that the instance parameter defaults when omitted. However, it does not disclose error handling or return format details, though an output schema exists.

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 relatively concise, with a clear purpose, Persian translation, API endpoint, and parameter list. It is well-structured but includes a possibly redundant Persian line that may not be needed for English readers.

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

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

Given the tool's simplicity (2 parameters, output schema exists), the description covers input semantics and read-only nature. It could mention that the deposit must exist or that it returns a single deposit object, but the output schema likely covers return structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description provides clear explanations for both parameters: 'Numeric id of the deposit to fetch' for deposit_id and 'Configured instance to use (default when omitted)' for instance. This adds significant meaning beyond the minimal titles in 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 'Get one deposit by id (read-only)', specifying the verb, resource, and scope. It distinguishes from sibling tools like ramzinex_get_deposits which likely list deposits, and the id parameter clarifies the single-item retrieval.

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 mentions 'Requires configured credentials' as a prerequisite, but does not provide explicit guidance on when to use this tool versus siblings such as ramzinex_get_deposits or ramzinex_get_currency_deposits. The context is implied but lacks direct comparisons.

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?

No annotations are provided, so the description carries full burden. It discloses read-only nature, pagination, credential requirement, and API endpoint. However, it does not mention potential errors, rate limits, or any side effects, which is acceptable for a simple 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?

The description is well-structured with a clear purpose, a Persian translation, API mapping, and parameter docs. It is efficient and front-loaded, though slightly longer than necessary.

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 existence of an output schema, the description adequately explains the input parameters and basic behavior. It does not cover filtering or sorting, but for a paginated list tool, it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description adds clear meaning for all three parameters: limit (with range and default), offset (default), and instance (default behavior). This compensates for the schema's lack of 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 'List my deposits, paginated (read-only)' and includes a Persian purpose and API endpoint mapping. However, it does not differentiate from similar sibling tools like ramzinex_get_currency_deposits or ramzinex_get_deposit, so it loses one point.

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 mentions it is read-only and requires credentials, and hints at pagination usage via limit/offset. But it does not explicitly state when to use this tool versus other deposit-related tools or provide exclusion criteria.

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?

No annotations are provided, so the description carries the full burden. It clearly states 'read-only' and 'Requires configured credentials,' and maps to a specific API endpoint. This informs the agent that the tool performs a safe, authenticated query with no side effects. However, it does not detail rate limits or response format, but for a simple balance retrieval this is adequate.

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, including the core purpose, a note on credentials, the API endpoint, and parameter documentation. The Persian phrase adds minor redundancy but does not harm clarity. Overall, it is efficiently structured and front-loaded with the most important 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 an output schema (not shown), so return values are presumably documented there. The description covers the purpose, parameter, and authentication requirement. It is complete enough for a read-only balance tool, though it could mention that it returns data for all currencies in one call.

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 schema description coverage at 0%, the description adds value by explaining that the 'instance' parameter is a configured instance and that omitting it uses the default. This clarifies the parameter's purpose beyond the schema type definition. The single parameter is well covered.

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 ('Get'), the resource ('full balance details'), and the scope ('for all currencies'). It also explicitly marks the tool as read-only, which distinguishes it from siblings like ramzinex_get_available_balance or ramzinex_get_balance_summary that likely provide more limited views.

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 mentions that configured credentials are required but does not compare this tool to its many siblings (e.g., when to use get_funds vs get_available_balance). The usage context is only implied: when full balance details are needed. No explicit when-not-to-use or alternative recommendations are given.

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?

With no annotations provided, the description carries the full burden. It explicitly states the tool is 'read-only' and maps to a GET endpoint, which is a key behavioral trait. It also notes that configured credentials are required. However, it does not disclose potential error conditions or rate limits, though for a simple read-only balance check, these may be less critical.

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 compact and front-loaded with the core purpose. The structure includes a brief main line, a Persian translation, and a clear 'Args' section. The Persian line adds minor noise but does not significantly detract. Overall, every sentence serves a purpose, though the Persian might be unnecessary for the AI.

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 is simple (get locked balance for one currency), and an output schema exists, so the description does not need to explain return values. However, it lacks references to sibling tools or when to use this over others. It covers the basics (params, credential requirement, read-only) but could be more complete by noting differences from available balance or total balance tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains that 'currency_id' is a 'Numeric id' and 'instance' is a 'Configured instance to use (default when omitted).' This adds basic meaning beyond the schema types but lacks details such as how to obtain these values or format constraints. The description provides adequate but not thorough parameter 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?

The description clearly states 'Get the in-orders (locked) balance for one currency (read-only).' The verb 'Get' and resource 'in-orders (locked) balance' are specific, and the read-only annotation distinguishes it from mutating tools. Among siblings like ramzinex_get_available_balance, this one is uniquely identified by 'locked balance', so differentiation is 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?

The description lacks explicit guidance on when to use this tool versus alternatives like ramzinex_get_available_balance or ramzinex_get_total_balance. It mentions it requires credentials but does not specify when not to use it or compare with other balance tools. The Persian translation does not aid in usage decisions.

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?

No annotations are provided, so the description must disclose behavior. It states it's public, no auth, and maps to a GET endpoint, implying read-only. However, it lacks details on rate limits, error handling, or any side effects. Given the absence of annotations, a score of 3 is adequate as basic behavior is covered.

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

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

The description is well-structured with a clear purpose statement, Persian translation, API mapping, and an Args section. It front-loads the main purpose. While slightly verbose due to the API endpoint details, it remains focused and earns its length.

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 an output schema is present, return values are covered elsewhere. The description covers purpose, parameters, and public access. It lacks error conditions or prerequisites, but for a simple price estimation tool, it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description provides detailed explanations for each parameter: 'pair_id' is numeric id, 'amount2' is amount in quote currency (e.g., IRR/Toman) and must be >0, 'instance' is a configured instance. This adds significant meaning beyond the schema's types and titles.

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 estimates the price to BUY for a given quote amount, specifying the verb 'estimate', resource 'market buy price', and the query parameter. It distinguishes from its sibling 'ramzinex_get_market_sell_price' which does the opposite, so the tool's purpose is well-defined and differentiated.

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 mentions 'Public, no auth' and maps to a GET endpoint, indicating it's a read operation open to all. It implies use when you need a buy price estimate, but does not explicitly state when not to use it or alternatives. The sibling existence provides context, but explicit guidance is lacking.

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

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

Describes as estimation and public, no auth. Adds endpoint mapping but does not clarify that no order is placed or any potential limits. Adequate but could be more explicit.

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?

Well-structured with main line, Persian purpose, endpoint, and parameter details. Slightly redundant Persian purpose adds length but not harmful.

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?

Covers purpose, endpoint, parameters. Lacks explanation of output (but output schema exists) and precision of estimate. Mostly complete for a read-only 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?

With 0% schema coverage, the description fully explains all three parameters (pair_id, amount with constraint, instance default), adding essential meaning beyond schema titles.

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 estimates the price to SELL for a given base amount, with explicit verb+resource and distinguishes from sibling ramzinex_get_market_buy_price.

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?

Implies usage for selling but lacks explicit guidance on when to use vs alternatives (e.g., buy price) or exclusions. Mentions 'Public, no auth' but no when-not context.

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?

With no annotations, the description carries the full burden. It discloses that the tool is public and no auth is needed, which is helpful for safe usage. However, it does not mention potential rate limits, data freshness, or any other behavioral traits beyond the basic GET request. The return behavior is partially implied by the parameter descriptions but not explicitly stated.

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

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

The description is well-structured: English purpose, Persian translation, API mapping, and an argument list. Each sentence is informative and contributes value. It is slightly longer than necessary but remains efficient. The front-loading of the main purpose is good.

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 an output schema exists (though not shown), the description need not detail return values. It adequately covers the tool's purpose, parameters, authentication status, and API mapping. However, it lacks mention of potential pagination or response structure, but this is acceptable since the output schema can provide that. Overall, it is sufficiently complete for selection and invocation.

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 has 0% description coverage, yet the description provides detailed explanations for all four parameters: currency_id (restrict to one currency), withdraw (filter by withdrawal support), deposit (filter by deposit support), and instance (configured instance URL). This fully compensates for the missing schema descriptions and adds significant value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists deposit/withdraw networks with optional filtering. It distinguishes from sibling tools like ramzinex_get_currencies (currencies) and ramzinex_get_pairs (trading pairs) by specifying 'networks'. The mapping to the API endpoint and Persian purpose add further clarity.

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 explains the filtering parameters and notes that the tool is public with no authentication required. While it does not explicitly state when to use this vs alternatives, the context is clear given the tool name and sibling tools. No exclusive usage guidance is provided, but the information is sufficient for an agent to decide.

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?

With no annotations provided, the description bears full burden. It declares the operation as read-only and notes the need for a configured API token, offering a clear safety profile. However, it lacks details on error responses or potential side effects, which are minimal for a 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?

The description is concise with four sentences covering purpose, authentication, endpoint mapping, and parameter details. The inclusion of a Persian purpose line is slightly redundant but does not detract from overall 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 (fetch one order by id with two parameters), the description adequately covers purpose, parameters, authentication, and endpoint. The presence of an output schema reduces the need to describe return values.

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 0% description coverage, but the description compensates fully by explaining each parameter: 'order_id' as numeric id of the order, and 'instance' as the configured instance with default behavior. This adds significant value beyond the schema's type and title fields.

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 'Get one of my orders by id (read-only)', specifying the action, resource, and read-only nature. This distinguishes it from sibling tools like 'ramzinex_get_orders' which retrieves multiple orders.

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 mentions the API endpoint and requirement for an API token, implying authentication context. It does not explicitly state when to use versus alternatives, but the specificity of 'by id' provides implicit guidance.

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

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

No annotations exist, so the description bears the burden. It states the operation is public and requires no auth, implying a read-only, non-destructive behavior. However, it doesn't disclose error handling, data freshness, or any limits, which would strengthen 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 extremely concise: a one-line purpose, Persian translation, endpoint mapping, and parameter list. Every sentence adds value with no fluff. Well-structured.

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), the description need not detail return values. It covers the core purpose, parameters, and public nature. It could mention that both buy and sell sides are returned, but the name already implies that. Overall, sufficiently complete for its 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?

Input schema had 0% description coverage, but the description adds clear meaning for both parameters: pair_id is 'Numeric id of the pair' and instance is 'Configured instance whose public base URL to use'. This compensates well for the schema 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?

The description clearly states the tool fetches the buy/sell orderbook for a single pair. It differentiates from sibling tools like ramzinex_get_orderbook_buys, ramzinex_get_orderbook_sells, and ramzinex_get_all_orderbooks by specifying 'single pair' and including both sides.

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 notes 'Public, no auth' and provides the HTTP endpoint, but does not explicitly compare when to use this vs the separate buys/sells tools. Usage context is implied by the name and Persian text, but no explicit when/when-not guidance is given.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the tool is public and requires no authentication, and maps to a specific HTTP GET endpoint, indicating a read-only operation. This adequately conveys the behavioral profile.

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 well-structured. It provides the core purpose, a Persian translation (optional but not harmful), authentication note, API mapping, and parameter explanations—all in a few sentences without redundancy.

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

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

Given the tool's simplicity and the presence of an output schema, the description covers essential aspects: purpose, parameters, auth, and API mapping. It is complete for a straightforward get-orderbook tool, though it could mention that returns only buy orders (already implied by name and 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?

The description adds value beyond the input schema by specifying that pair_id is a 'Numeric id' and that instance has a default when omitted. Since the schema has no descriptions for parameters (0% coverage), the description compensates well for both parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Get only the BUY side of the orderbook for a pair'. It uses a specific verb ('Get') and resource ('BUY side of orderbook'), and effectively distinguishes from sibling tools like ramzinex_get_orderbook_sells and ramzinex_get_orderbook.

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 includes useful context such as 'Public, no auth' and the API mapping. While it implies when to use (for buy side), it doesn't explicitly contrast with alternatives or state when not to use. Still, the context is clear enough for an agent to decide.

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?

With no annotations, the description covers key behavioral aspects: public, no auth, and the mapping to an API endpoint. It also explains the default for the instance parameter, adding 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 concise with no wasted words, well-structured with purpose, endpoint, and args sections.

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

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

Given the presence of an output schema, the description covers purpose, parameters, authentication, and endpoint mapping, making it complete for an agent to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description fully compensates by explaining pair_id as a numeric id and instance as a configured instance with a default. This adds complete meaning beyond the schema types.

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 gets the SELL side of the orderbook for a pair, specifying it is public, no auth, and maps to a specific endpoint. This differentiates it from sibling tools like ramzinex_get_orderbook_buys and ramzinex_get_orderbook.

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 this tool (when only sells are needed) by explicitly saying 'Get only the SELL side'. It does not explicitly mention alternatives, but sibling names provide context.

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?

No annotations are provided, so the description carries the burden. It states the tool is read-only and requires an API token, but does not disclose rate limits, authentication details beyond token, or pagination behavior (e.g., total count, result truncation). Basic transparency is present but could be more comprehensive.

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 reasonably concise, with front-loaded purpose and an organized 'Args' section. The inclusion of a Persian-purpose line adds context but slightly duplicates the English. Overall, it is well-structured and efficient, though it could be trimmed slightly without losing meaning.

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 8 parameters, no annotations, and a provided output schema (so return values need not be explained), the description is quite complete. It covers parameter details, read-only nature, and endpoint mapping. It lacks guidance on error conditions or rate limits, but for a read-only list tool, 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?

Despite the context indicating 0% schema coverage, the description lists all 8 parameters with defaults, ranges (e.g., limit 1-1000), and meanings. It adds value beyond the input schema by explaining how each filter works (e.g., 'Optional list of order-state ids to filter by'). This is excellent documentation.

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 'List my orders, filterable and paginated (read-only)'. It specifies the verb (list), resource (orders), and scope (my orders, filterable, paginated, read-only). It distinguishes from sibling tools like ramzinex_cancel_order and ramzinex_place_limit_order. The HTTP endpoint mapping adds further clarity.

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 indicates that the tool is read-only and requires a configured API token, implying when to use it. However, it does not explicitly state when not to use it or provide alternatives for similar functionality, such as ramzinex_get_order for a single order. There is no exclusion guidance, which 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.

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

Discloses that the tool is public and requires no authentication, and maps to a GET endpoint. With no annotations provided, the description adequately covers the read-only nature and access requirements.

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

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

Extremely concise with no fluff; efficiently communicates purpose, parameter explanation, and usage note. The Persian purpose line is redundant but does not detract from overall 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?

For a simple GET tool with an output schema, the description covers the essential: what it does, how to use it (including parameter details and prerequisite discovery), and its public nature. No gaps in 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?

Despite 0% schema description coverage, the description explains 'pair_id' with an example (2 for BTC/IRR) and describes 'instance' as an optional base URL config. This adds meaningful context beyond the schema types.

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 'Get a single Ramzinex market pair by its numeric id', specifying the exact action and resource. It includes the API endpoint and distinguishes from the sibling tool 'ramzinex_get_pairs' which lists all 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?

Explicitly advises to use 'ramzinex_get_pairs' to discover IDs, and notes that the tool is public and requires no auth. Lacks explicit 'when not to use' but provides sufficient guidance for correct invocation.

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?

With no annotations, the description bears full burden. It states the endpoint, auth status, and return fields (last price, buy/sell, volume). But it omits details like caching, update frequency, pagination, or rate limits, leaving gaps.

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 structured with a main sentence, a Persian phrase, endpoint mapping, and an args section. Slightly wordy with the Persian line, but overall clear and not excessive.

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 is a simple list-all-pairs function. The description covers purpose, endpoint, return data, and auth. An output schema exists. Missing context like data freshness or limits, but adequate for the tool's simplicity.

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 only parameter 'instance' is explained in the description as 'Configured instance whose public base URL to use', which adds meaning beyond the schema's type definition. Given 0% schema coverage, this explanation compensates well.

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 'List' and resource 'all Ramzinex market pairs'. It distinguishes from sibling 'ramzinex_get_pair' by specifying it returns the full set, not a single pair.

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 mentions 'Public, no auth', giving context that this is an unrestricted endpoint. However, it does not explicitly state when to use this versus other tools like 'ramzinex_get_pair' or 'ramzinex_get_orderbook'.

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

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

The description mentions public access, no auth, and the HTTP method (GET), which implies read-only behavior. However, with no annotations, it does not disclose potential side effects, rate limits, or data freshness.

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 relatively concise but includes a redundant Persian translation and a note about the path omitting the version segment. It is front-loaded with the key purpose.

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

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

Given the tool is a simple read operation with one optional parameter and an output schema exists, the description covers purpose, endpoint, auth, and parameter meaning adequately. It could be more thorough about response 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?

The parameter 'instance' is explained as a configured instance whose public base URL to use, with a default when omitted. This adds meaningful context beyond the bare schema (which has 0% description 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 retrieves a simple prices feed for all markets. However, it does not differentiate this from sibling price tools like ramzinex_get_market_buy_price or ramzinex_get_rial_equivalent, which weakens the distinction.

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. The description only notes it's public and no auth, but does not specify contexts 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?

With no annotations, the description fully handles behavioral disclosure. It declares the operation as read-only, notes required credentials, and transparently explains that the endpoint is a best-effort assumption based on documentation gaps. This goes beyond 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 multi-line but well-structured: clear purpose, Persian translation for locale, prerequisite note, implementation uncertainty disclosure, and parameter explanation. Each sentence adds value 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's simplicity (one optional parameter) and the presence of an output schema (which covers return structure), the description adequately covers context: read-only nature, credential requirements, and implementation status. It is sufficient for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. The single parameter 'instance' is described as 'Configured instance to use (default when omitted)', which adds the concept of a default behavior beyond the schema. However, it does not explain what an 'instance' is or how it affects the request, leaving some ambiguity.

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 'List reward / cashback entries (read-only)', which is a specific verb+resource. Among many sibling get_* tools, this is the only one for rewards, so it distinguishes clearly.

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 mentions 'Requires configured credentials' as a prerequisite, but does not provide guidance on when to use this tool versus alternatives or when not to use it. Usage context is implied but not explicit.

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?

No annotations are provided; the description labels the tool as 'read-only' and maps it to a GET endpoint, which implies safe behavior. It does not detail rate limits, authentication specifics beyond credentials, or side effects, but the basic behavioral trait is disclosed.

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 with three main parts: purpose, Persian translation, endpoint mapping, and parameter explanation. The Persian line adds extra content but is not verbose. Overall efficient.

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

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

The tool is simple with one optional parameter. The description provides enough context: purpose, read-only nature, credential requirement, and endpoint. With an output schema present, return values need not be detailed. Minor gaps like error conditions are acceptable.

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 has 0% parameter descriptions, but the description clarifies the sole parameter 'instance' as 'Configured instance to use (default when omitted)', adding meaning beyond the schema's type definition.

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 'Get', the resource 'total account value', and the specific unit 'Iranian Rial'. It also notes it's read-only, and the name distinguishes it from similar tools like ramzinex_get_usdt_equivalent.

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 mentions 'Requires configured credentials' but does not explicitly state when to use this tool versus alternatives like ramzinex_get_usdt_equivalent or ramzinex_get_total_balance. Usage is implied by the name and description.

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?

With no annotations provided, the description carries full burden. It mentions read-only and credential requirements, but does not disclose error handling, behavior on invalid inputs, rate limits, or other 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 concise and front-loaded with purpose. It uses a clear structure with Persian translation, credential note, API mapping, and parameter list. No unnecessary words.

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

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

Given the tool's simplicity and the presence of an output schema, the description covers the essential aspects: purpose, prerequisite, parameter sources. It could mention error cases but is adequately 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 0%, so the description must compensate. It provides meaningful context: currency_id is a numeric id from ramzinex_get_currencies, and instance defaults when omitted. This adds 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 'Get the total balance for one currency (read-only)' with a Persian translation. It identifies the specific resource, but does not explicitly differentiate from sibling tools like ramzinex_get_available_balance or ramzinex_get_balance_summary.

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

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

It notes that credentials are required and that the tool is read-only. It also indicates that currency_id comes from ramzinex_get_currencies, but it lacks explicit guidance on when to use this tool versus other balance-related tools.

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

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

The description notes the tool is read-only and maps to a specific API endpoint. However, without annotations, it should disclose more about authentication requirements (beyond 'configured API token'), error behavior, or any constraints like rate limits. The read-only nature is clear, but additional behavioral traits are missing.

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, uses only 4 short lines for the English part, and front-loads the main purpose. Every sentence provides necessary information without 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?

The description covers the core functionality but lacks context on what the output represents (e.g., total turnover vs. per-day), how it differs from other statistical tools, or whether pagination is involved. Given the output schema exists, return values are not required, but more differentiation from siblings would help.

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 has 0% coverage, so the description fully compensates by explaining both parameters: days (range 1-3650, default 30) and instance (configured instance, default when omitted). This adds significant meaning beyond the bare 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 (Get), resource (my trading turnover), and constraint (over a number of days). It also notes it's read-only and provides Persian purpose and API mapping, making it well-defined and distinct from many similar get_* 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 like ramzinex_get_orders or ramzinex_get_balance_summary. The description does not mention contextual triggers or exclusions, leaving the AI agent to infer usage.

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

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

The description discloses that the tool is 'read-only' and requires credentials, which are important behavioral traits. However, it does not elaborate on what happens if credentials are missing, rate limits, or the exact structure of the response (though output schema may cover that). Without annotations, the description carries the burden and is adequate but not thorough.

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: one sentence for the main purpose, followed by a Persian translation, credential requirement, endpoint mapping, and parameter explanation. No unnecessary words, and the critical information is front-loaded.

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

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

Given the tool's simplicity (one optional parameter, read-only, output schema exists), the description covers the key aspects: what it does, the endpoint, and parameter usage. However, it could be more explicit about when to prefer this over similar tools, but overall it is fairly 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?

The only parameter 'instance' is described as 'Configured instance to use (default when omitted).' This adds meaning beyond the schema's type definition, which only lists string|null and default null. With schema description coverage at 0%, the description compensates minimally. 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 tool's function: 'Get the total account value expressed in USDT (read-only).' This provides a specific verb and resource, and the 'read-only' qualifier adds precision. The sibling tool 'ramzinex_get_rial_equivalent' suggests a similar tool for IRR, so the USDT focus distinguishes them effectively.

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 mentions 'Requires configured credentials' but offers no guidance on when to use this tool versus alternatives like 'ramzinex_get_available_balance' or 'ramzinex_get_total_balance'. It does not state when not to use it or provide explicit usage context.

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?

With no annotations, the description carries the burden. It explicitly states 'read-only' and maps to a GET endpoint, confirming no side effects. It also notes credential requirements. However, it does not mention error handling or behavior for invalid IDs, but for a simple read, the provided details are 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?

The description is extremely concise with three sentences plus a bullet list. It front-loads the purpose, includes essential details, and avoids unnecessary fluff. Every sentence adds value.

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), the description does not need to detail return values. It covers purpose, parameters, authentication, and read-only nature. For a simple get-by-ID tool, this is complete and leaves no major gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. It provides clear descriptions for both parameters: 'withdraw_id: Numeric id of the withdrawal to fetch' and 'instance: Configured instance to use (default when omitted)'. This adds meaning beyond the schema types and requiredness.

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 'Get one withdrawal by id (read-only)'. It specifies the action (get), resource (withdrawal), and read-only nature. The HTTP endpoint mapping further clarifies. This effectively distinguishes from sibling tools like ramzinex_get_withdraws (multiple) and ramzinex_submit_withdraw (create).

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 mentions 'Requires configured credentials', indicating prerequisite. It implicitly suggests usage when a single withdrawal ID is known, but does not explicitly state when not to use or compare to alternatives like ramzinex_get_withdraws. Clear context but lacks explicit exclusion or guidance.

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

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

No annotations provided, so description carries burden. Discloses read-only nature, pagination, and endpoint. Does not mention rate limits, error responses, or data scope beyond 'my'. With output schema present, return value details are not required.

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?

Front-loaded summary, followed by endpoint mapping and parameter explanations. No redundant text; every sentence adds value. Efficient structure.

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

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

Tool has 4 optional params, output schema exists, and siblings are numerous. Description covers authentication, pagination, and parameter usage. Lacks potential error scenarios or conditions, but overall sufficient for correct usage.

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%, but description adds full meaning for all 4 parameters: limit range (1-1000) and default, offset default, currency_id as optional filter, instance as optional config.

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 'List my withdrawals, paginated (read-only).' Distinguishes from sibling ramzinex_get_withdraw (singular) which gets one specific withdrawal. Also mentions endpoint mapping and optional currency filter.

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 states 'Requires configured credentials.' and implies usage for listing user's withdrawals. No explicit when-not-to-use or alternatives, but context from siblings is adequate.

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?

No annotations provided, so description carries full burden. Discloses real trade execution, requirement for enable_trading=true, maps to specific endpoint, warns about real funds. Missing details on rate limits or success response, but sufficient for core 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?

Well-structured with warning, purpose, requirements, endpoint, and Args list. Slightly lengthy but each sentence serves a purpose. Could be trimmed slightly without losing 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 complexity as a trading tool with 5 params and no annotations, description covers purpose, requirements, parameters, and caution. Output schema exists, so return value not needed. Lacks mention of order lifecycle but adequate for selection and invocation.

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 a dedicated Args section explaining each parameter with constraints (e.g., amount and price must be >0, type is buy/sell). Adds significant meaning beyond bare 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?

Clearly states it places a LIMIT order, uses specific verb 'Place', identifies resource as LIMIT order with real trade warning, and the Persian purpose adds clarity. Distinguishes from sibling tools like market order and various query 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?

Provides strong usage context: warning about real trade, requires API token and enable_trading=true, double-check parameters. However, lacks explicit when-not-to-use or comparison to ramzinex_place_market_order, so not a complete guide.

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?

No annotations provided, so description fully covers behavioral traits: real trade, immediate fill, price not guaranteed, prerequisite checks, and error response. Additionally maps to API endpoint.

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?

Concise yet comprehensive: warning first, then prerequisite, Persian purpose, endpoint mapping, behavior, and clear Args section. No unnecessary text.

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 output schema present, the description covers input and behavior well. Could mention success response briefly, but not required. Overall complete for a market order 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 0%, but the description explicitly explains each parameter: pair_id (numeric id), amount (base currency, >0), type (buy/sell), instance (configured instance). Adds meaning beyond schema types.

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 places a MARKET order, warns it executes a real trade, and includes a Persian purpose. It distinguishes from sibling ramzinex_place_limit_order by specifying market order characteristics.

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 specifies prerequisites (API token, enable_trading=true) and warns about the real trade and execution behavior. It implies usage for immediate execution but does not explicitly compare with limit order.

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?

With no annotations, the description discloses key behavioral traits: it does not move funds, it re-scans for incoming deposits, and requires credentials. It does not mention rate limits or side effects, but the non-destructive nature is transparent. The API endpoint mapping adds clarity.

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 with no wasted words. Front-loaded with the main action, followed by Persian purpose, requirements, behavior, API mapping, and parameter explanations. Well-structured 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 tool's simplicity (2 params, 1 required, output schema exists), the description covers purpose, non-destructive nature, and parameter meanings. It does not discuss error handling or output format, but the presence of output schema reduces the burden. Mostly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It explains currency_id as 'numeric id of the currency' and instance as 'configured instance to use (default when omitted)'. This adds meaning beyond the schema's type definitions. Could be enriched with constraints or examples, but adequate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.