Server Quality Checklist

Tool Scores

• get_dividendsA
  4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable operational context including a rate limit of 6 requests per minute and pagination behavior, and enumerates the entry fields returned.

  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 effectively convey the purpose, entry contents, filtering option, and rate limit. No superfluous words or 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?

  For a read-only list tool with rich annotations and full schema coverage, the description covers purpose, entry contents, filtering, and rate limit. Pagination details are left to the schema's cursor parameter, which is sufficient.

  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?

  All three parameters are fully described in the schema (100% coverage), including defaults and ranges. The description only restates the optional ticker filter and pagination, providing no additional parameter semantics 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 retrieves paginated dividend history, using the verb 'Retrieve' with a specific resource. This distinguishes it from sibling tools like get_transactions or get_reports.

  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 guidance on when to use this tool versus alternatives like get_transactions or get_reports. The context is implied by the resource name, but 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.

• get_historical_ordersA
  4/5.0
  Behavior4/5

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

  Annotations already declare the tool read-only and non-destructive. The description adds valuable behavioral details beyond annotations: cursor-based pagination, rate limit (6 req/1m), and the inclusion of fill details, taxes, and realised P&L.

  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, then concise details on filtering, pagination, and rate limit. Every clause earns its place; no repetition 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 read-only, paginated list tool with no output schema, the description covers the key functional aspects: what orders are included, optional filter, pagination mechanism, and rate limit. It is slightly lacking on the response shape, but the core use-case is well specified.

  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 covers 100% of parameters, so baseline is 3. The description adds context for ticker ('Optionally filter') and cursor ('cursor-based pagination'), but these are already indicated in the schema. It does not add substantial new meaning beyond what the schema 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?

  The description uses a specific verb ('Retrieve') and resource ('paginated history of all past orders') and details the content (fill details, taxes, realised P&L), clearly distinguishing it from sibling tools like get_pending_orders or get_order_by_id.

  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 context is clear: this tool is for historical orders with optional ticker filtering. However, it does not explicitly state when not to use it or mention alternatives like get_pending_orders for non-past orders, so guidelines are 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_open_positionsA
  4/5.0
  Behavior4/5

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

  The annotations already declare read-only, idempotent, and non-destructive behavior. The description adds a rate limit (1 req/s) and lists the exact fields returned, providing useful operational context beyond the annotations.

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

  Conciseness4/5

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

  The description is front-loaded with the main action and efficiently includes a useful field list and rate limit. It is slightly long due to the field enumeration, but every element contributes to understanding the tool's output.

  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 simple read-only tool with one optional parameter and no output schema, the description provides a thorough enumeration of the returned data, the filtering option, and the rate limit. This makes it effectively complete 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.

  Parameters3/5

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

  Schema coverage is 100%, and the schema already fully describes the optional 'ticker' parameter. The description only restates the optional filter capability without adding new semantic detail, so it stays at the baseline for high schema coverage.

  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 verb and resource ('Retrieve all open positions') and enumerates the specific data fields returned. This distinguishes it from sibling tools like get_pending_orders or get_historical_orders, which operate on different data.

  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 usage context is implied by the tool's name and description, but there is no explicit guidance on when to use this tool versus alternatives such as get_pending_orders or get_historical_orders. No exclusions or prerequisites are mentioned.

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

• get_transactionsA
  4.2/5.0
  Behavior4/5

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

  Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral details not in annotations: the result is paginated, each entry contains specific fields, and there is a rate limit of 6 req/1m. It does not fully explain cursor mechanics or default time scope, but it meaningfully supplements the 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?

  The description is extremely concise: two substantive sentences plus a one-sentence rate limit. It front-loads the action and resource, then lists return fields and a key constraint. Every sentence earns its place with no 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?

  The tool has no required parameters and no output schema, so the description's list of return fields helps fill that gap. It specifies the transaction types, pagination, and rate limit. It does not state the default time behavior (e.g., all history if no 'time' given) or ordering, but overall it is nearly complete for a well-annotated list 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?

  The schema description coverage is 100%, with clear descriptions for time, limit, and cursor. The description's mention of 'paginated' aligns with the cursor parameter but adds no additional semantic detail about the parameters themselves. Baseline 3 is appropriate since the schema carries the parameter 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 verb ('Retrieve') and resource ('paginated history of account transactions') and enumerates the transaction types (deposits, withdrawals, fees, transfers). This distinguishes it from sibling tools like get_historical_orders (orders) and get_account_summary (summary), making the 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: it is for retrieving transaction history, with examples of what counts as a transaction. It does not explicitly name alternatives or exclusions, but the resource specification ('account transactions') strongly implies when to use it versus other get_* siblings. This meets the 'clear context, no exclusions' bar.

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

• place_market_orderA
  4.2/5.0
  Behavior4/5

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

  Beyond annotations, the description adds a slippage warning, emphasizes non-idempotency ('duplicate calls create duplicate orders'), and discloses the rate limit. These behavioral traits are useful for an agent. No contradiction 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?

  Three sentences, front-loaded with the core purpose, and each sentence earns its place (execution type, quantity convention, warnings, rate limit). No redundancy or 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 complexity and lack of output schema, the description covers execution semantics, side effects (duplicate orders), and rate limits. It does not mention return format or error scenarios, but this is not critical given the schema and sibling context.

  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 has 100% coverage, including descriptions for ticker, quantity, and extendedHours. The description repeats the positive/negative quantity rule already present in the schema, adding little new semantic value.

  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 specifies a clear verb ('Place') and resource ('MARKET order'), and the phrase 'immediate execution at the next available price' differentiates it from sibling tools like place_limit_order, place_stop_order, and place_stop_limit_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 gives context for use via 'immediate execution' and warns about price slippage, but it does not explicitly state when to prefer this over limit/stop orders or list any alternatives. The quantity sign rule and rate limit also provide guidance.

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

• request_csv_reportA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate a non-read-only, non-idempotent, non-destructive operation. The description adds valuable behavioral context: the operation is asynchronous, returns a reportId, has a strict rate limit (1 req / 30s), and requires a follow-up poll via get_reports. No contradiction 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?

  The description is four sentences, each with a distinct function: purpose, data selection, return value/next step, and rate limit. No redundant language or filler. Front-loaded with the primary action.

  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 it's an async initiation with six parameters and no output schema, the description covers the core facets: what is generated, what data can be included, the return token (reportId), and the polling pathway. It omits potential error conditions or date-range inclusivity, but those are secondary for a request 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?

  The input schema has 100% description coverage for all six parameters, so the description need not add much. It does summarize the boolean flags as 'orders, dividends, transactions, interest', but the schema already explains each. The date-range parameters are self-explanatory from the schema. Thus it meets the baseline for high schema coverage.

  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+resource: 'Initiate async generation of a CSV report for a date range.' It clearly distinguishes itself from sibling tools by framing the operation as an initiation that returns a reportId, and explicitly points to get_reports for the follow-up, preventing confusion.

  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 states when to use this tool: to generate a CSV report with selectable data types (orders, dividends, transactions, interest). It also directs the agent to use get_reports for polling and download, which is a clear alternative/handoff. It doesn't explicitly say when not to use it, but the context and sibling reference provide sufficient guidance.

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

• get_order_by_idA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by mentioning the rate limit ('1 req / 1s') and reinforcing the pending-order scope, which informs the agent about potential non-return of fulfilled or cancelled orders. No contradiction 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?

  The description is two concise sentences plus a rate limit note. The first sentence front-loads the core action and resource. No filler or repetition. Every sentence earns its place.

  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 simplicity (one parameter, read-only, idempotent) and rich annotations, the description is complete. It explains what it retrieves, when to use it, and the rate limit. No output schema exists, but the description sufficiently implies the return of a single order object. No additional context seems necessary.

  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 schema already describes orderId as 'The unique numerical ID of the pending order,' and the description adds little beyond restating it as 'unique numerical ID.' The description does not provide additional syntactic or semantic detail 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 action ('Retrieve'), the resource ('a single pending order'), and the identifier ('unique numerical ID'). This distinguishes it from sibling tools like get_pending_orders (which likely lists multiple orders) and get_historical_orders (which likely retrieves non-pending orders). The title further 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 provides a clear use case: 'Useful for checking the status of a previously placed order.' This implies when to use it. However, it does not explicitly name alternatives (e.g., get_pending_orders for listing all pending orders) 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.

• cancel_orderA
  4.4/5.0
  Behavior5/5

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

  The description adds meaningful behavioral context beyond the annotations: cancellation is not guaranteed if being filled, a successful response means the request was accepted, and the rate limit is specified. This complements the destructiveHint and idempotentHint annotations without contradicting them.

  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?

  Three short sentences deliver the essential information with no redundancy. The description is front-loaded with the core purpose, followed by caveats and rate limit.

  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 cancel operation with no output schema, the description covers the key points: what it cancels, a critical failure caveat, and the meaning of a successful response. It could also address behavior for invalid or already-canceled orders, but that is not essential.

  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 the single parameter orderId, which already explains it as 'The unique numerical ID of the order to cancel.' The tool description merely says 'by its unique ID' without adding further detail, so the baseline 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 clearly states the verb and resource: 'Cancel an active, unfilled order by its unique ID.' It distinguishes this tool from siblings, all of which are either get or place operations, with no other cancel tool present.

  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 it (to cancel an active, unfilled order) and includes an important caveat about orders being filled, but it does not explicitly name alternatives or state 'use this instead of X.' Since there are no competing cancel tools, the guidance is adequate.

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

• place_stop_limit_orderA
  4.4/5.0
  Behavior4/5

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

  Annotations already indicate non-read-only, non-idempotent, and non-destructive behavior. The description adds valuable context: the trigger mechanism, rate limit ('1 req / 2s'), and 'Protects against slippage.' It also reinforces the non-idempotent nature. This goes beyond the annotations but doesn't cover edge cases like partial fills or order lifecycle.

  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 at five sentences, each serving a distinct purpose: mechanism, benefit, usage sign, idempotency, and rate limit. It is front-loaded with the core definition and does not waste 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 tool's moderate complexity (5 params, no output schema), the description covers the essential behavioral semantics, usage sign, rate limit, and slippage benefit. It does not explain the return value or edge cases, but this is not critical for tool selection and invocation. Overall, it is well-rounded.

  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?

  Input schema covers all five parameters with descriptions (100% coverage). The description adds extra meaning by explaining the interplay between stopPrice and limitPrice ('when LTP reaches stopPrice a limit order is placed at limitPrice'), which clarifies their roles beyond simple definitions. It also emphasizes the sign convention for quantity, though that is already in 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 opens with 'Place a STOP-LIMIT order' and clearly explains the trigger mechanism ('when the Last Traded Price reaches stopPrice a limit order is placed at limitPrice'), which distinguishes it from sibling order types like market, limit, and stop orders. It also adds the benefit 'Protects against slippage,' reinforcing its purpose.

  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 a clear context for use by stating the slippage protection benefit, and gives explicit instructions for buy vs sell using sign of quantity. However, it does not name alternative tools or explicitly state when not to use this order type, so it lacks explicit exclusions. This is solid but not top-tier.

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

• get_account_summaryA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is established. The description adds the rate limit (1 req / 5s) and details the returned fields, which are not present in annotations or 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 sentences long: the first front-loads the purpose and lists all relevant data categories, the second adds the rate limit. Every word contributes, with no redundancy 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?

  For a zero-parameter read-only tool with no output schema, this description is complete. It explains what the tool returns (account ID, currency, cash/investment metrics, total value) and gives the rate limit. No additional context is needed for an agent to invoke and interpret the result.

  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 provides no field details. The description compensates by explaining the output contents, even though it doesn't discuss parameters (there are none). Baseline for 0 params is 4, and this description meets 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 with a specific verb ('Retrieve') and resource ('full breakdown of the Trading 212 account'), and enumerates the exact data components. This distinguishes it from sibling tools that focus on positions, orders, or instruments.

  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 use when an account-level overview is needed, listing all account metrics. It does not explicitly exclude alternatives, but given the sibling tools (e.g., get_open_positions, get_pending_orders), the context is clear enough for an agent to select this tool for account-wide summaries.

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

• get_pending_ordersA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety. The description adds valuable behavioral context beyond annotations, including a rate limit (1 req / 5s) and the specific list of fields included in each order, enriching what the agent can expect.

  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 well-structured: a clear opening sentence on purpose, a compact list of included fields, and a final rate-limit note. Every sentence earns its place, with no redundancy 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?

  For a simple tool with no parameters and rich annotations, the description is fully complete. It explains what the tool returns, the filtering criteria, and an operational constraint (rate limit). No output schema is present, but the description fills that gap adequately.

  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 there is no parameter schema to document. The baseline for 0 params is 4, and the description compensates by thoroughly explaining the return content, which effectively substitutes for parameter 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 a specific verb ('Retrieve'), resource ('all currently active pending orders'), and scope ('those not yet filled, cancelled, or expired'), which distinguishes it from siblings like get_historical_orders and get_order_by_id. The exclusion of cancelled/expired orders adds precision.

  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 by defining what constitutes a pending order and explicitly excludes filled, cancelled, or expired orders. However, it does not explicitly name alternative tools or state when not to use it, but the context is evident enough for an agent to infer appropriate usage.

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

• place_stop_orderA
  4.6/5.0
  Behavior5/5

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

  Beyond annotations, the description discloses key behavioral traits: non-idempotency (NOT idempotent), rate limit (1 req / 2s), trigger based on Last Traded Price, and side semantics for quantity. It adds significant contextual value that annotations alone do not convey.

  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 four sentences, each carrying essential information: order type, trigger source, side handling, idempotency, and rate limit. It is front-loaded with the core purpose and avoids any unnecessary words or repetition.

  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 does not explain return values, which is a minor gap. However, it thoroughly covers the order logic, side semantics, rate limit, and idempotency, and the schema fully documents all parameters, so the tool can be correctly invoked with confidence.

  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 coverage is 100%, so baseline is 3. The description adds extra meaning by clarifying that stopPrice is triggered by Last Traded Price (beyond schema's 'Price that triggers the market order') and reinforces the buy/sell quantity convention. This added specificity justifies a 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 clearly states the action: "Place a STOP order that triggers a market order once the stop price is reached." It specifies the verb (Place), the resource (STOP order), and the unique behavior (triggered by Last Traded Price), distinguishing it from sibling order tools like market or limit.

  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 usage context: positive quantity for buying, negative for selling (stop-loss), and the trigger mechanism. However, it does not explicitly name alternatives or state when *not* to use this tool versus place_stop_limit_order, leaving some exclusions implicit.

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

• get_exchangesA
  4.7/5.0
  Behavior5/5

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

  Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses two non-obvious operational traits: data refreshes every 10 minutes and a strict rate limit of 1 request per 30 seconds. It also reveals the relationship between exchange IDs and instrument workingScheduleId, which is useful for downstream usage.

  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?

  Three sentences, each with a distinct purpose: what is returned, how IDs relate to instruments, and operational constraints. Front-loaded with the primary action and resource, no 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 simple parameterless tool with no output schema, the description fully covers what the agent needs to know: the data content, the key field mapping, data freshness, and rate limiting. It is complete and actionable.

  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 is empty. The description appropriately focuses on the return value rather than parameters, and since no parameters exist, there is nothing to explain. Baseline for 0 params 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 a specific verb ('Retrieve') and names the resource ('all accessible exchanges') with a clear scope. It further explains the data includes working schedules and the mapping to workingScheduleId, which distinguishes it from sibling tools like get_instruments.

  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 (to get exchange metadata and link to instruments) and provides operational constraints (data refresh every 10 minutes, rate limit 1 req/30s). It does not explicitly state when not to use it or mention alternatives, 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_instrumentsA
  4.7/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable behavioral context not captured by annotations: the data refresh interval (every 10 minutes) and a specific rate limit (1 req/50s), plus detailed field contents. This exceeds the minimum bar.

  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: the first states purpose and lists included fields, the second adds refresh and rate limit. Every word earns its place, and the most important information is front-loaded.

  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 simple read-only list with rich annotations, the description is complete: it covers what is returned (field list including ticker example), data freshness, and rate limiting. No output schema exists, but the description compensates by detailing the contents. This is sufficient 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 and the schema coverage is 100%, so there are no parameter semantics to document. Per rubric, 0 params baseline is 4. The description correctly omits parameter details.

  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 ('Retrieve') and resource ('complete list of instruments available for trading on Trading 212'), clearly distinguishing it from sibling tools that handle accounts, orders, or exchanges. The scope is well-defined.

  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 this tool is relevant (retrieving all tradable instruments) but does not explicitly mention alternatives or when-not-to-use. It lacks exclusions but the context is unambiguous given the sibling list.

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

• get_reportsA
  4.7/5.0
  Behavior5/5

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

  The description goes beyond the annotations by explaining the status values (Queued, Processing, Running, Finished, Failed, Canceled) and the downloadLink field, which is essential behavior. It also discloses the rate limit. This adds value beyond the readOnlyHint and destructiveHint already provided by 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?

  The description is two sentences, front-loaded with the key action and status expectations. It packs status values, download behavior, and rate limit efficiently with no wasted words.

  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 having no output schema, the description explains what the response contains (status and downloadLink) and the rate limit. This is sufficient for a zero-parameter list tool. No additional context seems necessary.

  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?

  There are no parameters, so the description doesn't need to explain any. The baseline for zero parameters is 4, and the description mentions the scope ('all requested CSV reports'), providing context that would otherwise be unclear, even though there are no interactive inputs.

  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 a list of requested CSV reports with their status, which is a specific verb (Retrieve), resource (CSV reports), and scope (list). It distinguishes itself from sibling tools like request_csv_report, which creates reports, and get_historical_orders, which deals with orders, not reports.

  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 check the status of requested reports and access download links. While it doesn't explicitly mention alternatives or exclusions, the sibling context and clarity of purpose imply the right usage. The rate limit is also a practical usage note.

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

• place_limit_orderA
  4.7/5.0
  Behavior5/5

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

  The description goes beyond annotations by explicitly warning about non-idempotency (duplicate orders) and disclosing the rate limit. It also explains execution price semantics, which are not included in annotations. This adds significant behavioral context beyond the structured fields.

  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 with a front-loaded purpose, followed by critical usage and behavioral notes. No redundant text; every sentence serves a purpose. It is appropriately concise for a tool with this complexity.

  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 moderate complexity (4 parameters, no output schema), the description covers purpose, execution behavior, non-idempotency, and rate limiting. It provides enough information for an agent to invoke the tool correctly and handle expectations, with no significant gaps.

  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 coverage is 100%, so the baseline is 3. The description adds value by clarifying how the sign of quantity maps to buy/sell and that execution occurs at limitPrice or better, which reinforces and expands schema descriptions. It does not introduce new parameter details but enhances 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 clearly states the tool's function: placing a limit order that executes at a specified price or better. It distinguishes this from sibling order types (market, stop, stop-limit) by the explicit 'LIMIT order' terminology and the price execution logic.

  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 operational guidance: sign of quantity determines buy vs. sell, and execution price bounds are specified. It does not explicitly name alternative tools for comparison, but the behavior is detailed enough for an agent to select this tool when a limit order is needed.

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