Server Quality Checklist

Tool Scores

• list_ordersC
  2.7/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Lists' without mentioning that this is a read-only operation, any side effects, pagination behavior, or return format. The mention of 'filtering criteria' hints at behavior but never explains how filtering is applied or whether results are ordered.

  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, concise sentence with no redundancy. It front-loads the core action and resource, and every part contributes to the basic purpose. However, it is almost too terse, missing needed context, so it is not a perfect 5.

  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 empty schema and no output schema, the description leaves critical gaps: it does not explain where the 'supplied account' comes from, how 'filtering criteria' are passed, or what the response looks like. An agent has no idea how to structure the invocation or interpret the result, making the description incomplete for reliable use.

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

  Parameters2/5

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

  The input schema has zero parameters, but the description claims 'using the supplied account and filtering criteria', implying parameters that do not exist in the schema. This inconsistency makes the semantic meaning confusing rather than additive. Since there are no parameters to clarify, the description's mention of unspecified inputs harms rather than helps.

  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 states a specific verb and resource: 'Lists cTrader orders'. It adds scope with 'account and filtering criteria', which helps distinguish it from siblings like list_positions and get_order_details. The only shortcoming is that it doesn't explicitly name those siblings to differentiate.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use list_orders versus alternatives such as list_positions or get_order_details. The statement merely describes what the tool does, leaving an agent to infer any contextual selection criteria like needing a list of all orders rather than positions or a single order.

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

• get_symbolC
  2.8/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It indicates a read operation via 'Gets', but does not state what metadata is included, whether it is safe/read-only, what happens if the symbolId is invalid, or any error/rate-limit behavior. This is minimally informative but not misleading.

  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 concise sentence with no wasted words, front-loading the action and resource. It loses a point only because it could have used its brevity wisely to add a bit more useful context.

  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?

  This is a simple one-parameter read tool, so the description is minimally viable for an agent to attempt a call. However, with no output schema and no mention of return value shape, success/error conditions, or relation to sibling tools, an agent has incomplete context for interpreting results or planning multi-step workflows.

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

  Parameters2/5

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

  Schema description coverage is 0% and the description adds little beyond the schema. It confirms symbolId refers to a cTrader symbol or instrument, but it does not explain the expected format, source, or valid values for symbolId, so the agent gets weak parameter guidance.

  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 a specific verb ('Gets') and resource ('detailed metadata for a specific cTrader symbol or instrument'), so an agent knows this is a retrieval operation for a single symbol. It does not explicitly differentiate from siblings like get_market_data or list_symbols, which prevents a 5.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives such as list_symbols or get_market_data. No prerequisites, exclusions, or context are provided, leaving the agent to 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.

• get_account_list_by_access_tokenB
  3.2/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It only states the high-level purpose and gives no detail about authentication requirements, pagination, possible empty results, or whether the list includes only active accounts. The token scoping is hinted at, but behavior beyond the basic listing is undisclosed.

  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 no filler or redundancy. It front-loads the 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.

  Completeness3/5

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

  For a zero-parameter list operation, the description is minimally adequate and states the core purpose. However, it lacks usage guidance, behavioral details, and any note about the return value, which matters because no output schema is provided. It is complete enough to begin with but not fully self-sufficient.

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

  Parameters4/5

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

  The tool has zero parameters, so there is no parameter meaning to explain. The description adds useful context by clarifying that the accounts are scoped to the active cTrader access token, which is the relevant semantic for this no-input operation.

  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 a specific verb ('Lists') and resource ('accounts') with a scope qualifier ('available to the active cTrader access token'). It is immediately understandable, but it does not explicitly differentiate from sibling tools like get_account_status or get_trader, leaving some potential ambiguity.

  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 about when to use this tool versus alternatives. The description does not mention any prerequisites, exclusions, or scenarios where another sibling tool would be more appropriate.

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

• list_deals_by_position_idB
  3.2/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. 'Lists' indicates a read-only operation, but the description does not mention pagination, ordering, response contents, error behavior, or whether historical and closed positions are included.

  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 one concise, front-loaded sentence with no filler or redundant information. Every word contributes to identifying the tool's function and scope.

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

  Completeness3/5

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

  The tool is simple with one required parameter, and the description is adequate for basic invocation. However, with no annotations and no output schema, the agent is left without detail on return format, pagination, or operational constraints.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It adds only that positionId is a 'specific cTrader position ID', which is minimal beyond the schema property name. It does not explain the expected format, source, or how it relates to IDs from sibling tools.

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

  Purpose5/5

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

  The description uses a specific verb ('Lists') and resource ('deal history'), and clearly scopes it to a 'specific cTrader position ID'. This distinguishes it from sibling tools like list_positions and list_orders, which deal with different 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 implies the tool is for fetching deal history for a known position ID, but it gives no explicit guidance about when to use this tool versus alternatives such as list_positions, get_order_details, or list_orders. No exclusions or decision criteria are provided.

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

• get_market_dataB
  3.3/5.0
  Behavior2/5

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

  There are no annotations, so the description carries the full behavioral burden. It discloses that the tool fetches read-only market data and lists possible data types, but it does not mention time windows, response shape, pagination, authentication needs, or error 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 one efficient sentence with a front-loaded action verb and useful examples. Every part contributes to understanding the tool, with no filler or redundancy.

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

  Completeness3/5

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

  The tool is simple with a single parameter, but there is no output schema and no annotation context. The description names return categories but leaves the actual response format, time range, and edge-case behavior implicit, which is a notable gap for a tool an agent must invoke and interpret.

  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 provides zero description coverage, so the description must compensate. It clarifies that 'symbol' is the identifier for which market data is fetched, but it provides no format, example value, or additional constraints beyond the schema's 'symbol' string property.

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

  Purpose5/5

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

  The description uses a specific verb ('fetches') and resource ('recent market data for a symbol'), with concrete examples of what counts as market data: quotes, candles, or latest trades. This clearly distinguishes it from sibling tools like list_symbols or get_symbol, which focus on instrument metadata rather than live market data.

  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 about when to prefer this tool over alternatives or what conditions make it appropriate. The description implies it is for market data retrieval, but it never explicitly compares against sibling tools or states exclusions.

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

• get_order_detailsB
  3.3/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 conveys a read operation via 'Fetches', but it does not describe what 'detailed information' includes, error behavior, or whether the response can be empty for invalid IDs. This is minimal behavioral context for a tool with no output schema.

  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, front-loaded sentence with no filler or redundant phrasing. It is concise and easy to parse, though it sacrifices completeness in other dimensions.

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

  Completeness3/5

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

  For a simple one-parameter getter, the description states the core purpose adequately. However, with no output schema, no annotations, and no detail on what 'detailed information' means, an agent cannot fully anticipate return shape or edge cases. Sibling tools imply orderId could come from list_orders, but that connection is not explicit.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description does not explain the orderId parameter beyond what the schema already exposes (name and type 'string'). It loosely implies orderId targets the specific order, but it does not clarify format, source, or how to obtain it.

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

  Purpose5/5

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

  The description uses a specific verb ('Fetches') and resource ('detailed information for a specific cTrader order'), making the operation unambiguous. The word 'specific' clearly distinguishes it from siblings like list_orders, which presumably returns multiple orders.

  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 implicitly tells the agent to use this when it needs details about one order, but it does not explicitly mention when to prefer it over list_orders or provide alternatives/exclusions. There is no guidance about needing to first obtain an orderId from another tool.

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

• get_traderB
  3.4/5.0
  Behavior3/5

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

  With no annotations provided, the description must carry the behavioral disclosure burden. It does convey a read-only operation ('Returns') and an authentication precondition, but it omits any detail about failure modes, required token scopes, or the scope of the returned metadata. This 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?

  A single sentence delivers the tool's core function and is immediately front-loaded. There is no filler or redundant restatement of the tool name.

  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 zero-parameter read call, the description is minimally sufficient: an agent knows it receives an authenticated profile. However, with no output schema and only the vague phrase 'related account metadata', an agent is left uncertain about the exact return shape and how this differs from account-status siblings.

  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 zero parameters, so there is nothing to document; the baseline for 0 params is 4. The description's mention of the trader profile and account metadata clarifies what the result refers to, which is sufficient.

  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 names a specific resource ('cTrader trader profile') and a clear verb ('Returns'), so an agent knows what the tool does. It loses a point because 'related account metadata' is vague and it does not distinguish itself from siblings like get_account_status or get_account_list_by_access_token.

  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 given about when to choose this tool over nearby siblings such as get_account_status or get_account_list_by_access_token, nor are there any situations where it should not be used. The only hint is 'authenticated', which implies a precondition but does not direct tool selection.

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

• list_symbolsB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description must carry the burden of behavioral disclosure. It communicates a read-only listing operation and that metadata is returned, but it does not clarify what 'basic metadata' includes, whether results are paginated, or whether the list is scoped to a specific account or workspace.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no filler. Every word contributes meaning, and it avoids repeating the tool name or schema 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?

  For a simple, no-parameter listing tool, the description is mostly adequate, but since there is no output schema, it should more precisely describe the returned metadata or indicate whether the list is account-scoped. The vagueness of 'basic metadata' leaves room for ambiguity about what the agent will receive.

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

  Parameters4/5

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

  The tool has zero parameters, and the schema coverage is trivially 100%. The description adds no parameter-specific details, but none are needed; the baseline for a parameterless tool is appropriate 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 uses a specific verb ('Lists') and identifies the resource ('available cTrader symbols or instruments') with a hint at the data returned ('basic metadata'). It is clear in intent but does not explicitly differentiate itself from siblings like get_symbol or list_symbol_categories.

  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 states only what the tool does, not when an agent should choose it over alternatives. There is no mention of when to use this tool versus get_symbol for a single symbol or list_symbol_categories for categories, and no exclusions or prerequisites are given.

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

• get_account_statusA
  3.5/5.0
  Behavior3/5

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

  There are no annotations, so the description carries the full burden. 'Retrieves' clearly indicates a read operation and 'current' and 'session metadata' add some scope, but there is no mention of output shape, required authentication, or any behavioral caveats.

  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 with no filler. It front-loads the core purpose and every word contributes to understanding what the tool does.

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

  Completeness4/5

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

  For a zero-parameter status getter, the description is largely adequate: it names the resource and scope ('current cTrader account status and session metadata'). However, with no output schema and no annotations, a bit more detail about what the returned metadata includes would make it fully 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?

  The tool has zero parameters, so the baseline is 4. There is no parameter information needed beyond the schema, which is already empty and complete.

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

  Purpose4/5

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

  The description uses a clear verb ('Retrieves') and identifies a specific resource: current cTrader account status and session metadata. It does not explicitly differentiate itself from siblings like get_trader or get_account_list_by_access_token, so it loses the top 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?

  No guidance is given on when to use this tool versus related tools such as get_trader or get_account_list_by_access_token. The description simply states what it does 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.

• get_position_unrealized_pnlA
  3.5/5.0
  Behavior3/5

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

  With no annotations available, the description carries the full burden of behavioral disclosure. 'Retrieves' communicates a read-only, non-mutating operation, but the description does not mention auth requirements, error behavior, assumptions about open positions, or response handling. It is minimally transparent but not misleading.

  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 fluff or repetition. The verb, resource, and scope are front-loaded, making the tool's purpose immediately clear.

  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 one-parameter getter, the description is close to sufficient: the operation and input are obvious. However, there is no output schema, and the description does not clarify the response shape, currency/units of the P&L, or whether the position must be currently open. These are modest but real 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 coverage is 0% for the sole positionId parameter, though the property name is fairly self-explanatory. The description adds domain context by identifying it as a 'specific cTrader position,' but it does not specify the ID format, source, or how to obtain it. This partially compensates for the schema gap without fully doing so.

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

  Purpose5/5

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

  The description uses the specific verb 'Retrieves' and a precise resource: 'unrealized P&L for a specific cTrader position.' This distinguishes it from siblings such as list_positions and get_market_data, since no other sibling targets a single position's P&L.

  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 implies a prerequisite by saying 'for a specific... position,' but it does not explain when to use this tool versus alternatives such as list_positions or list_deals_by_position_id. No exclusions or conditions are stated, so usage guidance is left mostly to inference.

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

• list_positionsA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It clearly indicates a read-only operation that returns currently open positions, which is helpful, but it does not reveal response shape, whether the list is a live snapshot, or any authorization/rate-limit context. For a simple list tool, the basic behavior is adequately stated, but meaningful gaps remain.

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

  Conciseness5/5

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

  The description is a single front-loaded sentence that names the action, the resource, and the scope with no wasted words. Every part contributes to understanding the tool's purpose.

  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 parameterless list operation, the description is nearly complete: an agent knows it will get current positions and their status. The lack of an output schema leaves the exact fields unspecified, but for this low-complexity tool the text provides enough context to select and invoke it 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 tool has no parameters and the schema shows none, so there is little for the description to add. With zero parameters the baseline is 4, and the description does not need to explain parameter syntax or defaults.

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

  Purpose5/5

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

  The description uses a specific verb ('Returns') plus a well-defined resource ('currently open cTrader positions') and scope ('currently open'), making the tool's intent immediately clear. This resource is distinct from sibling tools like list_orders or list_deals_by_position_id, so an agent can tell what it returns.

  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 given about when to use this tool instead of siblings such as get_position_unrealized_pnl, list_deals_by_position_id, or list_orders. The phrase 'currently open' implicitly limits it to current positions, but there are no explicit when-to-use or when-not-to-use criteria.

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

• list_symbol_categoriesA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description is the sole source of behavioral information. It conveys a read-only listing operation through the verb 'Lists,' but it does not disclose return format, ordering, completeness, or any operational details beyond the basic action.

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

  Conciseness5/5

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

  The description is a single efficient sentence with no filler. 'Lists cTrader symbol categories' is front-loaded, and the trailing clause adds meaningful context about the purpose of the categories.

  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 parameterless listing tool, the description is largely sufficient: an agent knows what will be listed and why. However, with no output schema and no annotations, a bit more detail about the shape or scope of the returned categories would strengthen completeness.

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

  Parameters4/5

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

  The tool has zero parameters and the schema already documents this completely (100% coverage), so the description has no parameter burden. Per the zero-parameter baseline, a score of 4 is appropriate.

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

  Purpose5/5

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

  The description uses a specific verb ('Lists') with a concrete resource ('cTrader symbol categories') and adds context ('used to organize the instrument universe'). It is clearly distinct from sibling tools like list_symbols or get_symbol, which operate on individual symbols rather than categories.

  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 about when to choose this tool over alternatives such as list_symbols or get_symbol. The description doesn't mention prerequisites, use cases, or exclusions, leaving the agent to infer the appropriate context.

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

• amend_orderA
  4/5.0
  Behavior4/5

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

  With no annotations present, the description carries the behavioral disclosure burden, and it does so well: it states that the account ID is bound to the authenticated session, order ID is validated, only supported amendment parameters are allowed, and the response includes updated order state. It does not cover error behavior or reversibility, but the disclosed validations and response contract are genuinely useful.

  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 tight: one clear opening sentence followed by four meaningful bullets. Every line adds distinct information, and the most important action is front-loaded. There is no redundant or filler content.

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

  Completeness4/5

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

  For a four-parameter mutation tool with a complete schema and an output schema, the description covers the essential behavioral context: validation, session binding, supported parameters, and response content. It could add when-to-use guidance or amendment limitations, but nothing critical is missing for a competent agent to call it correctly.

  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 explains the parameters: order_id, account_id, optional price, and optional volume. The description adds no per-parameter meaning beyond what the schema provides, so the baseline of 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 starts with a clear verb and resource: 'Amend an existing cTrader order.' This distinguishes it from sibling tools like create_order and cancel_order. The added bullets about validation and response state reinforce the specific purpose without ambiguity.

  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 phrase 'existing cTrader order' implies this is for modifying orders that already exist, not for creating or canceling them. However, it never explicitly states when to prefer this tool over alternatives, nor does it name any sibling or exclusion condition.

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

• create_orderA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the behavioral disclosure burden and does so well. It explicitly lists four behavioral guarantees: session-bound account ID, positive volume validation, order type normalization, and full order state in the response. This goes beyond the bare 'create' semantics and gives agents meaningful expectations.

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

  Conciseness5/5

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

  The description is compact and front-loaded with the core purpose, followed by a tight bullet list of behavioral guarantees. Every sentence earns its place, with no fluff or redundant repetition of schema content.

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

  Completeness4/5

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

  The description is largely complete for a create operation: it names the resource, covers key validation and normalization behaviors, and notes the response shape. With full schema coverage and an output schema present, the agent has enough to invoke the tool correctly. Minor gaps remain around preconditions or when to prefer this over alternatives, but these are not critical.

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

  Parameters4/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining that account_id is always bound to the authenticated session, volume must be positive, and order_type is normalized to cTrader protocol values. These details enrich the otherwise minimal schema descriptions.

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

  Purpose5/5

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

  The description opens with 'Create a new cTrader order,' which states a specific verb and resource. This clearly distinguishes it from sibling tools like cancel_order and amend_order, making the tool's role unmistakable.

  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 explicit guidance on when to use this tool versus cancel_order, amend_order, or list_orders. The verb 'Create' implies usage for new orders, but no alternatives, exclusions, or contextual conditions are stated.

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

• cancel_orderA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the behavioral burden. It correctly implies mutating behavior and restricts to open orders, but it does not disclose what happens for unknown/already-closed IDs, reversibility, or related position effects.

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

  Conciseness5/5

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

  One front-loaded sentence with no filler: verb, object, condition, and parameter are all present in minimal space.

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

  Completeness4/5

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

  For a simple one-parameter cancellation tool, the description covers what, how, and the open-order precondition. It is slightly incomplete because error/edge-case behavior and output are not described, but these are secondary for basic invocation.

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

  Parameters4/5

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

  With 0% schema description coverage, the description compensates by stating that the sole parameter is the order ID used for cancellation. It adds practical meaning to the string type, though it does not specify ID source or format.

  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?

  States a specific action ('Cancels') and exact resource ('open cTrader order'), plus the identifier method ('by its order ID'). This clearly separates it from siblings like close_position (positions) and amend_order/list_orders.

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

  Usage Guidelines4/5

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

  Provides clear context: use it for open cTrader orders identified by order ID. It does not explicitly name alternatives or exclusion conditions, but 'open' and 'order' are sufficient directional guidance.

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

• close_positionA
  4.6/5.0
  Behavior4/5

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

  No annotations are present, so the description carries the behavioral burden. It discloses session-bound account enforcement, non-empty position ID validation, positive volume validation, and partial-close support. It does not explicitly mention irreversibility or permissions, but 'Close' itself conveys the core destructive action.

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

  Conciseness5/5

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

  The description is compact and front-loaded with the core purpose, followed by four bullet points that each add distinct value. There is no filler or redundant restatement of the schema.

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

  Completeness5/5

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

  For a 3-parameter mutation tool with an output schema available, the description covers the essential behavior, validation rules, auth binding, and partial-close semantics. Nothing critical is missing for an agent to select and invoke the tool correctly.

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

  Parameters5/5

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

  Schema coverage is already 100%, and the description adds meaning beyond the schema: account_id is session-bound, position_id must be a non-empty string, and volume is optional, positive, and enables partial closes. This gives an agent useful operational context for each parameter.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Close a cTrader position.' It clearly distinguishes closing a position from order-level operations like cancel_order, and the partial-close note further clarifies scope. The purpose is unambiguous and not a tautology.

  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 intended use is clear: call this when you want to close a cTrader position, including partial closes via the volume parameter. It does not explicitly name alternatives or when-not-to-use scenarios, but the context is direct enough that an agent can infer when it applies.

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