Server Quality Checklist

Tool Scores

• ig_create_working_orderD
  1.7/5.0
  Behavior1/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 but offers none. 'Create a working order' doesn't indicate whether this is a high-risk financial transaction, what permissions are required, whether it's idempotent, what happens on failure, or what the expected response format might be. For a trading tool with significant financial implications, this lack of behavioral context is critically inadequate.

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

  Conciseness2/5

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

  While technically concise with just three words, this is under-specification rather than effective conciseness. The description fails to provide essential context that would help an agent understand and use the tool correctly. Every sentence should earn its place, but this single phrase doesn't provide enough value to justify its existence as a helpful description.

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

  Completeness1/5

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

  Given the complexity of a financial trading tool with 13 parameters (8 required), no annotations, and no output schema, the description is completely inadequate. It doesn't explain what a 'working order' is, how it differs from regular positions, what the tool returns, or any behavioral characteristics. For a tool with this level of complexity and potential risk, the description fails to provide the necessary context for safe and effective use.

  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%, meaning all 13 parameters are documented in the input schema itself. The description adds no additional parameter information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.

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

  Purpose2/5

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

  The description 'Create a working order' is a tautology that essentially restates the tool name 'ig_create_working_order'. While it indicates this is a creation operation, it doesn't specify what a 'working order' is in this financial trading context or distinguish it from similar tools like 'ig_create_position'. The purpose remains vague without domain-specific clarification.

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

  Usage Guidelines1/5

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

  The description provides absolutely no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, appropriate contexts, or comparison to sibling tools like 'ig_create_position' or 'ig_delete_working_order'. An agent would have no indication of when this specific order creation tool should be selected over other trading operations.

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

• ig_create_watchlistC
  2.3/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Create a new watchlist', implying a write operation, but does not disclose any behavioral traits such as required permissions, whether the operation is idempotent, rate limits, or what happens on success/failure. The description is minimal and fails to provide necessary context for safe and effective use.

  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 with a single sentence 'Create a new watchlist'. It is front-loaded and wastes no words, making it easy to parse. However, this conciseness comes at the cost of completeness, as noted in other dimensions.

  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 complexity of a creation tool in a trading platform, with no annotations and no output schema, the description is incomplete. It does not explain what a watchlist is, its purpose, expected return values, or error conditions. The minimal description fails to provide sufficient context for an AI agent to use the tool effectively, especially compared to more detailed sibling tools.

  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, with clear documentation for 'name' and 'epics' parameters. The description does not add any semantic meaning beyond what the schema provides, as it mentions no parameters. According to the rules, with high schema coverage (>80%), the baseline score is 3, even without parameter info in the description.

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

  Purpose2/5

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

  The description 'Create a new watchlist' is a tautology that merely restates the tool name 'ig_create_watchlist'. It specifies the verb 'create' and resource 'watchlist', but lacks any detail about what a watchlist is or its purpose in the context of the IG trading platform. It does not differentiate from sibling tools like 'ig_get_watchlists' or 'ig_get_watchlist', which are related but distinct operations.

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

  Usage Guidelines1/5

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

  The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., authentication via 'ig_login'), exclusions, or comparisons to sibling tools such as 'ig_add_to_watchlist' for modifying existing watchlists. Without any context, an AI agent cannot determine appropriate usage scenarios.

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

• ig_get_account_activityC
  2.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get' implies a read-only operation, it doesn't specify authentication requirements, rate limits, pagination behavior (beyond the 'pageSize' parameter), or what 'activity history' entails (e.g., logs, transactions). For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior and constraints.

  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 with just four words, front-loading the core purpose without any fluff. Every word ('Get account activity history') directly contributes to understanding the tool's function, making it efficient and easy to parse. This minimalism is effective for basic clarity, though it sacrifices depth.

  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 complexity of retrieving account activity (which could involve sensitive data or pagination) and the absence of both annotations and an output schema, the description is insufficient. It doesn't explain what 'activity history' includes, how results are structured, or any behavioral aspects like error handling. For a tool with no structured metadata, more descriptive context is needed to ensure proper usage.

  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, clearly documenting all four parameters (detailed, from, pageSize, to) with their types and purposes. The description adds no additional parameter semantics beyond what's in the schema, such as explaining how 'detailed' affects the output or date format nuances. With high schema coverage, a baseline score of 3 is appropriate as the schema does the heavy lifting.

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

  Purpose3/5

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

  The description 'Get account activity history' clearly states the verb 'Get' and resource 'account activity history', which is specific enough to understand the basic function. However, it doesn't distinguish this tool from potential siblings like 'ig_get_accounts' or 'ig_get_positions' that might also retrieve account-related information, leaving ambiguity about what makes this tool unique.

  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?

  The description provides no guidance on when to use this tool versus alternatives. With siblings like 'ig_get_accounts' and 'ig_get_positions' that might overlap in retrieving account data, there's no indication of context, prerequisites, or exclusions. This lack of differentiation could lead to confusion for an AI agent selecting between similar tools.

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

• ig_search_marketsC
  2.7/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a search operation, implying it's likely read-only and non-destructive, but doesn't confirm this explicitly. It also omits critical details like authentication requirements (though siblings suggest login might be needed), rate limits, pagination behavior, or what the search returns (e.g., a list of market IDs or names). For a tool with zero annotation coverage, this is inadequate.

  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—just four words—and front-loaded with the core action ('Search for tradeable markets'). There's no wasted language or redundancy, making it efficient for quick comprehension, though this conciseness comes at the cost of detail in other dimensions.

  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 complexity (a search tool in a trading context with many siblings), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'tradeable markets' entails, how results are returned, or any behavioral traits. While the schema covers the single parameter well, the overall context for effective tool use is insufficient, especially compared to siblings that might overlap in functionality.

  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, with the 'searchTerm' parameter well-documented in the schema itself (e.g., examples like 'Oil', 'EUR/USD'). The description adds no additional parameter information beyond implying a search functionality, which the schema already covers. According to the rules, with high schema coverage (>80%), the baseline is 3 even without param details in the description.

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

  Purpose3/5

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

  The description 'Search for tradeable markets' clearly states the action (search) and target (tradeable markets), which is better than a tautology. However, it lacks specificity about what 'tradeable markets' means in this context (e.g., financial instruments, commodities, currencies) and doesn't distinguish it from potential sibling tools like 'ig_get_market_details' or 'ig_get_historical_prices', which might also involve market-related queries.

  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?

  The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing to be logged in), comparison to siblings like 'ig_get_market_details' (which might fetch specific market data) or 'ig_get_watchlist' (which might list saved markets), or any context about typical use cases (e.g., finding markets to trade). This leaves the agent with minimal direction.

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

• ig_add_to_watchlistC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action is 'Add', implying a mutation, but does not disclose any behavioral traits such as permissions required, rate limits, error conditions, or what happens if the epic already exists in the watchlist. This leaves significant gaps for an AI agent.

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

  Conciseness5/5

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

  The description is a single, concise sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded and efficient, making it easy to understand at a glance.

  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 a mutation operation (adding to a watchlist) with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects like success/failure responses, side effects, or dependencies, which are crucial for proper tool invocation in this 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 has 100% description coverage, with clear definitions for 'epic' and 'watchlistId'. The description does not add any additional meaning beyond what the schema provides, such as format examples or constraints. Since schema coverage is high, the baseline score of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the action ('Add') and the target ('an epic to a watchlist'), which is specific and unambiguous. However, it does not differentiate this tool from potential sibling tools like 'ig_create_watchlist' or 'ig_get_watchlist', which might handle watchlist operations differently, so it lacks sibling distinction.

  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?

  The description provides no guidance on when to use this tool versus alternatives. For example, it does not specify if this is for adding new epics only, updating existing ones, or if there are prerequisites like having a watchlist created first. No context or exclusions are mentioned.

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

• ig_close_positionC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Close') which implies a destructive mutation, but doesn't mention consequences (e.g., financial settlement, irreversible action), permissions required, rate limits, or what happens after closing. This leaves significant behavioral gaps for a mutation tool.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that states the core action without unnecessary words. It's appropriately sized for a simple tool with one parameter and gets straight to the point.

  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?

  For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'closing' entails (e.g., selling assets, settling trades), potential side effects, error conditions, or return values. Given the complexity of financial position management, this leaves too many unanswered questions.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents the single parameter 'dealId' adequately. The description doesn't add any additional meaning about the parameter beyond what's in the schema (e.g., format examples, where to find deal IDs). Baseline 3 is appropriate when the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the action ('Close') and resource ('an open position'), making the purpose immediately understandable. However, it doesn't differentiate from the sibling tool 'ig_close_all_positions' or specify what type of position (e.g., trading position) is being closed, which prevents a perfect score.

  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?

  The description provides no guidance on when to use this tool versus alternatives like 'ig_close_all_positions' or 'ig_update_position'. It lacks context about prerequisites (e.g., needing an open position) or typical scenarios for closing a single position versus all positions.

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

• ig_create_positionC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. While 'Create' implies a write/mutation operation, the description doesn't address critical aspects like authentication requirements, rate limits, whether this is a live trading action with financial consequences, error conditions, or what happens on success/failure. This is inadequate for a financial trading 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 maximally concise - a single clear sentence with zero wasted words. It's front-loaded with the essential information and doesn't include any unnecessary elaboration.

  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?

  For a complex financial trading tool with 12 parameters (7 required) and no annotations or output schema, the description is insufficient. It doesn't address the tool's behavioral characteristics, error handling, financial implications, or relationship to sibling tools. The agent would struggle to use this tool correctly without additional 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?

  With 100% schema description coverage, the input schema already documents all 12 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline expectation but doesn't provide extra value like explaining parameter relationships or trade-offs.

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

  Purpose4/5

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

  The description clearly states the action ('Create') and resource ('new trading position'), making the purpose immediately understandable. However, it doesn't differentiate this from sibling tools like 'ig_create_working_order' or 'ig_update_position', which might create similar trading-related entities.

  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?

  The description provides no guidance on when to use this tool versus alternatives. With siblings like 'ig_create_working_order' and 'ig_update_position' available, there's no indication of when a position should be created versus a working order, or whether this is for opening new positions versus modifying existing ones.

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

• ig_delete_working_orderC
  2.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 burden but only states the action ('Delete') without behavioral details. It doesn't disclose if deletion is permanent, requires specific permissions, has side effects, or provides confirmation. This is inadequate for a destructive operation with zero annotation coverage.

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

  Conciseness5/5

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

  The description is a single, direct sentence with zero waste. It's front-loaded and efficiently conveys the core action without unnecessary elaboration, making it easy to parse.

  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?

  For a destructive tool with no annotations and no output schema, the description is incomplete. It lacks critical context like irreversible effects, error handling, or response format. Given the complexity and risk of deletion, more behavioral transparency is needed.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents the 'dealId' parameter fully. The description adds no additional meaning beyond what the schema provides, such as format examples or context about valid deal IDs. Baseline 3 is appropriate when schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the verb ('Delete') and resource ('a working order'), making the purpose unambiguous. It distinguishes from siblings like 'ig_close_position' or 'ig_close_all_positions' by specifying deletion rather than closure, though it doesn't explicitly contrast them.

  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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing working order), exclusions, or comparisons to siblings like 'ig_close_position' or 'ig_get_working_orders'.

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

• ig_get_client_sentimentC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Get') but doesn't cover critical aspects such as authentication requirements, rate limits, data freshness, or response format. This is a significant gap for a tool with no annotation coverage.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.

  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 annotations and output schema, the description is incomplete. It doesn't explain what 'client sentiment' entails, how the data is returned, or any behavioral traits, leaving gaps in understanding for a tool that likely involves data retrieval.

  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 the parameter 'marketIds' clearly documented as a list of market IDs. The description adds no additional meaning beyond this, but the schema adequately covers the parameter, meeting the baseline for high coverage.

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

  Purpose4/5

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

  The description clearly states the verb ('Get') and resource ('client sentiment for markets'), making the purpose immediately understandable. It doesn't differentiate from siblings like 'ig_get_account_activity' or 'ig_get_market_details', but it's specific enough to identify the tool's function.

  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?

  No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, timing, or comparisons to sibling tools like 'ig_get_account_activity' or 'ig_get_market_details', leaving the agent to infer usage.

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

• ig_get_historical_pricesC
  2.9/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. 'Get historical price data' implies a read-only operation but doesn't specify whether this requires authentication, has rate limits, returns paginated results, or what format the historical data takes. For a financial data tool with zero annotation coverage, this is a significant gap in behavioral context.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a straightforward data retrieval tool and is front-loaded with the essential information. Every word earns its place in this minimal description.

  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 complexity of financial data retrieval with 5 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the returned data looks like, whether authentication is required (though sibling tools suggest it might be), or any limitations on date ranges or data availability. For a tool with this level of complexity and no structured support, the description should provide more 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?

  Schema description coverage is 100%, so the schema already documents all 5 parameters with good descriptions. The tool description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.

  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 'Get historical price data' clearly states the verb ('Get') and resource ('historical price data'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential sibling tools that might also retrieve price data, such as 'ig_get_market_details' which could include current pricing information. The description is specific about what data is retrieved but lacks sibling distinction.

  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?

  The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'ig_get_market_details' and 'ig_search_markets' that might provide related market data, there's no indication of when historical price data is needed versus current market details or search results. The description offers no context about appropriate use cases or exclusions.

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

• ig_get_market_detailsC
  2.9/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 but only states the action without disclosing behavioral traits. It doesn't mention if this is a read-only operation, rate limits, authentication needs, error handling, or what 'detailed information' entails, which is insufficient for a tool with no structured safety hints.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, making it easy to parse quickly.

  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 complexity of financial market tools and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed information' includes, potential return formats, or any prerequisites, leaving significant gaps for the agent to infer behavior.

  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, clearly documenting the 'epics' parameter as a list of market epic codes with a max of 50. The description adds no additional meaning beyond this, so it meets the baseline of 3 where the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the verb 'Get' and the resource 'detailed information about a market', which is specific and understandable. However, it doesn't differentiate from sibling tools like 'ig_search_markets' or 'ig_get_client_sentiment', which might also retrieve market-related data, so it lacks sibling distinction.

  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?

  No guidance is provided on when to use this tool versus alternatives. For example, it doesn't specify if this is for real-time data, basic details, or how it differs from 'ig_search_markets' or 'ig_get_historical_prices', leaving the agent with no context for selection.

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

• ig_get_watchlistC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a read-only operation ('Get'), but doesn't disclose authentication needs, rate limits, error conditions, or response format. For a tool with zero annotation coverage, this leaves critical behavioral traits unspecified, though it doesn't contradict any 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 a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence contributes to understanding the purpose.

  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 annotations and output schema, the description is incomplete for effective use. It doesn't explain what 'details' include (e.g., watchlist name, contents, metadata), potential errors, or authentication requirements. For a tool with no structured behavioral or output information, the description should provide more context to compensate, but it remains minimal.

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

  Parameters3/5

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

  Schema description coverage is 100%, with the parameter 'watchlistId' clearly documented in the schema. The description adds no additional meaning beyond implying the parameter identifies the watchlist to retrieve. Since the schema fully describes the single parameter, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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

  Purpose4/5

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

  The description clearly states the action ('Get details') and target resource ('a specific watchlist'), making the purpose immediately understandable. It distinguishes from the sibling 'ig_get_watchlists' by specifying retrieval of a single watchlist rather than a list. However, it doesn't explicitly mention what 'details' include or contrast with other sibling tools that might also retrieve watchlist information.

  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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a watchlist ID), contrast with 'ig_get_watchlists' for listing all watchlists, or specify use cases like retrieving metadata for editing or viewing. The agent must infer usage from the name and context alone.

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

• ig_get_watchlistsC
  2.9/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 only states the action ('Get all watchlists') without mentioning permissions, rate limits, pagination, or response format. This is inadequate for a tool that likely involves data retrieval, as critical behavioral traits are missing.

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

  Conciseness5/5

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

  The description is extremely concise with 'Get all watchlists', a single phrase that directly states the purpose without any waste. It's front-loaded and appropriately sized for a simple tool, earning full marks for efficiency.

  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 annotations and output schema, the description is incomplete. It doesn't explain what 'all watchlists' entails (e.g., user-specific, system-wide), how results are returned, or any error conditions. For a retrieval tool with no structured support, this leaves significant gaps in understanding.

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

  Parameters4/5

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

  The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, but since there are no parameters, this is acceptable, and the baseline score of 4 reflects that the description doesn't need to compensate for any gaps.

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

  Purpose3/5

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

  The description 'Get all watchlists' states a clear verb ('Get') and resource ('watchlists'), but it's vague about scope and lacks differentiation from sibling tools like 'ig_get_watchlist' (singular). It doesn't specify if this retrieves user-specific, system-wide, or all accessible watchlists, which reduces clarity.

  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?

  No guidance is provided on when to use this tool versus alternatives. For example, it doesn't explain when to choose 'ig_get_watchlists' over 'ig_get_watchlist' (singular) or other sibling tools like 'ig_get_accounts', leaving the agent without context for selection.

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

• ig_get_working_ordersC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get all working orders' implies a read-only operation, but it doesn't specify whether it returns active/pending orders, requires authentication, has rate limits, or includes pagination. The description is too vague to inform the agent adequately about how the tool behaves beyond basic retrieval.

  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—just three words—and front-loaded with the core action. There's no wasted language, making it easy to parse quickly. Every word ('Get', 'all', 'working orders') contributes directly to understanding the tool's purpose without unnecessary elaboration.

  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 annotations and output schema, the description is incomplete for a retrieval tool. It doesn't explain what 'working orders' entail (e.g., status, format) or what the return values might be. While the zero parameters simplify usage, the description fails to provide enough context for the agent to use the tool effectively without additional assumptions.

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

  Parameters4/5

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

  The input schema has 0 parameters with 100% coverage, meaning no parameters are documented or required. The description doesn't add parameter details, which is appropriate since there are none. This aligns with the baseline for zero parameters, as the description doesn't need to compensate for missing schema information.

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

  Purpose3/5

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

  The description 'Get all working orders' clearly states the verb ('Get') and resource ('working orders'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'ig_get_positions' or 'ig_get_watchlist', which follow similar patterns, leaving some ambiguity about scope. It's not tautological but lacks specificity about what distinguishes this retrieval operation.

  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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., login status), context (e.g., after creating orders), or exclusions (e.g., compared to 'ig_get_positions'). This leaves the agent with minimal direction, relying solely on the tool name in a list of siblings.

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

• ig_loginC
  2.9/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 but offers minimal information. It states the action ('Login') but doesn't describe what happens on success (e.g., session token creation, persistence), failure modes, rate limits, security implications, or whether this is a one-time or recurring operation. For an authentication tool with zero annotation coverage, this leaves critical behavioral traits unspecified.

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

  Conciseness5/5

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

  The description is a single, focused sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable and efficient. Every word earns its place by conveying essential purpose without redundancy or fluff.

  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 complexity of an authentication tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns (e.g., session tokens, account status), error behaviors, or how login state integrates with other IG tools. For a critical security-related operation, more context is needed to guide safe and effective use.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema fully documents all 5 parameters (apiKey, identifier, password, isDemo, useEncryption) with descriptions and defaults. The description adds no parameter-specific information beyond implying authentication credentials are involved. This meets the baseline of 3 since the schema does the heavy lifting, but the description doesn't enhance understanding of parameter roles or interactions.

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

  Purpose4/5

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

  The description clearly states the verb ('Login') and resource ('IG Trading account'), making the purpose immediately understandable. It distinguishes this from sibling tools like ig_logout, ig_get_accounts, and ig_switch_account by focusing specifically on authentication. However, it doesn't explicitly differentiate from potential alternatives or clarify if this is for initial session establishment versus re-authentication.

  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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether it must be called before other IG tools), when not to use it (e.g., if already logged in), or how it relates to sibling tools like ig_switch_account for account management. The agent must infer usage from the tool name alone.

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

• ig_switch_accountC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. 'Switch to' implies a state change operation, but the description doesn't clarify whether this affects subsequent API calls, requires specific permissions, has side effects on active positions, or what happens if switching fails. For a state-changing tool with zero annotation coverage, this is insufficient.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple tool with one parameter and gets straight to the point.

  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?

  For a state-changing tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'switching' entails operationally, what the expected outcome is, or how this affects subsequent API interactions. Given the complexity of account switching in trading systems, more context is needed.

  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 100% description coverage, with the single parameter 'accountId' clearly documented in the schema as 'Account ID to switch to'. The description doesn't add any additional parameter context beyond what's already in the schema, so the baseline score of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the action ('switch to') and resource ('trading account'), making the purpose immediately understandable. However, it doesn't differentiate this from sibling tools like 'ig_get_accounts' or explain what 'switch' means in this trading context.

  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?

  The description provides no guidance on when to use this tool versus alternatives like 'ig_get_accounts' or 'ig_login', nor does it mention prerequisites such as needing to be logged in first. There's no context about when switching accounts is appropriate versus when to use other account-related tools.

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

• ig_update_positionC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It states 'Update' which implies a write/mutation operation, but doesn't clarify critical aspects: whether this requires specific permissions, if changes are reversible, potential rate limits, or what happens on success/failure. For a financial trading tool modifying open positions, this lack of behavioral context is a significant gap.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a tool with clear parameters and no complex behavioral nuances needing explanation. The front-loaded structure immediately communicates the core functionality.

  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?

  For a financial trading tool that modifies open positions (a potentially sensitive operation), the description is inadequate. With no annotations, no output schema, and minimal behavioral context, the agent lacks critical information about permissions, side effects, error conditions, and return values. The 100% schema coverage helps with parameters, but doesn't compensate for the overall contextual gaps.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all parameters are documented in the schema itself. The description adds minimal value beyond what's in the schema - it mentions 'stop/limit levels' which aligns with stopLevel and limitLevel parameters, but doesn't provide additional context about parameter interactions (e.g., how trailingStop relates to stopLevel) or usage examples. Baseline 3 is appropriate when the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the action ('Update') and target ('stop/limit levels for an open position'), making the purpose immediately understandable. It distinguishes itself from siblings like 'ig_close_position' or 'ig_create_position' by focusing on modifying existing positions rather than creating or closing them. However, it doesn't explicitly differentiate from potential alternatives like 'ig_create_working_order' which might also involve order management.

  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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an open position identified by dealId), when not to use it (e.g., for closed positions), or how it differs from related tools like 'ig_create_working_order' for setting orders. The agent must infer usage from the tool name and parameters alone.

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

• ig_close_all_positionsB
  3.1/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. 'Close all open positions' implies a destructive, irreversible action affecting multiple resources, but it doesn't specify whether this requires confirmation, what happens to pending orders, or if there are rate limits or authentication requirements. The description is minimal and misses critical behavioral details for a high-stakes operation.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with zero wasted words—'Close all open positions' directly conveys the core action. It is front-loaded and appropriately sized for a tool with no parameters, making it highly concise and well-structured.

  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 complexity of a tool that performs a batch destructive operation with no annotations or output schema, the description is inadequate. It lacks details on return values, error conditions, side effects, or confirmation requirements. For a high-risk action like closing all positions, more context is needed to ensure safe and correct usage by an AI agent.

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

  Parameters4/5

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

  The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description correctly implies no required inputs, as closing all positions typically doesn't need parameters. This aligns well with the schema, earning a baseline score of 4 for parameter semantics in this context.

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

  Purpose4/5

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

  The description clearly states the action ('Close') and target resource ('all open positions'), which is specific and unambiguous. It distinguishes from the sibling 'ig_close_position' by specifying 'all' positions rather than a single one. However, it doesn't explicitly mention the financial trading context implied by the 'ig_' prefix and sibling tools.

  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?

  The description provides no guidance on when to use this tool versus alternatives like 'ig_close_position' for individual positions or 'ig_update_position' for partial adjustments. It lacks context about prerequisites (e.g., needing open positions) or consequences, leaving the agent to infer usage from the name alone.

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

• ig_logoutB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose what 'logout' entails (e.g., session termination, token invalidation), side effects, authentication requirements, or error handling, leaving significant 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 a single, clear sentence with zero wasted words, front-loading the essential action and target. It's appropriately sized for a simple tool with no parameters, making it highly efficient.

  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?

  For a tool that performs a state-changing operation (logout) with no annotations or output schema, the description is incomplete. It lacks details on behavior, side effects, success indicators, or error scenarios, which are critical for an agent to use it correctly in context.

  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 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't mention parameters, aligning with the schema, earning a baseline score above minimum viable.

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

  Purpose4/5

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

  The description clearly states the action ('Logout') and target resource ('IG Trading account'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'ig_login' beyond the obvious action contrast, missing explicit comparison.

  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?

  No guidance is provided on when to use this tool versus alternatives or prerequisites. While the context implies it should be used after authentication (given 'ig_login' exists), the description lacks explicit instructions about timing, dependencies, or error conditions.

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

• ig_get_accountsB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full responsibility for behavioral disclosure. While 'Get list' implies a read-only operation, it doesn't specify whether authentication is required, if there are rate limits, what format the list returns, or if it includes all accounts or only active ones. For a tool with zero annotation coverage, this leaves significant behavioral gaps unaddressed.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core purpose ('Get list of all trading accounts') and contains no redundant information. Every word earns its place in conveying essential information about what the tool does.

  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?

  Given the tool's simplicity (0 parameters, no output schema), the description is minimally adequate. It states what the tool does but lacks important context about authentication requirements, return format, or how it differs from sibling account tools. Without annotations or output schema, the description should provide more behavioral and contextual information to be truly complete.

  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 parameters and 100% schema description coverage, the description appropriately doesn't need to explain parameters. The schema already fully documents the empty parameter set. The description correctly focuses on the tool's purpose rather than redundant parameter details, meeting the baseline expectation for parameterless tools.

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

  Purpose4/5

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

  The description clearly states the action ('Get list') and resource ('all trading accounts'), making the purpose immediately understandable. It distinguishes this from other account-related tools like 'ig_get_account_activity' by focusing on listing rather than activity details. However, it doesn't specify what information is included in the list, leaving some ambiguity about the output.

  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?

  The description provides no guidance on when to use this tool versus alternatives. With siblings like 'ig_get_account_activity' and 'ig_switch_account' that also relate to accounts, there's no indication of when this listing tool is appropriate versus those for specific account operations or details. The description offers no context about prerequisites, timing, or comparative use cases.

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

• ig_get_positionsB
  3.2/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. 'Get all open positions' implies a read-only operation, but it doesn't specify whether this requires authentication, has rate limits, returns paginated results, or what format the positions are in. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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 a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose ('Get all open positions'), making it immediately scannable and understandable. Every word earns its place by conveying essential information.

  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?

  Given the tool's simplicity (0 parameters, no output schema), the description is adequate as a starting point. However, without annotations or output schema, it lacks details on authentication needs, return format, or error handling. For a read operation in a financial context, more behavioral context would be helpful, but the description meets the minimum viable threshold.

  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 0 parameters, and the schema description coverage is 100% (empty schema). The description doesn't need to explain any parameters, which is appropriate. It implies no filtering or input is required to retrieve all positions, aligning with the parameterless design.

  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 'Get all open positions' clearly states the verb ('Get') and resource ('open positions'), making the purpose immediately understandable. It distinguishes from siblings like 'ig_close_position' or 'ig_update_position' by focusing on retrieval rather than modification. However, it doesn't specify whether this returns positions for the current user, account, or all accounts, which prevents a perfect score.

  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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing to be logged in), nor does it differentiate from similar tools like 'ig_get_account_activity' which might include position data. Without any usage context or exclusions, the agent must infer when this tool is appropriate.

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