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

With no annotations, the description carries the full burden and does so well: it discloses the IP-whitelist constraint that produces HTTP 403 from non-whitelisted IPs, a rate limit of 200/day, and the automatic token caching side effect. These are precisely the preconditions and side effects an agent needs before invoking a credential-exchanging tool.

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?

Four tight sentences with zero repetition: purpose first, the critical IP restriction flagged with IMPORTANT, then rate limit and caching. Nothing is wasted and the safety-critical content is elevated rather than buried.

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 2-param credential tool with no output schema or annotations, it covers preconditions, quotas, and the caching side effect. The only real omission is not distinguishing itself from the token-management siblings (refresh_token, set_access_token), which would complete the picture.

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

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

Schema description coverage is 100%, including the environment-variable fallback for both api_key and secret_key, so the schema already does the heavy lifting and the baseline of 3 applies. The description adds no parameter-level detail beyond what the schema states.

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

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

States a specific verb and resource: authenticate against the BitPin API using API Key/Secret to obtain JWT access and refresh tokens. It is clearly distinct from read-only siblings, though it never names bitpin_refresh_token or bitpin_set_access_token, which are the closest alternatives.

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 context (you need this to get tokens) and usefully notes that tokens are cached automatically for subsequent requests, which implicitly reduces the need to re-call. However, it gives no explicit guidance on when to use bitpin_authenticate versus bitpin_refresh_token or bitpin_set_access_token — exactly the routing decision an agent faces.

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 does disclose the authentication requirement and that only active orders are affected, which is useful mutation context. It says nothing about irreversibility, partial-failure behavior when some IDs are invalid or already filled, or rate limits.

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

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

Two short sentences; the action and batch scope lead, and the auth requirement trails as a secondary note. No filler or 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?

For a one-parameter tool with full schema coverage and no output schema, the description covers purpose and auth adequately. What is missing is behavioral detail on failure handling and confirmation of the result, which matters for a destructive batch operation with no annotations to fall back on.

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

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

Schema coverage is 100% and the ids property already documents both accepted forms with examples (["123","456"] or "123,456"). The description restates the same list-or-comma-separated fact without adding constraints such as maximum batch size or how invalid IDs are reported, so baseline 3 applies.

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

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

States a specific verb (cancel) and resource (multiple active orders) with the batch scope front and center, which implicitly separates it from the single-order sibling bitpin_cancel_order. It doesn't name that sibling, so the differentiation is inferred rather than explicit.

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?

"Cancel multiple active orders at once" implies the batch scenario, and "Requires authentication" states a prerequisite. However, there is no explicit when-to-use vs. bitpin_cancel_order or bitpin_get_orders, and no mention of preconditions such as whether the orders must still be open.

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, and it delivers two non-schema behavioral facts: a 5400/hour rate limit and an authentication requirement. It still omits mutation consequences such as irreversibility or behavior for partially filled orders, which matters for a destructive operation.

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

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

Three short, front-loaded sentences — action, rate limit, auth — with no filler or repetition of schema content.

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

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

For a one-parameter cancellation tool with full schema documentation, the description covers action, constraint, and auth. The remaining gap is outcome semantics (what happens on success/failure, partial fills), which is notable since no output schema exists.

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

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

Schema description coverage is 100% and the order_id field already documents accepted formats including Persian digits. The description adds no parameter-level detail beyond 'by its order ID', so baseline 3 applies.

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

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

States a specific verb and resource ('Cancel an active open order on BitPin') qualified by order ID, which is materially clearer than the bare name. It does not explicitly distinguish itself from the sibling bitpin_cancel_bulk_orders, leaving singular-vs-bulk differentiation to inference.

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 phrase 'active open order' implies it only applies to orders that are still open, which is useful selection guidance. However, there is no explicit statement of when NOT to use it or a pointer to bitpin_cancel_bulk_orders / bitpin_get_order_by_id for lookup before cancelling.

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 does disclose two important behaviors: authentication is required and the request is not final until OTP confirmation. It does not cover irreversibility, fee handling, address/network validation, or failure behavior, which matter for a financial mutation.

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

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

Three short sentences, with the core action front-loaded and the OTP requirement immediately following. Nothing is wasted, though 'Requires authentication' is somewhat generic boilerplate.

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 5-parameter mutation with no annotations and no output schema, it covers auth and the OTP flow but omits what the response contains, how the subsequent verification is performed, and any constraints around fees or limits. Adequate but with clear gaps.

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

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

Schema description coverage is 100%, so all five parameters, including memo and Persian numeral support, are already documented in the schema. The description adds no parameter-level meaning beyond that baseline.

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

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

The description names a specific verb and resource: submitting a cryptocurrency withdrawal request to an external blockchain wallet. The 'external blockchain wallet' scoping implicitly distinguishes it from internal/IRT withdrawal siblings, but it never names those alternatives explicitly.

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

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

It states a precondition (authentication) and a follow-up step (OTP confirmation), which gives useful context. However, it does not explicitly say when to choose this over bitpin_create_internal_withdrawal or bitpin_create_irt_withdrawal, leaving that to inference.

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 disclosure burden. It does add useful context (zero-fee, instant, "Requires authentication"), but for an irreversible money-movement mutation it omits whether OTP confirmation is needed (a sibling bitpin_verify_withdrawal_otp exists), whether the transfer can be cancelled or reversed, and what failure conditions look like.

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

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

Two short sentences, with the core action and its distinguishing traits front-loaded and the authentication caveat trailing. Nothing redundant.

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 three-required-parameter fund-transfer with no annotations and no output schema, the description covers purpose but not the operational picture: confirmation/OTP flow, expected result, and error behavior are all absent, so an agent cannot fully anticipate the call sequence.

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

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

Schema coverage is 100% and all three parameters are documented in-schema, so the baseline is 3. The description only reinforces that alternative_address is a BitPin-registered mobile or email; it adds no format, validation, or cross-parameter rules 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?

States a specific verb and resource ("cryptocurrency transfer") plus the distinguishing scope: internal, instant, zero-fee, and to another BitPin user via phone/email. That scope makes it self-evidently distinct from the on-chain and IRT withdrawal siblings without naming them.

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

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

The adjectives "instant, zero-fee" and "another BitPin user" imply the when-to-use case (internal P2P transfers), but the description never explicitly routes the agent: it does not name bitpin_create_crypto_withdrawal or bitpin_create_irt_withdrawal as the alternatives for external/IRT withdrawals, nor state prerequisites such as wallets or limits.

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 usefully discloses that authentication is required and that a follow-up OTP step exists, but says nothing about irreversibility, when funds are debited, fees/limits, or what the call returns – meaningful gaps for a financial mutation.

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

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

Three short sentences, front-loaded with the action and destination, followed by the two operational requirements. No filler and nothing important buried.

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 2-parameter financial mutation with no annotations and no output schema, the description covers the essential flow but omits return behavior and how the OTP step connects to bitpin_verify_withdrawal_otp. An agent knows what the tool does but not fully what to expect after calling it.

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

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

Schema description coverage is 100%, so both amount and account_number are already fully documented in the schema. The description adds no parameter-level detail (e.g. formatting, limits, where to obtain the account ID) beyond the schema baseline.

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

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

States a specific verb and resource ('Submit an Iranian Toman (IRT) withdrawal') and narrows the destination to 'a registered bank account on BitPin.' This distinguishes it implicitly from crypto and internal withdrawal siblings, but no sibling is named explicitly, so it falls short of a 5.

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

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

Gives prerequisites ('Requires authentication', 'Requires subsequent OTP confirmation') that imply the flow, but never states when to choose this over bitpin_create_crypto_withdrawal or bitpin_create_internal_withdrawal. Usage is inferable only from the IRT/bank-account framing.

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 carries the burden and does meaningful work: it discloses that authentication is required and gives an explicit rate limit of 60/min — operational facts an agent can't get from the schema. It stops short of describing the return shape (list of IBAN/card records) or pagination semantics.

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

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

Two short sentences with zero filler, and the core purpose is front-loaded ahead of the operational constraints.

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

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

For a two-optional-parameter read tool with no output schema, the description covers purpose, auth, and rate limits. The main missing piece is a brief indication of what the returned records contain (e.g., bank name, IBAN masked) so the agent knows what it can act on.

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

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

Schema coverage is 100% and both parameters (limit, offset) are documented there; the description adds no further meaning such as maximum page size or default behavior. Baseline 3 applies since the schema does the heavy lifting.

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

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

Names a specific verb ('Get') and a precisely scoped resource ('user registered bank accounts (IBAN/card numbers) for Toman (IRT) withdrawals'), which clearly separates it from siblings like get_deposit_address, get_wallet_balances, and get_withdrawal_history.

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 scoping to IRT withdrawals implies the tool's role as a prerequisite step for create_irt_withdrawal, but this is never stated. There are no explicit when-to-use/when-not conditions and no named alternatives, so the agent must infer routing.

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 at all, the description carries the full disclosure burden and delivers the two operationally critical facts: authentication is required and there is a 1000/day rate limit. It stops short of describing the response shape (e.g., whether rates are nested per market or flat) or error behavior, which matters given there is no output schema.

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

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

Three short sentences with zero filler, ordered by importance: what it returns, then the auth requirement, then the rate limit. Every sentence earns its place.

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

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

For a no-argument read tool with no output schema, the description covers purpose, scope, auth, and throttling — nearly everything needed to call it correctly. The only mild gap is the response structure, which an agent could reasonably guess but is not told.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline applies. The schema is empty and complete, and the 'all markets' phrasing correctly signals that no filtering argument exists.

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

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

States a specific verb ('Get') and a precise resource ('maker and taker commission rates') scoped to 'all markets on BitPin'. This is clearly separable from data-oriented siblings like bitpin_get_markets and bitpin_get_tickers without opening any schema.

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

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

The description implies the use case (looking up fee rates) and notes the authentication precondition, but never says when to reach for this versus neighboring market-data tools, nor does it name any alternative. An agent must infer the selection 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?

With no annotations, the description carries the full burden and does add genuinely non-schema information: the dual rate limits (10,000/day public, 200/min authenticated), which also signals the auth distinction of the underlying call. It stops short of describing result ordering, pagination (or lack thereof), or how the optional filter interacts with the returned list.

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

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

Two sentences, zero filler. The core purpose and returned fields come first, with the rate-limit caveat as a compact second sentence; every clause earns its place.

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

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

For a simple, single-parameter read tool with a fully documented schema, the description is close to complete, and it even enumerates the response fields despite no output schema. The only gap is the unmentioned filter parameter, which would have made the 'all currencies' claim more precise.

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

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

Schema description coverage is 100%, and the single `currency` parameter is fully documented there with ticker and Persian-name examples. The description never mentions the filtering capability at all, so it adds nothing beyond the schema — baseline 3 applies.

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

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

Specific verb + resource: lists all supported crypto and fiat currencies on BitPin, and names the returned fields (symbol, title, precision, trading status). It does not distinguish itself from adjacent reference-data siblings like bitpin_get_markets, bitpin_get_networks, or bitpin_get_tickers, so an agent must infer the difference.

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

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

Usage is only implied — this is clearly a reference/lookup call, and the rate-limit note hints at how cheaply it can be called. There is no explicit statement of when to use it instead of get_markets or get_tickers, and no prerequisites 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 carries the full burden and does disclose auth, KYC gating, and a concrete rate limit — three real behavioral constraints. The remaining gap is side-effect semantics: it doesn't say whether repeat calls return the same address or mint a new one, which matters for a tool that can 'generate'.

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

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

Three short sentences, action front-loaded, with each subsequent sentence adding a distinct constraint (KYC, rate limit, auth). No filler or 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?

For a two-parameter read-ish tool this covers purpose, access requirements, and throughput. The notable omission is return shape, since there is no output schema: an agent isn't told whether to expect a bare address, a memo/tag, or an expiry — relevant for networks that require destination tags.

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

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

Schema coverage is 100% and both parameters are documented with concrete examples, including Persian ticker forms. The description only restates the concepts ('cryptocurrency', 'blockchain network') without adding format rules, valid-value sources, or the currency/network pairing constraint, so baseline 3 applies.

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

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

States a specific verb pair (get or generate), a precise resource (deposit address), and the scoping qualifiers (cryptocurrency + blockchain network). No sibling tool retrieves deposit addresses, so an agent can route here unambiguously, and the 'get or generate' phrasing hints at the create-on-demand nuance up front.

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

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

Gives the entry preconditions an agent needs before calling: authentication, KYC level 1+, and a 60/min rate limit. It does not, however, point to bitpin_get_currencies or bitpin_get_networks as the way to discover valid currency/network values, so no alternatives or exclusions are stated.

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 load. It usefully discloses a rate limit (60/min) and the authentication requirement, which are real behavioral facts. However, it omits that this is a read-only operation, says nothing about the return shape, and does not describe pagination behavior despite limit/offset params.

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

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

Three short, front-loaded sentences with no filler; purpose comes first, then filters, then operational constraints. Efficient and easy to scan.

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 read-only history endpoint with full schema coverage and no output schema, the description covers the essentials: what it returns (deposit history), how to scope it, the rate limit, and auth. The main gap is the undisclosed pagination semantics, which is minor given the documented limit/offset params.

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

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

Schema description coverage is 100%, so each parameter is already documented in the schema, making 3 the baseline. The description restates the filter names but adds no syntax or format detail beyond the schema, and it references a 'wallet_transfer' filter that does not actually appear among the schema properties, which is mildly misleading.

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

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

States a specific verb and resource ('Get deposit history on BitPin'), which clearly distinguishes it from a generic history call. It does not explicitly differentiate from the sibling bitpin_get_withdrawal_history, but the deposit-vs-withdrawal distinction is carried by the name and resource.

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 listed filters imply when you'd want this tool (to narrow deposit history by currency, network, state), but there is no explicit guidance on when to use it versus alternatives like bitpin_get_withdrawal_history or bitpin_get_deposit_address. Usage is inferable rather than stated.

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 and does well: it discloses the 80/min rate limit and the authentication requirement, both of which are real operational constraints an agent must plan around. It stops short of describing result ordering or what a fill record contains.

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

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

Three compact sentences: purpose first, filters second, operational constraints last. No filler, and the most decision-relevant information is front-loaded.

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

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

For a zero-required-param read tool with a fully documented schema, this is nearly sufficient, and the auth and rate-limit notes fill the annotation gap. However, with no output schema the description says nothing about what a returned fill looks like or how pagination terminates, leaving a modest gap.

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

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

Schema coverage is 100% and every parameter already documents itself, including defaults and the Persian alternatives. The description merely enumerates the same filter names without adding format or behavioral detail, so baseline 3 applies.

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

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

States a specific verb+resource ("Get personal executed trade history (fills)") and the qualifier "personal" implicitly separates it from the public bitpin_get_recent_trades. It never names that sibling explicitly, so differentiation requires a small inference.

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 word "personal" implies this is the authenticated counterpart to the public recent-trades listing, but the description never states when to choose this over bitpin_get_recent_trades or bitpin_get_orders. Usage is implied rather than spelled out.

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 and does disclose concrete rate limits (10,000/day public vs 200/min authenticated), which importantly signals that an unauthenticated call is viable. It does not say whether the full list is returned in one response or paginated, and doesn't state ordering.

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

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

Two sentences, zero waste: purpose and returned fields first, operational constraint second. Front-loaded and appropriately sized for a simple read tool.

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

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

There is no output schema, so listing the returned fields is the right compensation, and it does that. The remaining gap is whether the result set is complete or paginated and whether filters are combinable — minor for a low-complexity, zero-required-parameter read 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 100%, so both optional filters (symbol, quote_currency) are already fully documented in the schema, including Persian-language expression support. The description adds nothing about parameter behavior beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get a list of all trading markets/pairs on BitPin') and enumerates the payload fields (base/quote currencies, minimum order sizes, price precisions), which cleanly separates it from siblings like get_tickers or get_orderbook. It stops short of naming those siblings explicitly, so it lacks full differentiation.

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

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

Usage is only implied: an agent infers this is the discovery/reference call for market metadata. There is no statement about when to prefer it over get_tickers or get_currencies, and no guidance on combining the two optional filters.

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 usefully discloses the shape of the returned data (deposit/withdrawal statuses, regex validation patterns, confirmation counts), but says nothing about authentication requirements, rate limits, or the fact that results are unfiltered by default if no params are passed.

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

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

A single front-loaded sentence with no filler; the return-content list is compact and informative. It stops just short of being maximally efficient because the enumeration of return fields substitutes for a structured output schema.

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

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

With no output schema and no annotations, the description compensates by listing what the response contains, which is what an agent needs to decide whether to call it before bitpin_get_deposit_address. Auth/prerequisite context is the only notable omission.

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

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

Schema description coverage is 100%, so all three filters (code, can_deposit, can_withdraw) are already documented including Persian value variants. The description adds no parameter detail beyond the schema, which matches the baseline 3.

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

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

States a specific verb and resource ('Get all supported blockchain networks on BitPin') and enumerates the data returned. It does not explicitly distinguish itself from nearby metadata siblings such as bitpin_get_currencies, but the resource is unambiguous.

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

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

Usage is only implied: an agent can infer this is a lookup to run before choosing a network for deposit/withdrawal. There is no explicit when-to-use, when-not-to-use, or pointer to an alternative sibling.

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 and does add two genuinely useful operational facts: a hard truncation of 20 rows per side and a rate limit of 60/min. It does not mention whether authentication is required or whether the data is a live snapshot, leaving a small gap.

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

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

Three short sentences, front-loaded with the purpose, then the capacity limit, then the rate limit. Nothing is redundant and nothing important is buried.

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 single-parameter read tool with no output schema and no annotations, the description covers purpose, data shape, truncation, and throttling. It stops short of stating auth requirements or confirming the return field structure (price/quantity levels), which would fully close the loop.

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

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

Schema coverage is 100% and the schema's own description already gives example symbols in both Latin and Persian form. The description only restates "specified market pair" without adding normalization or case rules, so the baseline 3 applies.

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

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

States a specific verb and resource ("Get orderbook") and qualifies what it contains ("bids and asks") for a scoped resource ("a specified market pair on BitPin"). This is clearly distinguishable from sibling market-data tools like bitpin_get_tickers or bitpin_get_recent_trades.

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

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

The description never says when to reach for this tool versus bitpin_get_tickers, bitpin_get_recent_trades, or bitpin_get_markets, nor does it state any preconditions. The use case is inferable from the resource name, but no guidance or routing is offered.

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 behavioral burden and does deliver two concrete facts beyond the schema: authentication is required and the rate limit is 80/min. It stops short of noting behavior for an unknown or expired order ID, or whether the call is read-only, but the operational constraints given are genuinely useful.

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

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

Three short sentences, front-loaded with the purpose, then constraints. No filler and nothing an agent must read past to understand the tool.

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

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

For a one-parameter read lookup with full schema coverage this is nearly complete: purpose, ID format, auth, and rate limit are all present. Since there is no output schema, a brief indication of what 'details and status' includes would have closed the remaining gap.

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

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

Schema coverage is 100% and the single order_id parameter is fully described, including Persian-digit formatting. The description adds nothing beyond the schema beyond restating 'BitPin order ID', so baseline 3 is appropriate.

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

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

States a specific verb ('Get details and status'), a specific resource ('a single order'), and the identifying key ('by its BitPin order ID'). This implicitly separates it from the plural sibling bitpin_get_orders and from bitpin_get_fills, but it never names an alternative, so differentiation is only inferable.

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 phrase 'by its BitPin order ID' implies the precondition of already holding an order ID, but there is no explicit guidance on when to call this versus bitpin_get_orders or bitpin_get_fills. The authentication requirement is stated, which is useful context but not usage direction.

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 real weight and does deliver two concrete behavioral facts: rate limit of 80/min and an authentication requirement. It omits return ordering and whether the 7-day window can be widened, so it is strong but not complete.

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

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

Three short sentences, front-loaded with scope, then filters, then operational constraints. Nothing is redundant and nothing could be cut without losing information.

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

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

For a nine-parameter read-only listing tool with full schema coverage and no output schema, the description covers scope, filter surface, rate limit and auth. Pagination is delegated to the documented limit/offset parameters, which is 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?

Schema description coverage is 100%, so all nine parameters are already documented. The description's mention of symbol, state, side and date range only restates fields the schema explains more fully (including Persian aliases and comma-separated states), so baseline 3 applies.

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

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

States a specific verb and resource plus an explicit scope: active and closed orders from the last 7 days on BitPin. That scope implicitly separates it from bitpin_get_order_by_id (single order) and bitpin_get_fills (executions), but no sibling is named outright.

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?

Lists the available filters (symbol, state, side, date range) which implies how the tool is typically used, but never says when to reach for this versus bitpin_get_order_by_id or bitpin_cancel_order-style lookups, nor any prerequisite sequencing.

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, and the rate limit (60/min) is a genuinely useful behavioral disclosure. However, it says nothing about ordering (newest first?), how many trades are returned by default, or whether the call is read-only/public without credentials — for a zero-annotation tool that leaves real 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?

Two short sentences, purpose front-loaded, the operational constraint (rate limit) placed last. Nothing redundant or padded.

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?

A simple single-parameter read tool with no output schema or annotations needs little more than what is present: purpose, input, and rate limit. The missing piece is result semantics (default size/ordering), which an agent would otherwise have to discover empirically.

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

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

Schema coverage is 100% and the single symbol parameter is fully documented with examples including Persian names, so the schema does the heavy lifting. The description only restates that a market pair is required and adds no format or normalization guidance 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?

Specific verb + resource + scope: "latest executed public trades/matches for a specified market pair on BitPin." The word "public" implicitly separates it from bitpin_get_fills (the authenticated user's own fills) without naming that sibling, so an agent can mostly route correctly but must infer 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?

Usage is only implied: a market pair is required and the data is public, which suggests unauthenticated market-data lookup. There is no explicit statement of when to prefer this over bitpin_get_fills or bitpin_get_orderbook, and no note that authentication is not required.

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 supplied, so the description carries the full burden. It does disclose a concrete rate limit (80/min), which is genuinely useful operational context, but it says nothing about authentication requirements (notable given authenticate/set_access_token siblings), response ordering, caching/freshness of 'real-time', or error 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?

Two sentences: the first front-loads what is returned, the second front-loads the operational constraint. No filler, no repetition of the tool name.

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

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

With one optional parameter, no annotations, and no output schema, the description usefully enumerates the returned fields and adds a rate limit, which covers most of what an agent needs. The remaining gap is auth/public-endpoint status and whether results are paginated or capped, which for a 'fetch all tickers' call matters.

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

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

Schema coverage is 100% and the single optional symbol parameter is fully documented with both Latin and Persian examples plus the omit-to-get-all behavior. The description adds nothing about the parameter, so baseline 3 applies — the schema does all the work.

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

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

Specific verb ('Get') plus resource ('real-time market prices ... for all trading pairs') and it enumerates the payload fields (24h change, high, low, volume), which makes it easy to tell apart from bitpin_get_orderbook or bitpin_get_recent_trades. It never explicitly distinguishes itself from bitpin_get_markets (pair metadata) though, so an agent must infer the boundary.

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

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

Usage is only implied: the description frames the tool as returning 'all trading pairs', and the schema's note that omitting symbol returns all tickers carries the when-to-use signal. There is no explicit guidance on when to prefer a single-symbol call or which sibling to use for order book/trade data.

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 and does well: it discloses the rate limit (60/min), the authentication requirement, and the max limit of 200. It doesn't explicitly confirm the operation is read-only or describe whether balances are live vs settled, leaving a small gap.

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

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

A tight, front-loaded passage that packs purpose, filters, and operational constraints into a few lines with no filler. Slightly dense in list form but 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?

For a read-only balances tool with no output schema, the description covers purpose, filtering, and operational limits adequately. It doesn't describe the returned balance structure, but with no output schema that omission is minor.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description's examples (Persian asset names, service='main', limit max 200) largely restate the schema, so baseline 3 is appropriate.

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

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

States a specific verb ('Get') and resource ('user wallet balances per asset on BitPin'), which is clearly distinct from siblings like get_account_numbers or get_commissions. It lacks an explicit pointer to the nearest alternative, so it stops short of 5.

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

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

Provides filter context (assets, service, pagination) and the authentication requirement, implying when the tool applies. However, it never says when to prefer this over related tools or what the preconditions are beyond 'requires authentication'.

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 and does add real behavioral context: authentication requirement and a 10,000/day rate limit. However it omits pagination behavior (limit/offset defaults), ordering of results, and return shape, which matters for a history-listing tool.

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

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

Three short, front-loaded clauses with zero padding: purpose, filters, then operational constraints. Every sentence earns its place.

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

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

Covers auth, rate limit, and filter set, but for a 7-parameter paginated list tool with no output schema, the absence of pagination and result-shape guidance leaves meaningful gaps 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 100% with per-parameter descriptions including format hints (YYYY-MM-DD) and a currency example, so the schema does the heavy lifting. The description restates the main filters but adds nothing beyond the schema and omits limit/offset.

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

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

States a specific verb and resource ("Get withdrawal history on BitPin") and enumerates the filterable dimensions, which cleanly separates it from siblings like bitpin_get_deposit_history and bitpin_get_fills.

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?

Implied usage only: it tells you what it returns and the rate limit, but never says when to prefer it over related tools or what happens with no filters applied. No explicit when-not 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 carries the full burden; it does add that authentication is required, which is useful. But for a bulk write tool the critical behavior is undisclosed: whether the batch is atomic or partially applied on failure, what validation rejects individual orders, and whether the operation is reversible.

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

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

Two sentences, the capability and its magnitude front-loaded, followed by the prerequisite. No filler to remove.

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 bulk-mutating order-placement tool with no annotations and no output schema, the description covers capability and auth but omits partial-failure semantics and any hint of the per-order error behavior an agent needs before firing ten real orders.

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

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

Schema description coverage is 100% and the single top-level parameter (orders) is itself documented as 'Array of up to 10 order payloads', so the schema does the heavy lifting. The description only restates the 10-order cap and adds nothing about per-order fields like limit vs market 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?

Names a specific verb and resource (place orders) plus a quantifiable scope (up to 10 simultaneously, single market), which clearly separates it from the single-order sibling bitpin_place_order. It stops short of naming that sibling explicitly, so the differentiation is inferable rather than stated.

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 'up to 10 ... simultaneously on a single market' phrasing implicitly tells an agent when to prefer this over bitpin_place_order, but there is no explicit when/when-not guidance, no note on whether cross-market batches are allowed, and no pointer to cancel_bulk_orders for rollback.

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 carries the full burden: it does disclose the auth requirement and the language flexibility, which is real value. However, it never says this submits a live, irreversible trade on real funds, nor anything about validation failures, minimums, or what happens on rejection — significant omissions for an order-placement mutation.

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

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

Three short sentences with the action front-loaded, followed by supported types and then the environment constraints. Nothing is padded and there is no narrative filler.

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

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

With 9 parameters, no annotations, and no output schema, the description covers purpose and language handling but omits the conditional parameter dependencies (price for limit/stop_limit/oco, stop_price for stop orders, quote_amount for market buys) and gives no hint of the return value such as an order ID or status. Adequate but with clear gaps for a high-stakes mutation.

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

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

Schema description coverage is 100% and each parameter is documented with type, requiredness context, and Persian variants. The description's only added parameter-adjacent claim — accepting English or Persian input, including Persian numerals — is already repeated in nearly every schema field description, so it adds little 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?

States a specific verb and resource ('Place a new cryptocurrency order on BitPin') and enumerates the supported order types, which lets an agent distinguish it from read-only siblings like bitpin_get_orders and bitpin_get_order_by_id. It does not explicitly contrast with bitpin_place_bulk_orders, so sibling differentiation is incomplete.

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 usage context is implied by the name and the order-type list, and 'Requires authentication' signals a prerequisite. There is no explicit statement of when to prefer this over bitpin_place_bulk_orders, nor any caveat about when not to use it.

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

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

With no annotations, the description carries the full burden and it does volunteer a concrete operational constraint (200 requests/day) and the token source. However, it says nothing about whether the new token is cached, returned in the response, or how failures behave — meaningful gaps for an auth-mutation tool with no output schema.

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

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

Two short sentences, no filler. The purpose is front-loaded and the rate limit appended as a compact constraint.

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 one-parameter tool this is close to sufficient, but with no annotations and no output schema the description should say what the caller gets back — a new access token, a cached-token side effect, or an error mode — and it does not.

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

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

Schema description coverage is 100% and the single optional parameter's fallback behavior (cached value or BITPIN_REFRESH_TOKEN) is fully documented in the schema. The description adds no parameter meaning beyond that, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Refreshes an expired BitPin JWT access token') with the mechanism ('using a refresh token'). It is distinguishable from bitpin_authenticate by implication, but the description never names that sibling or contrasts the two explicitly.

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

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

The word 'expired' establishes the trigger condition clearly: call this when the access token has lapsed. It stops short of naming alternatives like bitpin_authenticate or bitpin_set_access_token, so the agent must infer the boundary from sibling names alone.

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 does disclose the important scope qualifier ('current session') and implies overwrite semantics via 'set or update', but says nothing about what happens if the token is invalid, whether it is verified against the API, or whether a prior token is discarded. Those gaps matter for a credential-mutating tool.

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

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

A single front-loaded sentence with the action first and the scope qualifier at the end. No filler, no restatement of the tool name beyond what is 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?

For a simple one-parameter tool with no output schema this is close to adequate, but a credential-setting tool should at least indicate whether the token is validated and what a caller should do on failure. The session-scoping statement is the main piece of substance present.

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

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

There is only one parameter and the schema already documents it fully at 100% coverage, including that it is a BitPin JWT/Bearer token. The description adds no format, prefix, or expiry guidance beyond the schema, so the baseline of 3 applies.

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

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

The description names a specific verb pair (set/update) and resource (BitPin Bearer access token), plus the scope (current session). The word 'Manually' hints at the distinction from bitpin_authenticate and bitpin_refresh_token, but it never names those siblings explicitly, so the differentiation is inferred rather than stated.

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?

'Manually set or update' implies the use case of supplying a token you already hold rather than running the auth flow, but the description never says when to prefer this over bitpin_authenticate or bitpin_refresh_token, nor any precondition (valid JWT, existing session). Usage is implied only.

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 behavioral burden. It states that success confirms the withdrawal, but omits important details such as permissions, failure behavior, retry/idempotency rules, and what happens if the OTP is invalid.

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

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

The description is two tight sentences with the core action front-loaded and no wasted text. It is appropriately sized for the tool.

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

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

The schema is fully documented and there is no output schema, but this is a financial mutation tool with no annotations. The description covers the success outcome yet leaves meaningful gaps around failure handling, retry behavior, and the two-OTP flow.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds useful context about the OTP being a 6-digit Authenticator code and/or SMS OTP, but it does not explain withdraw_id or the is_second_otp flow beyond what the schema already provides.

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

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

The description states a specific verb+resource: verify and confirm a pending withdrawal using an OTP. It is clearly distinguishable from sibling tools like create withdrawals or authenticate, though it does not explicitly name alternatives.

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 phrase 'pending withdrawal' implies this is used after a withdrawal has been created and an OTP is available, but there is no explicit when-to-use guidance, prerequisites, or mention of alternatives such as re-authentication.

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