Server Quality Checklist

Tool Scores

• mb_get_tierB
  3.3/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden for behavioral disclosure. It only states the function without revealing whether the operation is read-only, requires authentication, or what happens on errors. The description adds no behavioral context 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.

  Conciseness5/5

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

  The description is two concise sentences: the first states the core purpose, the second adds relevant context. There is zero wasted wording and it is well-structured.

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

  Completeness3/5

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

  For a simple one-parameter getter with no output schema, the description provides the essential purpose. However, it does not describe the response format or any possible variations in tier levels, leaving the agent to infer the output structure. This is adequate but not thorough.

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

  Parameters3/5

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

  The schema fully describes the single parameter accountId with a simple description. The tool description does not add extra semantic detail beyond the schema, so the baseline score of 3 applies.

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

  Purpose4/5

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

  The description clearly states the verb 'Get' and the resource 'fee tier level of an account', making the purpose evident. It adds a useful detail about higher tiers having lower fees. However, it does not explicitly distinguish itself from the sibling mb_get_trading_fees, so it is not a perfect 5.

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

  Usage Guidelines3/5

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

  The description implies the usage scenario—checking an account's fee tier—but provides no explicit guidance on when to use this tool versus alternatives like mb_get_trading_fees or other account-related tools. There are no exclusions or alternative recommendations.

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

• mb_list_all_ordersA
  3.5/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure. It states the tool lists orders but does not disclose behaviors such as pagination, filtering capability, return format, or whether it includes all statuses. This is a significant gap for a tool with many optional filters.

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

  Conciseness5/5

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

  The description is two concise, front-loaded sentences. Every word adds value: 'List orders across ALL trading pairs' states the action and scope, and 'complete picture of trading activity' explains the use case. There is no redundancy or filler.

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

  Completeness3/5

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

  The description adequately conveys the core function but lacks important context. It does not mention that the tool supports optional filters (size, status, symbol, has_executions) or describe the return structure, which is especially relevant given there is no output schema and no annotations. The schema covers parameters, but the description could be more complete about behavior and results.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; it does not explain parameters like status, size, or has_executions. The schema already documents these adequately, so no penalty is applied, but there is no extra value from the description.

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

  Purpose5/5

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

  The description clearly states the tool lists orders across ALL trading pairs for an account, which is a specific verb+resource+scope. The emphasis on 'ALL trading pairs' and 'complete picture' distinguishes it from the sibling tool mb_list_orders, which likely has a narrower scope.

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

  Usage Guidelines3/5

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

  The description implies usage for getting a comprehensive view of trading activity, but it does not explicitly state when to use this tool versus alternatives like mb_list_orders, nor does it mention any exclusions or prerequisites. The guidance is only implied.

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

• mb_get_tradesA
  3.6/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It only says 'Get recent executed trades' without disclosing return format, ordering, pagination, rate limits, or any side effects. It implies read-only but doesn't confirm.

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

  Conciseness5/5

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

  The description is two short sentences with no redundancy, front-loading the core purpose and a use case.

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

  Completeness2/5

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

  With 5 parameters, no output schema, and no annotations, the description is too brief. It omits return value structure, behavior with parameters, and any limitations, making it incomplete for an agent to fully understand the tool.

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

  Parameters3/5

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

  Schema descriptions cover 100% of the 5 parameters, so the baseline is 3. The description adds little beyond the schema, mentioning 'trading pair' and 'recent' but not explaining timestamp or limit semantics.

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

  Purpose5/5

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

  The description clearly states the tool retrieves 'recent executed trades for a trading pair', using a specific verb and resource. This distinguishes it from sibling tools like mb_get_tickers (prices) and mb_get_candles (OHLCV).

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

  Usage Guidelines4/5

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

  It provides context by saying it is 'Useful for seeing market activity, recent prices and volumes', which implies when to use it. However, it does not explicitly mention alternatives or scenarios 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.

• mb_get_candlesA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description must fully disclose behavioral traits. It only states the basic purpose and lists resolutions; it does not disclose how 'from' and 'countback' interact, the ordering of returned candles, whether the current forming candle is included, or any rate limits. The read-only nature is implied by 'Get' but not explicitly stated, leaving significant gaps beyond the schema.

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

  Conciseness5/5

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

  The description is two concise sentences. The first sentence front-loads the primary purpose, and the second lists resolutions, which is a useful quick reference despite being redundant with the schema enum. No fluff; every sentence earns its place.

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

  Completeness3/5

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

  The tool is simple and the schema covers all parameters, but there is no output schema and the description does not explain the return structure or edge cases like countback overriding 'from'. It provides enough context to understand the basic use case but lacks detail on data ordering, limits, or potential pitfalls. Adequate but with clear gaps.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds minimal value beyond the schema; it restates the resolution enum but does not explain the relationship between 'from', 'to', and 'countback', which would be genuinely useful. Since the schema already documents each parameter, the description only marginally supplements it.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Get OHLCV candlestick data for charting and technical analysis.' This is a specific verb + resource combination that differentiates it from sibling tools like mb_get_trades or mb_get_orderbook, which serve different data needs.

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

  Usage Guidelines4/5

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

  The phrase 'for charting and technical analysis' gives clear context for when to use this tool. It does not explicitly name alternatives or exclusions, but the context is sufficient to infer that raw trades would use mb_get_trades and order book data would use mb_get_orderbook. No explicit exclusions are mentioned, hence a 4.

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

• mb_get_orderbookA
  3.7/5.0
  Behavior2/5

  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 states that the tool returns asks and bids with prices and quantities, which is essentially restating the tool's purpose. It does not disclose any additional behavioral traits such as default limit behavior, result ordering, pagination, or potential errors (e.g., invalid symbol). This is a significant gap for a read operation without annotation support.

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

  Conciseness5/5

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

  The description is a single, well-structured sentence that is concise and front-loaded with the key action and resource. Every word adds value, and there is no redundant information. It is 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.

  Completeness3/5

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

  The tool is simple with only two parameters, and the schema covers both fully. However, there is no output schema, so the description should ideally provide more detail about the return structure. It does mention asks/bids and prices/quantities, which gives a general idea, but it does not explain how the limit parameter affects the response or whether there is a default limit. Given the tool's simplicity, this is adequate but not complete.

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

  Parameters3/5

  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 both parameters (symbol and limit). The description adds some meaning by explaining that the trading pair is for a pair like BTC-BRL and that the return contains orders with prices and quantities, but it does not add semantics for the limit parameter beyond what the schema provides. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly identifies the tool as retrieving the order book (asks and bids) for a trading pair on Mercado Bitcoin. It uses a specific verb ('Get'), specifies the resource ('order book'), and differentiates it from sibling tools like mb_get_trades (which retrieves trades) and mb_get_tickers (which gets ticker info).

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

  Usage Guidelines4/5

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

  The description clearly implies when to use this tool: when you need current buy and sell orders with prices and quantities for a trading pair. It does not explicitly mention alternatives or when not to use it, but the context is clear enough that an agent can infer the appropriate use case.

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

• mb_get_tickersA
  3.9/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden. It discloses the return fields and the ability to query multiple symbols, but it does not mention authentication, rate limits, or the response container structure (e.g., object vs array). This 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.

  Conciseness5/5

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

  The description is a single sentence plus a list of return values, with no wasted words. It front-loads the action and is appropriately sized for the tool's simplicity.

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

  Completeness3/5

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

  The tool is simple, but the description does not specify how multiple symbols are mapped in the response (e.g., a single object vs a keyed map). Since there is no output schema, this is a notable gap that prevents a higher score.

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

  Parameters3/5

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

  The input schema fully describes the 'symbols' parameter with an example (BTC-BRL,ETH-BRL), giving 100% coverage. The description adds no additional parameter meaning, so the baseline of 3 applies.

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

  Purpose5/5

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

  The description uses the specific verb 'Get' with the resource 'current price tickers' and lists exact return fields (last price, bid, ask, high, low, open, 24h volume), clearly distinguishing it from sibling tools like mb_get_orderbook and mb_get_trades.

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

  Usage Guidelines4/5

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

  The description clearly states the tool provides current price tickers for one or more trading pairs, which establishes the context for when to use it. However, it does not explicitly mention alternatives or exclusions, so it stops short of a 5.

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

• mb_internal_transferA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses the confirmation requirement and the two-step preview/execute workflow, which is useful behavioral context. But it does not mention side effects (e.g., balance changes), prerequisites (e.g., sufficient funds), or what the preview returns, leaving gaps for a financial mutation tool.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the core purpose, and every sentence adds necessary information (scope and confirmation workflow). No filler or redundancy.

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

  Completeness3/5

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

  The description covers the essential purpose and usage flow, but it omits what the preview returns (no output schema exists to compensate) and does not mention any prerequisites or limitations. For a 5-parameter transaction tool with no annotations, this leaves the agent without full context on expected responses or preconditions.

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

  Parameters3/5

  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 the workflow context for the confirm parameter (preview vs. execute), but this largely mirrors the schema description 'Set true to execute after preview'. No additional meaning is given for accountId, symbol, amount, or recipientAccountId beyond the schema.

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

  Purpose5/5

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

  The description uses a specific verb ('Transfer') and names the exact resource ('asset between your own Mercado Bitcoin accounts (sub-wallets)'), clearly distinguishing this from trading tools like mb_place_order. The scope is unambiguous.

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

  Usage Guidelines4/5

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

  It provides explicit usage context: 'between your own accounts' clarifies when this tool is appropriate, and the two-step confirmation flow ('call first with confirm=false to preview, then confirm=true to execute') gives concrete instructions. However, it does not name alternatives or explicitly state when not to use it.

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

• mb_get_asset_networksA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description must convey behavioral traits. The 'List' verb implies a read-only operation, and the multi-network context is helpful, but it does not disclose output format, behavior for unknown assets, or any special handling. This leaves some ambiguity.

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

  Conciseness5/5

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

  The description consists of two concise sentences: the first states the purpose and the second provides a relevant example. There is no redundant information, and it is immediately clear what the tool does.

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

  Completeness4/5

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

  For a simple one-parameter read tool, the description adequately covers its purpose and usage context. However, it lacks details about the exact output structure or behavior for single-network assets, and with no annotations or output schema, a bit more specificity would improve completeness.

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

  Parameters3/5

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

  The input schema already fully describes the 'asset' parameter with examples (USDT, BTC), and the description echoes this without adding new semantic detail. With 100% schema coverage, the description adds no extra parameter information.

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

  Purpose5/5

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

  The description clearly states the action ('List') and the target ('available blockchain networks for a specific asset'), and distinguishes it from sibling tools by focusing on networks rather than prices or orders. The multi-network example reinforces the scope.

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

  Usage Guidelines4/5

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

  The description indicates when this tool is relevant, especially for multi-network assets like USDT, providing clear context. It does not explicitly name alternative tools or state exclusion criteria, but the context is sufficient for selection.

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

• mb_get_orderA
  4/5.0
  Behavior3/5

  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 states exactly what information is returned (fills, average price, fees, timestamps), giving insight into the tool's behavior, but it does not explicitly disclose read-only status, permissions, or rate limits. This is adequate but not exhaustive, meriting a 3.

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

  Conciseness5/5

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

  A single, information-dense sentence efficiently captures the tool's purpose and outputs with no redundancy. It is optimally concise.

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

  Completeness4/5

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

  The tool is straightforward with three fully described parameters and a clear statement of return contents. Although no output schema exists, the description sufficiently covers the essential information for an agent to select and use the tool, though it lacks explicit error-handling or pagination info.

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

  Parameters3/5

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

  The input schema provides 100% parameter descriptions, so the description doesn't need to elaborate. It adds minimal parameter-specific meaning ('specific order' references orderId), maintaining the baseline of 3.

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

  Purpose5/5

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

  The description uses the specific verb 'Get' and clearly identifies the resource ('detailed information about a specific order') and enriches it with output specifics (executions, average price, fees, timestamps). This distinguishes it from sibling tools like mb_list_orders or mb_get_trades.

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

  Usage Guidelines4/5

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

  The description conveys a clear use case: retrieving detailed information for a specific order rather than listing orders. However, it does not explicitly state when not to use it or name alternative tools, so it falls short of a 5 but provides clear context.

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

• mb_get_positionsA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses the read-only nature (listing positions) and the fields returned (average entry price, quantity, side). However, it does not mention authentication requirements, pagination, or any other behavioral nuances. This is adequate but not rich, matching a 3.

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

  Conciseness5/5

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

  The description is two sentences long, front-loaded with the core purpose, and contains no filler. Every sentence contributes value.

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

  Completeness4/5

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

  For a simple list tool with no output schema, the description covers the essential return fields and use case. It does not explain all possible behaviors (e.g., filtering behavior, result limits), but it is sufficiently complete for straightforward portfolio analysis. The schema handles parameter details, leaving the description to provide context and output expectations.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both parameters (symbols, accountId) already described. The tool description adds no extra meaning about these parameters; it only mentions output fields. Thus, baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'List open positions with average entry price, quantity and side.' The verb 'List' and specific resources (open positions, entry price, quantity, side) make it distinct from sibling tools like balances or trades.

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

  Usage Guidelines4/5

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

  The description provides context for when to use the tool ('Usful for portfolio analysis and P&L tracking') but does not explicitly mention alternatives or when not to use it. This is clear context without exclusions, so a 4 is appropriate.

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

• mb_get_symbolsA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the transparency burden. It discloses the default BRL filter, page size, and that the 'symbols' filter overrides pagination. It does not cover auth, errors, or exact response structure, but the key behaviors of a read-only list tool 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.

  Conciseness5/5

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

  The description is three sentences, front-loaded with the core purpose, then gives default behavior and scale. No redundant or wordy content.

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

  Completeness4/5

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

  With no output schema, the description compensates by naming the metadata fields and clarifying pagination/filtering. It does not provide a precise return structure or error conditions, but it is adequate for a straightforward list endpoint.

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

  Parameters3/5

  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 usage context (e.g., 'Use symbols for specific pairs or offset to paginate') but does not materially expand on the schema's own parameter descriptions.

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

  Purpose4/5

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

  The description uses a specific verb ('List') and identifies a clear resource ('available trading symbols/pairs on Mercado Bitcoin') while also naming returned metadata fields. However, it does not explicitly differentiate from sibling tools like mb_get_tickers, so it stops 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.

  Usage Guidelines4/5

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

  It clearly states the default behavior (BRL-only pairs, pages of 200) and provides direct guidance on when to use 'symbols' or 'offset'. It does not mention when to prefer an alternative tool, but the context is sufficient for correct invocation.

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

• mb_get_trading_feesA
  4/5.0
  Behavior3/5

  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 states the read operation ('Get') and the returned data, but does not disclose potential dependencies such as fee rates varying by account tier or error handling. The description is minimally adequate for a simple fetch.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the primary action. Every word earns its place, with no redundancy or unnecessary detail.

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

  Completeness4/5

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

  For a simple read tool with no output schema, the description states the return value (maker/taker rates) and provides a relevant use case. It lacks explicit distinction from mb_get_asset_fees and does not describe the output format, but it covers the essential information.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond the schema; it aligns 'symbol' with 'specific market' but does not explain the role of 'accountId' in determining fee rates.

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

  Purpose5/5

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

  The description clearly states 'Get maker and taker fee rates for a specific market', which is a specific verb+resource combination. It is distinct from sibling tools like mb_get_asset_fees by focusing on trading fees for a market rather than asset-level fees.

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

  Usage Guidelines4/5

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

  The description gives a clear usage context: 'Useful before placing orders to estimate costs.' This indicates when to use the tool, but it does not explicitly mention when not to use it or name alternative tools like mb_get_asset_fees.

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

• mb_list_ordersA
  4/5.0
  Behavior3/5

  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 discloses that results include executions/fills, but does not mention pagination, ordering, or rate limits. No contradictions with annotations.

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

  Conciseness5/5

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

  Two concise sentences, front-loaded with the main verb and scope. No wasted words.

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

  Completeness4/5

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

  The description covers the core purpose, filters, and return value (executions/fills). Given the moderate complexity and no output schema, it is mostly complete, though it lacks pagination or limit details.

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

  Parameters3/5

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

  Schema description coverage is 100% for all 9 parameters, so the baseline is 3. The description references status, side, and date range, but doesn't add meaning beyond the schema.

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

  Purpose5/5

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

  The description clearly states the tool lists orders for a specific trading pair, with a specified scope and filter options. It distinguishes itself from sibling mb_list_all_orders by emphasizing 'specific trading pair'.

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

  Usage Guidelines4/5

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

  The description implies usage for querying orders of a specific pair and mentions filter criteria, providing clear context. However, it does not explicitly name alternatives like mb_get_order or mb_list_all_orders, nor exclusions.

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

• mb_get_asset_feesA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It clearly signals a read-only 'Get' operation and adds context that results include minimum amounts and confirmation requirements per network. It does not cover error cases or output format, but for a simple query this is acceptable.

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

  Conciseness5/5

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

  Two sentences with no redundancy. The primary action is front-loaded, and every word contributes value.

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

  Completeness5/5

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

  Given the simple two-parameter schema and no output schema, the description is sufficiently complete. It covers the tool's purpose and includes key details about minimum amounts and confirmations without over-explaining.

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

  Parameters3/5

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

  Schema description coverage is 100% for both asset and network. The description adds only 'per network' context which aligns with the network parameter, but does not add substantial semantic meaning beyond what the schema already provides.

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

  Purpose5/5

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

  Description states 'Get deposit and withdrawal fees for a specific asset' with a specific verb and resource. It clearly distinguishes from sibling tools like mb_get_trading_fees and mb_get_asset_networks by focusing on deposit/withdrawal fees.

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

  Usage Guidelines3/5

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

  No explicit when-to-use or when-not-to-use guidance is provided, nor is there any mention of alternative sibling tools. Usage is implied by the description but not clearly differentiated from tools like mb_get_trading_fees.

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

• mb_list_accountsA
  4.3/5.0
  Behavior3/5

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

  Since no annotations are provided, the description carries the full burden. It discloses the return values (account IDs, names, currency, type) and the dependency on accountId, but it does not mention authentication requirements, rate limits, or potential side effects. This 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.

  Conciseness5/5

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

  The description is two concise sentences, front-loaded with the action and resource, and provides essential context without any filler or redundancy.

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

  Completeness5/5

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

  For a parameterless list tool with no output schema, the description adequately explains what it returns and why it is needed. The low complexity and clear return field list make it complete for the user's purposes.

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

  Parameters4/5

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

  The tool has zero parameters, and the schema coverage is 100%. The description adds useful context about what the result will be used for (accountId), but no parameter explanation is needed. Baseline for 0 parameters is 4.

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

  Purpose5/5

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

  The description uses the specific verb 'List' with the resource 'all your Mercado Bitcoin accounts (wallets)' and explicitly states the returned fields. It also notes that the accountId is needed for most other operations, clearly distinguishing this tool as the primary source of account identifiers among the siblings.

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

  Usage Guidelines4/5

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

  The description provides clear context: 'You need the accountId for most other operations' indicates when to use this tool (before other operations). However, it does not explicitly name alternatives or state when not to use it, so it stops short of full exclusion guidance.

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

• mb_cancel_orderA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description bears full responsibility for behavioral disclosure. It clearly indicates that cancellation requires confirmation and explains the preview-then-execute flow, which is essential for a destructive action. It does not mention error cases or permission requirements, but the core destructive behavior is transparently communicated.

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

  Conciseness5/5

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

  The description is exceptionally concise: two sentences, with the purpose front-loaded and the usage pattern immediately following. There is zero wasted wording, and every sentence adds critical information.

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

  Completeness4/5

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

  For a simple cancel-order tool with no output schema, the description covers the essential operational flow: preview and execute. It appropriately scopes to a single open order and specifies the confirmation requirement. It lacks details on return values or error conditions, but these are not critical given the tool's simplicity and the clear usage instructions.

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

  Parameters4/5

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

  The schema covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds meaningful semantics beyond the schema by explaining the purpose of the confirm parameter and the preview/execute workflow, which is not evident from the parameter description alone.

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

  Purpose5/5

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

  The description states the tool's function clearly with a specific verb and resource: 'Cancel a specific open order.' This distinguishes it from sibling tools like mb_cancel_all_orders by emphasizing a single order. The mention of confirmation adds a key characteristic.

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

  Usage Guidelines4/5

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

  The description provides explicit usage context by instructing a two-step process: call with confirm=false first to preview, then confirm=true to execute. This is clear guidance on how to use the tool safely, though it does not explicitly contrast with alternatives like cancel_all_orders or mention 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.

• mb_get_balancesA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses the returned fields, the default filtering of zero-balance assets, and the asset count (1900+). This goes beyond a bare 'gets balances' by explaining the data shape and a key behavioral nuance.

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

  Conciseness5/5

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

  The description is three sentences, front-loaded with the primary purpose, and every sentence adds value. There is no redundant phrasing or filler.

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

  Completeness4/5

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

  For a two-parameter getter with no output schema, the description covers the return fields, default behavior, and how to control the result set. It does not go into pagination or error handling, but these are not necessary for this simple tool given the sibling context and parameter coverage.

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

  Parameters4/5

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

  The schema already has 100% coverage with descriptions for both parameters. The description adds extra context: it tells users how to find accountId via mb_list_accounts, and it explains the practical effect of hide_zero with a concrete example. This enriches the schema's minimal descriptions.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Get asset balances for an account.' It further clarifies the scope by listing the fields (available, on_hold, total) and the behavior around zero balances. This clearly distinguishes it from sibling tools like mb_get_positions or mb_list_accounts.

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

  Usage Guidelines4/5

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

  The description gives clear context on the default behavior and how to change it ('most common use case', 'Set hide_zero=false'). It does not explicitly name alternatives or state when not to use this tool, but the context is sufficient for typical use cases.

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

• mb_place_orderA
  4.5/5.0
  Behavior4/5

  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 discloses the critical safety behavior: the two-step confirm flow (confirm=false returns preview, confirm=true executes). It also explains that cost auto-calculates quantity. While it doesn't cover permissions or error handling, it provides key behavioral context beyond a simple 'place order' statement.

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

  Conciseness5/5

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

  The description is well-organized with sections for confirmation flow, cost usage, and order type definitions. Every sentence provides value, and the structure makes complex information scannable. The length is appropriate for the tool's complexity.

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

  Completeness4/5

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

  For a tool with 10 parameters and four order types, the description covers the essential usage patterns and safety flow. It lacks details on preview output format and whether confirm=true must reuse the exact same parameters, but these are minor given schema descriptions of conditional requirements and the clear step-by-step confirmation instructions.

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

  Parameters5/5

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

  Schema coverage is 100%, but the description adds substantial meaning beyond schema definitions: explains 'cost' vs 'qty' trade-off, defines order types and which parameters are relevant (e.g., 'stoplimit triggers a limit order when stopPrice is reached'). This significantly enhances parameter understanding.

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

  Purpose5/5

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

  The description states the specific action: 'Place a buy or sell order on Mercado Bitcoin' and lists supported order types (market, limit, stoplimit, post-only). This clearly distinguishes it from sibling tools like mb_cancel_order or mb_get_order.

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

  Usage Guidelines4/5

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

  Provides explicit guidance on the two-step confirmation flow and explains when to use 'cost' instead of 'qty' for market buy orders. Also defines each order type with usage semantics. However, it does not explicitly mention when not to use this tool or direct users to alternative tools, but the context is clear.

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

• mb_statusA
  4.5/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries full responsibility. It clearly conveys a read-only 'check' operation and adds value by specifying exactly what aspects are reported (operation mode, security limits, authentication status, daily spending). This goes beyond a vague 'status' label, though it doesn't explicitly confirm absence of side effects or permission requirements.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that states the primary action first, then lists concrete items covered. Every phrase earns its place, with no wasted words or filler.

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

  Completeness5/5

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

  Given the low complexity (no parameters, no output schema), the description is fully complete. It tells the agent what the tool does and gives an outline of the return content, which is sufficient for selection and use.

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

  Parameters4/5

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

  The tool has zero parameters, and schema coverage is 100%, so there are no parameter details to explain. The description compensates by outlining the data returned, which gives the agent a sense of the output without needing a formal schema.

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

  Purpose5/5

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

  The description uses a specific verb ('Check') and clearly identifies the resource ('configuration and health of the Mercado Bitcoin MCP server'). It visibly distinguishes itself from all sibling tools, which focus on market data, account operations, or order management, while this tool is exclusively for server status.

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

  Usage Guidelines4/5

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

  The description gives clear context: use this to check server configuration and health. It implicitly targets users needing a high-level server overview. No explicit alternative is named, but there are no similar sibling tools, so the context is sufficient for an appropriate use case.

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

• mb_cancel_all_ordersA
  4.7/5.0
  Behavior5/5

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

  With no annotations provided, the description bears full responsibility for behavioral disclosure. It explicitly warns 'DANGEROUS', notes that multiple orders are cancelled at once, requires confirmation, and specifies the two-step preview/execute pattern. This effectively conveys the destructive nature and necessary safeguards.

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

  Conciseness5/5

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

  The description is concise: three sentences with no filler. It front-loads the core purpose, then adds a danger warning, then gives a clear usage instruction. Every sentence contributes distinct value, making it well-structured and easy to parse quickly.

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

  Completeness5/5

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

  Given the tool's complexity as a dangerous bulk operation, the description covers purpose, danger, and the exact confirmation workflow. It lacks an output schema, but the description does not need to explain return values since none are provided. It is sufficiently complete for an agent to select and invoke the tool correctly.

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

  Parameters4/5

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

  The input schema already provides descriptions for all three parameters (100% coverage), establishing a baseline of 3. The description adds meaningful context by explaining how to use the confirm parameter ('Call with confirm=false first to preview, then confirm=true to execute'), and by mentioning the optional symbol filter, which aligns with and reinforces the schema descriptions.

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

  Purpose5/5

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

  The description clearly states the tool cancels ALL open orders, with an optional symbol filter. It uses a specific verb ('Cancel') and resource ('ALL open orders'), and the scope is distinct from the sibling tool mb_cancel_order, which cancels a single order.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use the tool: to cancel all open orders, possibly filtered by symbol. It also outlines a preview-then-execute workflow with confirm=false and confirm=true. However, it does not explicitly contrast with mb_cancel_order or list exclusions, so it falls short of a full 5.

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