Server Quality Checklist

Tool Scores

• get_screenerC
  2.8/5.0
  Behavior2/5

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

  The description does not disclose behavioral traits beyond what annotations already provide. It does not mention that sorting is client-side, that pagination is 1-based, or that maxPages controls the number of API calls. With readOnlyHint=true already indicating a read-only operation, the description adds minimal value for behavior.

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

  Conciseness3/5

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

  The description is a single sentence, which is concise and front-loaded. However, it omits important details that could be included without much length, such as pagination or client-side sort behavior. It is not wasteful, but not optimally informative.

  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 the tool (9 optional parameters, client-side sort, pagination, and aggregation via maxPages), the description is too brief. It does not mention the presets for fields, the client-side nature of sorting, or the aggregation behavior. An output schema exists but is not shown; the description should compensate by explaining the result structure. It falls short.

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

  Parameters3/5

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

  Schema coverage is 100%, so the schema already documents all parameters. The description adds a high-level summary of filtering and sorting, but does not provide additional meaning beyond what the schema offers. For example, it doesn't explain the difference between presets and comma-separated fields. 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 ('Get') and resource ('cryptocurrency screener results'). It mentions filtering and sorting capabilities, making the tool's purpose understandable. However, it does not explicitly distinguish it from sibling tools, but since no other tool retrieves screener results, this is acceptable.

  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 its siblings. The description does not mention typical use cases, prerequisites, or when to avoid using it. An agent would have to infer usage from the 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.

• get_accountB
  3.3/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description does not need to reiterate those. The description adds context by listing the info types, but it does not disclose additional behavioral aspects such as rate limits, authentication requirements, or the effect of empty results. With annotations present, the description is adequate but not rich.

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

  Conciseness5/5

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

  The description is a single sentence with no wasted words. It front-loads the action and resource, and lists the key subcategories efficiently. Every word serves a purpose.

  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?

  While the description provides a good high-level summary, it does not address conditional parameter usage (e.g., exchangeId only for balances) or pagination hints. The output schema exists, so return values are covered. For a tool with 7 parameters and conditional logic, the description could be more helpful, but the schema details compensate.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter semantics beyond what the schema already provides. The schema descriptions for each parameter are detailed, so the description's lack of additional parameter info is acceptable.

  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 tool retrieves account information and lists four specific subcategories (balances, exchanges, globalVariables, supportedExchanges). The verb 'get' and resource 'account information' are specific, and the tool is distinct from siblings like get_bot or get_deal, but it does not explicitly differentiate itself.

  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 does not mention when not to use it or suggest other tools for different scenarios. The usage is implied by the name and subcategories, but explicit guidelines are missing.

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

• manage_dealB
  3.4/5.0
  Behavior3/5

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

  Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description's listing of mutating actions is consistent. However, it adds no extra behavioral context beyond what annotations convey, such as irreversible effects or authorization needs.

  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—one sentence plus a short phrase—and front-loads the core purpose. Every word earns its place with no redundancy.

  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?

  Despite 100% schema coverage, the tool has 10 parameters and three distinct actions with conditional dependencies. The description does not summarize these relationships or provide a high-level overview of when each action applies, making it insufficient for a complex tool.

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

  Parameters3/5

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

  Schema description coverage is 100%, meaning all parameters are documented in the schema. The tool description adds no additional meaning beyond what the schema already provides, so baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool manages deal operations with three specific actions: close, add funds, or reduce funds. This distinguishes it from siblings like create_deal or update_deal.

  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 says 'Each action has specific requirements' but provides no guidance on when to use this tool vs alternatives like manage_bot or update_deal. No explicit context or exclusions are given.

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

• apply_presetA
  3.7/5.0
  Behavior3/5

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

  Annotations already indicate destructive hint. Description adds process detail but no additional behavioral traits beyond annotations. Consistent with destructive nature.

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

  Conciseness5/5

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

  Two concise sentences, front-loaded with purpose, no fluff. Every word earns its place.

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

  Completeness3/5

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

  Describes process and overrides but lacks output details. With 9 params and no output schema, description could mention return value. Adequate but not fully complete.

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

  Parameters3/5

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

  Schema has 100% coverage, so baseline 3. Description mentions override pair and name but incorrectly includes 'sizing' which is not a parameter, causing slight confusion. No net gain over 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?

  Description clearly states the tool creates a bot from a curated preset in one call, distinguishing it from manual creation (create_bot) or listing presets (list_presets). It specifies the process and overrides.

  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?

  Description implies use for presets but lacks explicit guidance on when to use vs alternatives like create_bot. No when-not-to or exclusions provided.

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

• backtest_infoA
  3.7/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds context about the specific read operations (list, fetch, get, build) but does not discuss additional behavioral traits like rate limits or prerequisites.

  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?

  Description is a single sentence with a colon-separated list, front-loading the core purpose. It is concise but could be slightly more streamlined.

  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 presence of an output schema (so return values are covered) and 100% schema coverage, the description adequately covers the four operations. It does not explicitly note required parameters but the schema does.

  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 parameters thoroughly. The description only briefly rephrases the target options, adding minimal extra 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?

  Description clearly states 'Get backtest information' and lists four specific actions (list requests, fetch, get schema, build template), distinguishing it from sibling tools like run_backtest or create_bot.

  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?

  Description lacks explicit guidance on when to use this tool vs alternatives like run_backtest. Usage is implied by the listed actions, but no when-not or alternative guidance is provided.

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

• manage_global_variableA
  3.7/5.0
  Behavior3/5

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

  Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds context that variables are 'user-defined constants accessible in strategies,' which is helpful but does not disclose further behavioral traits such as impact on strategies or undo possibilities.

  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 sentences with no superfluous words. It front-loads the primary actions and provides a brief definition of the resource.

  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 no output schema, the description could include more complete context, such as the consequences of deletion or the requirement to provide 'id' for update/delete. While it covers the basic purpose, it leaves some operational details implicit.

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

  Parameters3/5

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

  Schema coverage is 100%, so the baseline is 3. The description does not add additional meaning to the parameters beyond what is in the schema (e.g., no explanation of how 'id' relates to 'action' or constraints on '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?

  Description clearly states the tool performs create, update, or delete operations on global variables. The verb 'manage' plus the specific resource 'global variable' is unambiguous and distinguishes it from sibling tools that focus on bots, deals, and presets.

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

  Usage Guidelines3/5

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

  The description implies usage for managing global variables but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. Users must infer from the action enum.

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

• run_backtestA
  3.7/5.0
  Behavior2/5

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

  Annotations indicate readOnlyHint=false and destructiveHint=false, but the description does not clarify what the tool actually does beyond 'run backtest'. It omits behavioral details such as whether it consumes credits, returns a backtest ID, or how long async requests take. The description adds minimal value beyond the annotations and 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 extremely concise: two sentences that cover the tool's purpose and main modes without extraneous information. It is front-loaded with the action (run) and key distinction (four modes), making it easy to parse.

  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 complexity (nested objects, enums, multiple modes), the description is too brief. It does not explain what the tool returns (no output schema), how to interpret results, or prerequisites like credit balance. However, it covers the basic operation flow. A more complete description would add outcome details.

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

  Parameters3/5

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

  Schema coverage is 100%, so baseline is 3. The description adds a brief summary of required payload fields, but this largely repeats the schema. It does not provide additional context or constraints beyond what the schema already offers. A higher score would require unique semantic insights, which are absent.

  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 runs backtest operations, lists four distinct modes (validate, estimate, request, requestSync), and specifies the required payload elements (exchange, exchangeUUID, bot settings). It distinguishes from siblings like backtest_info, which handles results, and other bot management tools.

  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 each mode (validate, estimate, request, requestSync), but does not explicitly state when not to use the tool or offer direct comparisons with alternatives like backtest_info for retrieving results. The guidance is adequate for an agent to choose the correct mode.

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

• clone_botA
  3.8/5.0
  Behavior3/5

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

  Annotations already indicate destructiveHint=true. The description adds that it returns the new bot ID, but does not elaborate on side effects or restrictions. 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?

  Two concise sentences: first states action and optional override, second states return value. No fluff, well-structured and front-loaded.

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

  Completeness4/5

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

  Given the tool's complexity and schema coverage, the description provides sufficient context for a clone operation, specifying the return value. It lacks detail on what exactly is cloned (e.g., configuration, deals), but overall adequate.

  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 all 4 parameters with descriptions. The description adds minimal value ('optionally override settings'), which is already implied by the overrides parameter name. High schema coverage warrants baseline 3.

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

  Purpose5/5

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

  The description clearly states the verb 'clone', the resource 'existing bot', and the optional override. It distinguishes from siblings like create_bot (creates from scratch) and update_bot (modifies existing). The return value is specified.

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

  Usage Guidelines3/5

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

  The description implies cloning for creating a copy with possible overrides, but lacks explicit guidance on when to use vs create_bot or update_bot, and no prerequisites 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.

• manage_botA
  3.9/5.0
  Behavior4/5

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

  Annotations indicate destructiveHint=true and readOnlyHint=false. Description adds specific destructive actions (stop, archive) and the constraint 'DCA only' for changePairs. No contradiction.

  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?

  Single sentence that is front-loaded with purpose and includes a concise caveat. Every word earns its place.

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

  Completeness3/5

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

  For a tool with 8 parameters and conditional requirements, the description is minimal. Does not explain that closeType/closeGridType are needed for stop, or that pair is only for changePairs. No output schema, but return behavior is not addressed.

  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% with detailed descriptions. The tool description says 'Each action has specific requirements' but does not elaborate on parameter dependencies per action. Minimal added value beyond 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?

  Description clearly states verb 'Manage', resource 'bot lifecycle', and lists specific actions (start, stop, archive, restore, changePairs). Distinguishes from siblings like create_bot, update_bot.

  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?

  Mentions 'Each action has specific requirements' but provides no explicit guidance on when to use this tool vs alternatives like create_bot or update_bot. No exclusions or when-not advice.

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

• list_presetsA
  4/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds behavioral context by specifying that results are ranked by backtested performance and include ROI, drawdown, and full strategy settings. This goes beyond annotations, though it does not mention rate limits or auth needs.

  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 convey the purpose and output without redundancy. Information is front-loaded and each sentence adds value.

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

  Completeness4/5

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

  Given 7 parameters (100% schema coverage) and an output schema, the description sufficiently explains the tool's function and output. It could mention ordering criteria explicitly, but overall it is complete enough for an agent to use the tool effectively.

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

  Parameters3/5

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

  Schema coverage is 100%, so baseline is 3. The description does not add meaning to individual parameters beyond what the schema provides. It explains the output structure but not 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 clearly states the tool lists curated bot-strategy presets, ranked by backtested performance, and details the output structure. This distinguishes it from siblings like list_bots (which lists bots) and apply_preset (which applies a preset).

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

  Usage Guidelines3/5

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

  The description implies usage for browsing presets, but does not explicitly state when to use this tool versus alternatives like apply_preset or list_bots. It provides no 'when not to use' guidance or explicit context for selection.

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

• create_botA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate destructiveHint=true, so the description's mention of creation implies mutation. The description adds value by explaining the single-step behavior and transparent merging of settings, which goes beyond the annotations. No contradiction detected.

  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 a single paragraph with key points front-loaded (single step creation, settings fallback). It is efficient and every sentence provides useful information. However, it could be more structured with bullet points for clarity.

  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 complexity (28 parameters, nested objects, no output schema), the description covers the creation process well. However, it does not describe the return value or confirmation of success, which is a gap. The lack of output schema increases the burden on the description.

  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 100% schema coverage, the baseline is 3. The description adds meaning for the 'settings' parameter, explaining it is a transparent passthrough for any field not listed. It also provides additional context for 'pair' (Grid bot unwrapping) and enumerates examples of fields that go into settings. This elevates the score above baseline.

  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 it creates a new bot in a single step, avoiding the need for a follow-up update. This directly specifies the verb and resource, and the phrase 'no follow-up update needed' distinguishes it from sibling tools like update_bot.

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

  Usage Guidelines4/5

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

  The description provides explicit guidance on using the 'settings' object for fields not listed, and references discover() for all available fields. It also warns about auto-detected fields ('futures', 'coinm') and clarifies pair handling for Grid bots. However, it does not explicitly state when not to use this tool or provide alternative tool names.

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

• discoverA
  4.2/5.0
  Behavior4/5

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

  Annotations already set readOnlyHint=true and destructiveHint=false. The description adds context about learning defaults/strategies, reinforcing read-only nature. No contradictions; behavioral traits are adequately disclosed.

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

  Conciseness5/5

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

  Two concise sentences, front-loaded with the primary action and list of targets. No redundant information, every word earns its place.

  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 output schema exists and annotations cover safety, the description is complete for a discovery tool. It covers multiple targets adequately, though could mention return format briefly.

  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% with well-described parameters, so the description adds no extra per-parameter meaning. Baseline 3 is appropriate as the schema already handles semantics.

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

  Purpose5/5

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

  The description clearly states the tool discovers bots, bot details, sections, indicators, and exchanges. It distinguishes from sibling tools (most are CRUD operations) by focusing on exploration and learning available fields, defaults, and strategies.

  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 says 'Use this to learn available fields, defaults, and strategies,' which gives clear usage context for discovery. It lacks explicit when-not-to-use or alternatives, but the purpose is well differentiated from siblings.

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

• list_botsA
  4.2/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true and destructiveHint=false, so the description focuses on behavioral traits like field selection presets and filtering options. It adds useful context beyond annotations, though it omits details like pagination 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 concise with two sentences: the first states the core purpose with bot types, and the second lists additional features. It is front-loaded and contains no redundant information.

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

  Completeness4/5

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

  Given the tool's complexity (5 parameters, output schema present), the description covers the main aspects: bot type filtering, field selection, status and context filters. It does not mention pagination or sorting, but these are documented in the schema, so completeness is adequate.

  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 100% schema coverage, the baseline is 3. The description adds meaning by explaining the role of botType, fields, and filters, grouping them into a coherent purpose. The page parameter is only implied through its schema, but overall the description compensates well.

  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 'List bots by type (DCA, Combo, or Grid)', using a specific verb and resource. It highlights key capabilities like field selection presets and filtering by status and paper/real context, distinguishing it from sibling tools like get_bot or list_deals.

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

  Usage Guidelines3/5

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

  The description implies usage through its name and mention of bot types and filters, but it does not explicitly state when to use this tool over alternatives or when not to use it. No exclusions or comparisons are provided.

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

• list_dealsA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by mentioning field selection presets and filtering, which are behavioral options beyond the annotations. No contradictions exist.

  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-loading the core action ('List deals by type') followed by key capabilities. Every sentence earns its place with no redundancy.

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

  Completeness4/5

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

  Given the presence of an output schema and rich input schemas, the description covers the essential behavior (listing, type, filters, field selection) but omits mention of pagination. While the page parameter is in the schema, an agent might benefit from knowing pagination is supported. Overall, it is nearly complete for a 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?

  Schema coverage is 100%, so baseline is 3. The description adds minimal extra meaning by summarizing dealType enum values and mentioning field presets, but these are already detailed in the schema. The description reinforces key parameters without significant new information.

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

  Purpose5/5

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

  The description clearly states the tool lists deals by type (DCA, Combo, Terminal) and distinguishes it from siblings like get_deal (single deal) and create_deal (mutation). The verb 'list' combined with resource 'deals' and explicit type enumeration leaves no ambiguity.

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

  Usage Guidelines4/5

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

  The description implies usage context by specifying filtering capabilities (status, botId) and field selection presets. It does not explicitly state when not to use or reference alternatives, but the context is clear enough for an agent to select this over siblings like get_deal for single-item retrieval or list_bots for bots.

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

• update_dealA
  4.2/5.0
  Behavior3/5

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

  Annotations already declare destructiveHint=true, so the description adds minimal beyond that. It adds a constraint (settings non-empty) but doesn't elaborate on side effects or permissions.

  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 efficient sentences with no wasted words. Front-loaded with the key 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?

  For a 4-parameter tool with full schema descriptions and annotations, the description covers the essential usage pattern and constraint. Could mention output or error handling but not required.

  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?

  Description adds value beyond the schema by advising partial updates. Schema already covers parameter details well (100% coverage), so additional guidance is helpful but not essential.

  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 'Update' and the resource 'existing deal'. It distinguishes this from create_deal and manage_deal, aligning with the tool's name.

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

  Usage Guidelines4/5

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

  Provides usage guidance: 'Pass only the fields you want to change' and 'Settings object must be non-empty'. However, it does not explicitly state when not to use this tool or mention alternatives like manage_deal.

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

• update_botA
  4.3/5.0
  Behavior5/5

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

  Annotations indicate destructive and not read-only; the description adds crucial behavioral details beyond annotations, such as the silent ignoring of feature value fields when their toggle is false. This transparency helps the agent avoid unexpected behavior.

  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 three clear, efficient sentences with no wasted words. The most important information (purpose and constraints) is front-loaded.

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

  Completeness4/5

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

  For a simple update tool with full schema coverage and annotations, the description covers purpose, usage, constraints, and a behavioral quirk. Missing a note about the return value, which could be inferred but not stated.

  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 description adds little to parameter understanding beyond what the schema provides. The description re-emphasizes the partial update strategy but does not introduce new 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 tool updates existing bots, specifying DCA or Combo only, directly distinguishing it from create_bot and other siblings. The verb-resource pairing is precise.

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

  Usage Guidelines4/5

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

  Provides explicit guidance on partial updates ('Pass only the fields you want to change'), a constraint on the settings object (must be non-empty), and a behavioral note about boolean gates. It also clarifies that Grid bots are not supported, helping the agent avoid calling the tool incorrectly.

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

• get_botA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's addition that it gets a bot aligns well. It also adds context about ID formats and field presets, which is useful beyond annotations.

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

  Conciseness5/5

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

  Two sentences, no wasted words. First sentence states purpose, second adds context. Very concise.

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

  Completeness4/5

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

  Given the output schema exists and annotations are provided, the description covers the core functionality. It could mention error cases, but is sufficient for a simple get tool.

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

  Parameters4/5

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

  Schema coverage is 100%, but the description adds value by explicitly mentioning that botId accepts ObjectId or UUID and referencing list_bots for field presets, which is not 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 clearly states the tool gets a single bot by its MongoDB ObjectId or UUID, and mentions field selection presets. It is specific and distinguishes from sibling tools like list_bots.

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

  Usage Guidelines4/5

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

  The description implies usage for retrieving a single bot with field selection, and references list_bots for presets. However, it does not explicitly state when not to use or provide alternatives.

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

• get_dealA
  4.4/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds the behavioral detail of supporting field selection presets, which is not evident from annotations alone. No contradiction.

  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 sentences that convey the core purpose and a key distinguishing feature. Every sentence is necessary and no extraneous information.

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

  Completeness4/5

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

  For a single-deal retrieval tool with an output schema and complete parameter documentation, the description is adequate. It could optionally mention the response format or error cases, but the existing information is sufficient for an AI agent to use the tool correctly.

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

  Parameters4/5

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

  The input schema covers 100% of parameters with detailed descriptions. The description adds contextual value by linking the fields parameter to list_deals presets, which reduces ambiguity about what values are accepted beyond the enum.

  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 ('Get a single deal'), the identifier type ('by its MongoDB ObjectId'), and a key feature ('Supports the same field selection presets as list_deals'). It is specific and distinguishes this tool from siblings like list_deals and update_deal.

  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 implicitly indicates when to use this tool (when you have a specific deal ID) by contrasting with list_deals. However, it does not explicitly state when not to use it or provide alternative tool names for different use cases.

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

• create_dealA
  4.5/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=false and destructiveHint=true, indicating a write operation that may be destructive. The description confirms creation of a new deal, aligning with annotations and adding no contradiction. It also clarifies the two distinct creation pathways, adding behavioral context beyond annotations.

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

  Conciseness5/5

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

  Two sentences with no filler. The first sentence states the main purpose; the second explains the two modes. Every phrase earns its place, making it highly efficient and easy to parse.

  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 complexity of 13 parameters and two distinct creation paths, the description provides a high-level overview that covers the main modes. It does not detail all parameter interactions or return values, but the schema fills those gaps. A mention of any output or next steps could improve completeness, but overall it's adequate.

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

  Parameters5/5

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

  While schema coverage is 100% with descriptions, the tool description adds significant meaning by grouping parameters by deal type (dca/combo requires botId, terminal requires exchangeUUID, etc.). This provides context that the schema alone does not offer, such as explaining that settings is a passthrough for terminal.

  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 explicitly states the tool's purpose: creating a new deal. It distinguishes between two types (dca/combo from existing bot, terminal standalone), providing a clear verb+resource distinction that differentiates it from sibling tools like update_deal or manage_deal.

  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 each parameter set: for dca/combo vs terminal. It implicitly guides the agent on required parameters based on deal type, but does not explicitly exclude other use cases or mention alternatives.

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