Server Quality Checklist

Tool Scores

• get_depositsC
  2.8/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 mentions the optional symbol filter but does not state what happens when symbol is omitted, whether the result is sorted, or any other behavior. It also fails to explicitly confirm it is a read-only operation, though that is implied by 'history'.

  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 and front-loaded, consisting of two short clauses that immediately convey the tool's purpose and the optional parameter. Every word adds value, with no wasted or redundant phrasing.

  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?

  Given the tool is simple (one optional parameter, no output schema) and the description is brief, it should still provide enough context for the agent to know when and how to use it. However, it lacks any guidance on use cases, alternatives, or expected behavior, which is especially problematic given the many sibling tools. The description meets the bare minimum but is not complete for effective selection.

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

  Parameters2/5

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

  The schema description coverage is 0%, so the description must compensate. It does mention that the 'symbol' parameter is an optional filter, but it does not clarify what constitutes a valid symbol (e.g., crypto ticker, fiat code, case sensitivity) or any default behavior. This leaves significant ambiguity for the agent.

  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 indicates the tool retrieves deposit history for both fiat (EUR) and crypto, which distinguishes it from sibling tools like get_withdrawals. It does not explicitly use a verb like 'list' or 'get', but 'Deposit history' strongly implies retrieval, making the purpose clear.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives like get_withdrawals or get_transactions. The description only states what it does, not when it is preferred or when symbol filtering is appropriate. The large sibling list makes this omission noticeable.

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

• get_transactionsA
  3.7/5.0
  Behavior4/5

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

  With no annotations, the description discloses important behavioral context: data is locally stored, populated via import_transactions, ordered newest first, and limited to 100 rows by default. It also notes that filters narrow results. It does not mention response format or error handling, but the core behaviors are covered.

  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 concise sentences, front-loaded with the core purpose, then adding ordering/default limit, and finally filter combination advice. Every sentence provides value with no redundancy or filler.

  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?

  Given the lack of an output schema and annotations, the description should clarify what the returned transaction list contains or how to paginate. It does not describe the response structure or the semantics of from/to, leaving the agent to infer important details for a tool with five parameters.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description only mentions currency and type by name with the advice to combine them. It does not explain the meaning of 'from' or 'to', nor the limit parameter beyond the default. The phrase 'Without filters returns the most recent 100 rows' implies limit behavior but lacks concrete detail.

  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 'Query' and identifies the resource as 'locally-stored transaction history', explicitly noting it is populated via import_transactions. It clearly distinguishes from sibling tools like get_trades or get_withdrawals by focusing on the full transaction history.

  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 gives useful tips like 'Combine currency + type to narrow' and explains the default behavior without filters. However, it does not explicitly state when to use this tool versus alternatives, so usage guidance is implied rather than directly contrasted with siblings.

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

• get_withdrawalsA
  3.9/5.0
  Behavior2/5

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

  With no annotations, the description carries full responsibility for behavioral disclosure. It only states the resource scope and optional filter, but omits details such as response format, pagination, whether pending/completed withdrawals are included, or any access requirements. This is a minimal disclosure for a getter 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 short, front-loaded clauses: 'Withdrawal history' first, then scope and filter. Every word earns its place; no fluff 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?

  For a simple tool with one optional parameter and no output schema, the description is adequate for selection and invocation but still leaves gaps about the returned data structure and any caveats. An agent would know what the tool does but not exactly what to expect in the response.

  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?

  Schema description coverage is 0%, so the description must compensate. It does: 'Optionally filter by symbol' explains the sole parameter's purpose and optionality, and the mention of 'fiat (EUR) and crypto' hints at acceptable symbol types. It lacks examples or validation details, but adds meaningful semantics beyond the bare 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's function: 'Withdrawal history' with scope 'fiat (EUR) and crypto' and an optional filter. This distinguishes it from sibling tools like get_deposits and get_transactions by specifying the exact resource (withdrawals) and its subtypes.

  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 when to use the tool: when needing withdrawal history, covering both fiat and crypto. It does not explicitly contrast with alternatives like get_deposits or get_transactions, but the context is clear enough for an agent to select it appropriately.

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

• get_open_ordersA
  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 burden of behavioral disclosure. It reveals the unfilled-order state and the all-markets default when no filter is provided, but does not cover potential edge cases like empty results, rate limits, or authentication. It provides some transparency but leaves room for more detail.

  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, and free of filler. Each sentence adds specific information: the definition and the filter behavior.

  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-only tool with one optional parameter and no output schema, the description explains what it returns and the key filter behavior. It lacks explicit mention of read-only nature or return format, but these are fairly obvious and the description is adequate for the tool's simplicity.

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

  Parameters3/5

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

  The schema coverage is 0%, so the description must compensate for the undocumented 'market' parameter. It explains that market is a filter and its omission yields all markets, which adds meaning beyond the raw schema. However, it does not specify the expected format (e.g., market ID or symbol), so it only partially compensates.

  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 defines the tool as returning open orders that are placed but not yet filled, and adds the key behavior of optionally filtering by market. This distinguishes it from siblings like get_trades, which likely returns completed 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?

  It states that omitting the market filter returns open orders across every market, giving clear context on when to use the filter. It does not explicitly mention alternatives or exclusions, but the behavior is clear enough for simple selection.

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

• get_pnlA
  4.1/5.0
  Behavior5/5

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

  With no annotations provided, the description carries full burden and does an excellent job: it discloses the average-cost method, data source priority (local vs live API), and specific limitations (fully-sold positions hidden without local data, only non-zero balances visible otherwise). This goes well beyond minimal expectations.

  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 appropriately sized for the tool's complexity. It front-loads the core purpose, then explains methodology, outputs, and data-source nuances without redundancy. Every sentence contributes useful 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?

  The description thoroughly covers computation method, outputs, and data-source behavior, which is especially important given no output schema or annotations. However, the unexplained 'quote' parameter is a gap that prevents a perfect score.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not mention the 'quote' parameter at all. With only one parameter, the description should at least clarify its purpose (e.g., filter by quote currency). This is a significant omission.

  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 computes profit & loss per asset using the average-cost method and lists the specific outputs. It distinguishes itself from siblings by explaining its methodology and data source, making its purpose 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?

  The description provides clear context on when to use this tool: when you need per-asset P&L with cost basis, including realized P&L from fully-sold positions if local data is imported. It references sibling tool import_transactions as a prerequisite for complete coverage, though it does not explicitly name alternatives to avoid.

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

• get_tradesA
  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 burden and does well by stating the return fields and ordering. It doesn't explain limit behavior or pagination, but for a simple read-only tool 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, front-loaded with the core action and resource, 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?

  For a simple getter with no output schema, it covers purpose, ordering, and fields. Lacks detail on limit/pagination, but overall adequate for selection and invocation.

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

  Parameters2/5

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

  Schema description coverage is 0%, so description should explain both parameters. It addresses 'market' implicitly but never explains 'limit' (e.g., that it controls the number of trades returned). This is a notable gap.

  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 returns your own filled trades for a specific market, with ordering (newest first) and data fields. 'Filled trades' distinguishes it from sibling tools like open orders.

  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 clear context (own filled trades on a specific market) but doesn't explicitly mention alternatives or exclusions. The distinction from open orders is implied though not stated directly.

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

• get_trendA
  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 transparently discloses the conditional behavior (P&L only when transactions are imported) and the full set of returned metrics. It does not mention error handling or side effects, but for a read-only getter, the disclosure is effective.

  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 purpose, and every phrase adds value. The first sentence covers the core trend data; the second adds the conditional P&L without redundancy.

  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?

  Given the tool's simplicity (one parameter, no output schema), the description covers the main output contents and the conditional logic. The only notable gap is the lack of parameter format guidance, but overall it is sufficiently complete for an agent to invoke it.

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

  Parameters2/5

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

  Schema coverage is 0% and the description does not define the 'market' parameter beyond using it as a subject. It does not specify expected format (e.g., 'BTC-USD' vs 'BTCUSD') or examples, so the description insufficiently compensates for the lack of schema documentation.

  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: a multi-period trend digest for a market with specific percentage changes and high/low values. It also adds a conditional P&L comparison feature. This distinguishes it from siblings like get_ticker (single price) and get_candles (raw data).

  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 on what data the tool returns, making the use case apparent (e.g., obtain trend percentages over multiple periods). However, it does not explicitly name alternatives or exclusion conditions, so it falls 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.

• get_tickerA
  4.2/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 disclose behavioral traits. It states the endpoint is public, which indicates no authentication is needed, and lists the return data. However, it doesn't mention error handling, rate limits, or how 'live' the data is. For a simple read-only ticker, this is adequate but leaves some gaps.

  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 with no wasted words. The first sentence immediately communicates the core purpose and scope, the second lists return fields and public status. It's well-structured and front-loaded.

  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 purpose, parameter format, return fields, and public accessibility. It lacks explicit error behavior and data freshness details, but for a lightweight public endpoint with a single parameter and no output schema, it is nearly complete. The missing items are non-critical for this simple tool.

  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?

  With 0% schema description coverage, the description compensates by providing an example ('BTC-EUR') that clarifies the expected format for 'market'. This adds meaning beyond the bare schema, but it doesn't enumerate valid values or define timezone behavior. Still, for a single parameter, it is quite helpful.

  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 specific function: providing a live 24-hour ticker for a single market. It names the return fields (open/high/low/last/volume/bid/ask) and gives a concrete example, distinguishing it from sibling tools like get_markets (list of markets) or get_candles (historical data).

  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 clear usage context: this is the tool for a single market's current 24-hour ticker. It implies a real-time use case and mentions the market format (e.g., 'BTC-EUR'). While it doesn't explicitly exclude alternatives, the context is clear enough for an agent to decide when to use it.

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

• get_portfolio_valueA
  4.3/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 and it does well: it explains the calculation (sum of available + inOrder, multiplied by latest price), the default quote currency, and the handling of assets without a direct market chain ('unpriced'). This gives clear insight into the tool's behavior.

  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, tightly packed with relevant details: calculation logic, default, and edge-case handling. No unnecessary words or repetition of schema 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?

  Despite lacking an output schema, the description explains the return behavior in terms of the total and an 'unpriced' list. It covers the essential aspects of the tool, though it could be slightly more explicit about the output structure or potential errors.

  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?

  The input schema has one parameter 'quote' with zero description coverage. The description fully compensates by explaining that it is the quote currency and defaults to EUR, providing all necessary semantic information for the parameter.

  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 with a specific verb ('Compute') and resource ('total portfolio value'). It explains the calculation method and handles edge cases, distinguishing it from sibling tools like get_balance (raw balances) and get_ticker (prices alone).

  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 tool is for computing total portfolio value, but it does not explicitly state when to use it over alternatives like get_balance or get_ticker. No direct comparison or exclusions are provided, so the usage context is implied rather than explicit.

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

• get_candlesA
  4.4/5.0
  Behavior5/5

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

  With no annotations provided, the description fully carries the transparency burden. It discloses defaults (interval=1d, limit=100), ordering (newest-first), and row structure (timestamp, OHLCV fields), going well beyond the schema. It clearly implies a read-only operation with no destructive effects.

  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 concise sentences, front-loaded with the core purpose and followed by essential usage defaults and output format. Every sentence adds value with no redundancy 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 simple read-only tool with no annotations and no output schema, the description covers purpose, usage, defaults, ordering, and return format well. The only gap is the ambiguous 'custom time window' claim, since the schema offers no explicit start/end parameters, which could confuse users.

  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 has 0% description coverage, so the description must compensate. It adds defaults for interval and limit and gives an example market value, but it does not fully explain each parameter's meaning or how the 'custom time window' maps to the available parameters (interval, limit). This partial coverage merits a middle score.

  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 returns 'Historical OHLCV candles' with a market example, which is specific and distinguishes it from siblings like get_ticker or get_trades. The phrase 'Use this for trend analysis, charts, or computing technical indicators' further clarifies its intended role.

  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 explicitly says 'Use this for trend analysis, charts, or computing technical indicators over a custom time window,' providing clear context for when to choose this tool. However, it does not name alternatives or state when not to use it, so it falls short of the highest bar.

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

• get_marketsA
  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 transparency burden. It discloses the non-obvious default filtering behavior and how to disable it. It does not mention output format or error handling, but for a simple list operation, this is adequate and adds value beyond the tool name.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the primary action, and every clause provides meaningful information. It is concise and well-structured with 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?

  Given the simplicity of this listing tool and the absence of an output schema, the description covers the key behavioral aspects: what it lists and how to modify the default filters. The lack of return structure detail is acceptable for this use case.

  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 provides no descriptions and 0% coverage, so the description must compensate. It explains that quote and status are filters and that null disables them, which adds meaning beyond the bare schema. The implied default values (EUR and trading) are also conveyed, though not explicitly stated as parameter defaults.

  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 markets available on Bitvavo, using the specific verb 'List' and a distinct resource. It also notes the default filter behavior, which further clarifies its scope and differentiates it from sibling tools like get_ticker or get_candles.

  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 on default behavior (EUR-quoted, trading markets) and explains how to adjust filters by passing null. While it does not explicitly reference alternatives, no sibling tool performs this exact function, so the guidance is sufficient for usage.

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

• import_transactionsA
  4.4/5.0
  Behavior4/5

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

  With no annotations to rely on, the description carries the full burden and does well. It discloses that the tool writes to a local SQLite store, is idempotent (updates existing rows in place), and affects downstream queries (get_pnl). It clearly indicates the tool has side effects and explains the update behavior, which is valuable 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 three sentences, each earning its place: the first states the action, the second clarifies idempotency and update behavior, and the third explains the downstream impact. It is front-loaded, concise, and free of fluff.

  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?

  Given the tool's simplicity (one parameter, no output schema, no annotations), the description is quite complete. It covers the action, side effects, idempotency, and relationship to get_pnl. It does not specify return values or error handling, but with no output schema, that is not strictly required. It could be improved by mentioning what happens on invalid CSV files, but it is otherwise comprehensive.

  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 has only one parameter, file_path, with 0% description coverage in the schema. The description compensates by specifying that the expected file is a 'Bitvavo CSV transaction export,' giving the parameter context and expected format. While it doesn't detail full schema or error handling, it adds meaning beyond just the parameter name and type.

  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 specific action: 'Import a Bitvavo CSV transaction export into the local SQLite store.' The verb 'import' and the resource (CSV export) are explicit, and it distinguishes itself from the read-only sibling tools (get_balance, get_pnl, etc.) by being a write/import operation.

  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 on when to use this tool: it mentions that after import, get_pnl uses these records as the canonical source, implying users should import before querying PnL. It also explains idempotency and update behavior, giving practical usage guidance. However, it does not explicitly name alternatives or say 'when not to use,' but with no alternative import tools among siblings, the context is sufficient.

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

• get_balanceA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description discloses key behaviors: it lists what each entry contains and explains that zero balances are filtered out unless include_zero=true. It does not mention rate limits or authentication, but for a read-only list tool, the behavior is adequately transparent.

  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 purpose and followed by output detail and parameter behavior. Every sentence adds value without any 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?

  Despite lacking an output schema, the description specifies the output structure (symbol, available, inOrder) and the behavior of the only parameter. For a simple list tool, this is sufficient for an agent to invoke and interpret results 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 schema has one parameter, include_zero, with no description. The description compensates by explaining its effect: zero balances are filtered out unless include_zero=true. This adds meaning beyond the bare boolean type.

  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 'List balances per asset on the Bitvavo account,' specifying the resource and scope. It also details the output fields (symbol, available, inOrder), distinguishing it from sibling tools like get_portfolio_value or get_ticker.

  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 this tool: to retrieve account balances per asset. However, it does not explicitly mention alternatives or when not to use it, so it lacks explicit exclusion guidance.

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

• pingA
  4.7/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses behavior: it calls two endpoints (public time and private account), confirms API key/secret validity, and returns three specific data points (server time, fee tier, rate-limit budget). This goes well beyond a simple 'ping' and gives the agent a clear picture of side effects and response content.

  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 succinct sentences, front-loaded with the primary purpose. No redundant wording; each sentence adds unique value (purpose, method, outputs).

  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 zero-parameter tool with no output schema or annotations, the description is remarkably complete. It explains what the tool does, how it works, and what it returns, covering all necessary context for an agent to invoke and interpret results.

  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, so the schema carries no semantic burden. The description adds context about what the tool does (endpoint calls, returned values), but since there are no parameters to explain, the baseline 4 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: 'Verify the connection and credentials against Bitvavo.' This is a specific verb (verify) with a resource (Bitvavo connection/credentials), and it is clearly distinct from sibling tools that retrieve market or account data.

  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 the use case: check connectivity and credential validity before relying on other tools. It does not explicitly contrast with alternatives, but the sibling tools are all data-retrieval functions, making the diagnostic purpose evident.

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