Server Quality Checklist

Tool Scores

• list_positionsA
  4.3/5.0
  Behavior4/5

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

  Annotations already indicate read-only and open-world hints. The description adds valuable behavioral context: data is read live, sl/tp of 0 means no stop/take profit, and ticket is the handle for closing. This goes beyond the structured annotations.

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

  Conciseness5/5

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

  The description is concise and well-structured: the first sentence states the core purpose, the second clarifies the parameter, the third explains edge cases of sl/tp. Every sentence adds value with no redundancy.

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

  Completeness5/5

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

  Given the tool's simplicity (one parameter, output schema present), the description fully covers the needed context: what data is returned, how to identify the account, how to use the ticket, and edge cases like sl/tp = 0. Nothing essential is missing.

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

  Parameters3/5

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

  Schema coverage is 100% and the schema description already explains that accountId is the id from list_accounts, not login. The tool description repeats this, adding no new parameter semantics beyond what the schema provides. 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 lists open positions on one MT5 account, with a specific verb and resource. It distinguishes from sibling tools like list_pending_orders and list_deals by focusing on positions, and adds scope details ('read live from the terminal').

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

  Usage Guidelines4/5

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

  The description provides a clear prerequisite: accountId must be the id from list_accounts, not login. It implies when to use the tool (to see open positions) and how to use the output (ticket for closing). However, it does not explicitly mention alternatives or when not to use it.

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

• get_account_performanceA
  4.5/5.0
  Behavior4/5

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

  Beyond the readOnlyHint annotation, the description adds useful behavioral context: the response is a fixed-size summary that does not grow with the window, and a null live block means the terminal was unreachable (not that the account is empty). It also clarifies the ambiguous reporting parameter. No contradiction with annotations.

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

  Conciseness5/5

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

  The description is concise yet dense, front-loaded with the core purpose, followed by a compact list of included metrics, then practical usage notes. Every sentence adds value—parameters, defaults, null handling, and a common pitfall—without fluff or redundancy.

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

  Completeness5/5

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

  For a summary tool with an output schema, the description fully covers what the agent needs to know: the exact metrics returned, the default time window, default currency, the accountId pitfall, and the meaning of a null live block. Given the low complexity (no nested objects) and rich schema/output schema, this is highly 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?

  Schema coverage is 100%, so parameters are documented, but the description adds valuable semantic clarifications: accountId is the id field from list_accounts, NOT the login; reporting is a currency code (default USD), not a period; from/to are in UTC YYYY-MM-DD. This goes beyond the schema's descriptions and addresses likely user confusion.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Summarize how one MT5 account has performed over a date window' and enumerates the specific metrics returned (net P&L, win rate, profit factor, etc.). It explicitly labels itself as 'the default tool for any performance question,' distinguishing it from sibling listing tools like list_deals and list_positions.

  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 concrete usage guidance: default 30-day window when from/to are omitted, reporting is an ISO-4217 currency code not a period, and accountId must come from list_accounts (not login). It names the tool as the default for performance questions, implying alternatives for other needs, but does not explicitly mention when-not to use it or name sibling alternatives.

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

• list_accountsA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only nature is covered. The description adds transparency about what the tool returns (id, login, broker, balance, equity, sync state, strategies) and the critical id-vs-login distinction, going beyond annotation-only disclosure.

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

  Conciseness5/5

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

  Three sentences with no wasted words: the first states the action, the second enumerates return fields, and the third delivers essential integration guidance. It is front-loaded, compact, and every sentence earns its place.

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

  Completeness5/5

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

  With zero parameters and an output schema available, the description fully covers what an agent needs: what accounts are included, what data is returned, and how the returned `id` connects to other tools. No gaps are apparent for the tool's intended read-only listing use case.

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

  Parameters4/5

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

  The tool has zero parameters, so the baseline is 4 per the rubric. The description appropriately focuses on output semantics and the meaning of the returned `id` field instead, which is more valuable than parameter details in this case.

  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: 'List the MT5 trading accounts linked to the configured Senti Quant API key.' It clearly defines the tool's scope and purpose, and the lack of sibling tools removes any differentiation concern.

  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?

  There are no explicit alternative tools to compare against, but the description gives practical usage context by explaining that the returned `id` field is the accountId required by every other Senti endpoint. This implicit guidance about when to use the tool and how to use its output earns above-average marks.

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

• list_account_strategiesA
  4.5/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true and openWorldHint=true, so the read-only nature is known. The description adds useful context about the returned data (symbol, timeframe, status) and the accountId caveat. No contradictions; missing only minor details like error behavior or pagination, which are less critical given the output schema exists.

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

  Conciseness5/5

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

  Three sentences, each delivering distinct value: purpose, accountId clarification, and alternative tool reference. No fluff or repetition, well front-loaded with the core function.

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

  Completeness5/5

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

  Given the simple list tool, rich annotations, existing output schema, and exact parameter guidance, the description is fully complete. It covers purpose, usage, parameter caveats, and alternatives without needing to explain return values since an output schema is present.

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

  Parameters3/5

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

  Schema coverage is 100% and the schema already documents accountId as the id field from list_accounts, not the MT5 login. The description reiterates this same information, adding no new meaning beyond the schema; thus 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 lists strategies (expert advisors) deployed on one MT5 account, including symbol, timeframe, and status. It distinguishes this from the platform-wide catalog via the explicit reference to list_strategies, making sibling differentiation clear.

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

  Usage Guidelines5/5

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

  The description provides explicit guidance on when to use this tool versus list_strategies, and clarifies the exact accountId format with a warning against using login. This gives the agent clear context and exclusion criteria for tool selection.

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

• list_pending_ordersA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds valuable behavioral context: reads live from the terminal, zero-valued sl/tp/priceStopLimit meaning not set, and ticket being the cancellation handle. This goes beyond annotations without contradicting them.

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

  Conciseness5/5

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

  Three sentences, each earning its place: core purpose, live-read clarification, unfilled-vs-filled distinction and alternative, parameter guidance, and zero-value semantics. No redundant or filler content.

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

  Completeness5/5

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

  Given the simple one-parameter tool, presence of an output schema, and thorough annotations, the description covers all necessary context: purpose, usage, edge cases (zero values), and cross-reference to list_positions. Nothing missing.

  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 covers 100% of parameters and already explains accountId as the id field from list_accounts and not login. The description repeats this guidance, providing no additional meaning beyond the schema. Baseline 3 is appropriate for full schema coverage.

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

  Purpose5/5

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

  The description clearly states the tool lists pending limit and stop orders on one MT5 account, with a specific verb ('List') and resource ('pending limit and stop orders'). It distinguishes from related tools by explicitly noting these are unfilled orders, unlike list_positions for open positions.

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

  Usage Guidelines5/5

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

  Provides clear when-to-use context: it explains that the tool reads live pending orders and explicitly offers an alternative, 'use list_positions' for filled positions. Also clarifies the correct accountId parameter and how to interpret ticket for cancellation.

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

• get_authoring_conventionsA
  4.9/5.0
  Behavior5/5

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

  Beyond the readOnlyHint annotation, the description adds behavioral specifics: the response is small (~2 KB) and static per deploy, and forbiddenConstructs[].pattern values are regular expressions reported verbatim without evaluation. These details give an agent accurate expectations about call cost, response stability, and the tool's pass-through behavior, all of which are not visible in annotations or the empty input 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?

  Every sentence earns its place. The first sentence defines the resource, the second gives a direct action, the third provides the cost rationale, and the final two disclose response size and regex handling. The content is front-loaded with the most important information and uses imperative language for the critical instruction.

  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?

  The description is complete for a read-only, zero-parameter tool. An output schema exists, so return-value detail is not the description's responsibility, but it still tells the agent the response is small, static, and that regexes are verbatim. The sibling-tool context shows no overlap, so no alternative-routing information is needed. An agent knows exactly when to call it and what to expect.

  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 the baseline is 4. The description does not need to explain parameter meanings; instead it clarifies what the returned data represents, which is the closest equivalent. It names the four content categories and the pattern semantics, adding meaning beyond the empty schema.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Read the Senti Quant MQL5 authoring contract as data'. It enumerates four concrete components of that contract and the platform limits on draft count and source size. This clearly differentiates it from all sibling tools, which deal with drafts, accounts, brokers, strategies, positions, and performance—not authoring rules.

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

  Usage Guidelines5/5

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

  The description gives an explicit, imperative trigger: 'CALL THIS BEFORE GENERATING ANY MQL5 SOURCE.' It also explains the cost of ignoring that guidance: rule-breaking code is rejected by a static scan before the compiler, and compile slots are globally serial, making compile-time discovery expensive. This is unambiguous when-to-use guidance with a clear rationale.

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

• get_equity_timeseriesA
  4.9/5.0
  Behavior5/5

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

  Beyond the annotations (readOnlyHint, openWorldHint), the description discloses key behavioral traits: the series is downsampled to at most 200 points, but first/last/deepest-drawdown points are always retained. It explains the `notes` field records downsampling and warns that short moves may not be visible. It also tells users to read `caveats` and `portfolioCaveats` before quoting numbers, which is critical for data quality.

  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 dense but well-structured: purpose first, then alternatives, then downsampling behavior, then parameter clarifications. Every sentence adds value, though the length is substantial. The all-caps 'THIS RESPONSE IS SHAPED' is attention-grabbing but slightly jarring; however, it emphasizes an important limitation. Overall it's appropriately sized for a tool with these nuances.

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

  Completeness5/5

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

  Given the output schema exists and annotations are present, the description covers all necessary operational context: how the response is shaped, downsampling rules, the meaning of `notes` and `caveats`, and parameter gotchas. It leaves no major ambiguity about selecting, invoking, or interpreting the tool's results.

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

  Parameters5/5

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

  The input schema already describes parameters, but the description adds crucial disambiguation: `accountId` is the `id` field from list_accounts (NOT `login`), and `reporting` is an ISO-4217 currency code, not a reporting period. It also notes omitting from/to gives the last 30 days. These clarifications prevent common misuse and go well beyond the schema's stated 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 starts with a specific verb and resource: 'Return the reconstructed equity curve and floating drawdown for one MT5 account over a date window, as a series of points.' It clearly distinguishes from siblings by naming get_account_performance for whole-account figures and get_performance_breakdowns for day/symbol/hour breakdowns, so the tool's role is unambiguous.

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

  Usage Guidelines5/5

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

  Explicit guidance says when to use it ('how has my equity moved' or 'what was my worst drawdown') and when not to (for net P&L, win rate, ROI use get_account_performance; for breakdowns use get_performance_breakdowns). It also adds practical tips like omitting from/to for the last 30 days and narrowing the window for finer resolution.

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

• list_brokersA
  4.9/5.0
  Behavior5/5

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

  Annotations already indicate read-only and open-world behavior. The description adds meaningful context by explaining it is a catalog, not user-specific accounts, and shows how to consume the output for account linking. This goes beyond the annotations.

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

  Conciseness5/5

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

  The description is concise and well-structured: first states the main purpose, then clarifies scope, and finally gives practical usage guidance. Every sentence adds value without redundancy.

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

  Completeness5/5

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

  With no parameters, an output schema, and clear annotations, the description fully addresses the tool's behavior and use. It explains what is returned and how to apply it, making it complete for an agent.

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

  Parameters4/5

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

  There are no parameters, so the baseline per guidelines is 4. The description still implicitly covers the output usage, but since no parameters exist, no additional parameter semantics are needed.

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

  Purpose5/5

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

  The description clearly states the tool's function: listing supported brokers with their MT5 server names and account types. It also explicitly differentiates this from `list_accounts`, making the purpose unambiguous.

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

  Usage Guidelines5/5

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

  It provides clear usage context: this is the platform-wide catalog for linking accounts, and explicitly contrasts with `list_accounts`. It also gives actionable guidance on using output fields (`accountTypes[].id` and `servers[]`) when linking a new account.

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

• list_draftsA
  4.9/5.0
  Behavior5/5

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

  Annotations provide readOnlyHint and openWorldHint, but the description goes further by disclosing that source code, compiler logs, and diagnostics are dropped to avoid >10MB responses, that the cut content is listed in `notes`, and that there is no option to request the unshaped response. This is essential behavioral context beyond the annotations.

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

  Conciseness5/5

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

  The description is succinct yet information-dense. It front-loads the core purpose, then use cases, then the critical shaping caveat, all in four sentences. No filler or redundancy; every sentence earns its place.

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

  Completeness5/5

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

  With an output schema present, the description need not repeat return types, but it adds critical context about dropped fields and size limits that the schema cannot convey. It also covers usage scenarios, ordering, and alternatives, making it complete for an agent to correctly select and invoke this 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?

  There are zero parameters, so baseline is 4 per rubric. The description doesn't need to explain parameters, but it effectively communicates the response shape and its implications. Since the schema has no properties to describe, the description adds value by clarifying output details, which is more relevant to contextual completeness.

  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 (List), the resource (MQL5 drafts), and ownership scope (this API key owns). It also specifies ordering (most recently updated first) and the fields included. It differentiates from siblings by naming get_draft and list_draft_attachments as alternatives for specific needs.

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

  Usage Guidelines5/5

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

  Explicitly tells the agent when to use this tool: to find a draftId, answer 'what am I working on', or identify broken drafts. It also points to sibling tools (get_draft, list_draft_attachments) for source/attachment retrieval, giving clear when-to-use vs. when-not-to-use guidance.

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

• list_strategiesA
  4.9/5.0
  Behavior5/5

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

  Beyond the readOnlyHint and openWorldHint annotations, the description adds key behavioral context: this is the global catalog of what COULD be deployed, not what is account-specific. It also clarifies the meaning of the returned `id` with a deployment instruction, preventing misinterpretation.

  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 composed of two sentences, each serving a distinct purpose: stating the main action, then providing caveat and alternative, then a deployment tip. It is front-loaded and every sentence earns its place.

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

  Completeness5/5

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

  With no parameters, an output schema present, and annotations confirming safe read-only behavior, the description fully covers the tool's purpose, scope, and usage context. It even includes a helpful cross-reference and usage tip, making it complete for the tool's complexity.

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

  Parameters4/5

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

  The tool has zero parameters, so the schema fully covers them (vacuously). The description does not need to explain parameters, and the baseline for 0 params is 4. No additional parameter semantics are required.

  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 'List' and the resource 'every strategy (expert advisor) available to deploy on Senti Quant', with specific attributes (symbols, timeframes, rating, presets). It explicitly distinguishes from the sibling tool list_account_strategies, making the purpose unambiguous.

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

  Usage Guidelines5/5

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

  The description explicitly tells when to use this tool (platform-wide catalog of deployable strategies) and when not to (not currently running on an account), and names the alternative list_account_strategies. It also provides a concrete usage hint: 'Use `id` as `eaDefinitionId` when deploying.'

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

• get_draftA
  5/5.0
  Behavior5/5

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

  Even though readOnlyHint=true is already annotated, the description adds significant behavioral warnings: the response can be extremely large (up to ~105,000 tokens) because content is returned twice, attachment source code is excluded, and only attachment metadata is included. This gives the agent crucial execution-hazard information beyond the annotations.

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

  Conciseness5/5

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

  Although it is longer than average, every sentence contributes: what is returned, why to use it, how to reference the parameter, the large-response warning, the attachment behavior, and the cheaper alternative. The most important caveat, response size, is highlighted and placed prominently.

  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 read operation with an output schema and readOnlyHint annotations, the description provides all the context an agent needs: return contents, size hazard, attachment source exclusion, and sibling routing. The attachment exclusion is especially important because otherwise an agent would assume the returned source includes attachment code.

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

  Parameters5/5

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

  The schema offers 0% description coverage, so the description carries the full burden of explaining the only parameter. It directly defines `draftId` as the `id` field from list_drafts, which is precise, actionable, and sufficient for an agent to invoke the tool correctly.

  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 and resource, 'Read one MQL5 draft', and lists exactly what the tool returns: source code, compiler log, diagnostics, and compile-match status. It distinguishes itself from sibling tools by explicitly saying how it differs from list_drafts and list_draft_attachments. This allows an agent to confidently select it for showing code or diagnosing compile failures.

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

  Usage Guidelines5/5

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

  It explicitly tells the agent when to call it: to answer 'why did this fail to compile' or 'show me the code'. It also gives routing alternatives: use list_draft_attachments for attachment source code and list_drafts for a cheap overview. This is strong, actionable usage guidance.

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

• get_performance_breakdownsA
  5/5.0
  Behavior5/5

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

  Discloses response shaping: chart-sized payload, dropped running totals, at most ten symbols kept, hourly grid totalled across the window, and the use of `notes` to signal truncation. This is significant behavioral context far beyond the readOnlyHint/openWorldHint annotations, and it does not contradict any annotation.

  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 paragraph is dense but every clause serves a purpose: purpose, use case, alternative, shaping warning, and parameter clarifications. It is front-loaded with the core breakdown, then practical guidance, and no filler words. The length is justified by the tool's complexity.

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

  Completeness5/5

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

  Given the tool's complexity, the description covers the main output structure (three series), the shaped/truncated behavior, the most important parameter pitfalls, and the recommended alternative tool. Combined with the rich schema and annotations, this leaves no major contextual gap for agent selection or invocation.

  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?

  Even though schema coverage is 100%, the description adds meaningful parameter semantics: explains that omitting `from`/`to` defaults to the last 30 days, that a narrower window is the remedy for truncated symbols, and clarifies that `reporting` is a currency code, not a reporting period. These go beyond the 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 a specific verb and resource: 'Break one MT5 account down three ways over a date window' and enumerates the exact breakdown series (day-by-day P&L/volume/notional, per-symbol P&L/deal-count, hourly P&L). It further differentiates from the sibling tool get_account_performance by explicitly stating that is for a single whole-account figure.

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

  Usage Guidelines5/5

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

  Provides explicit use cases ('which symbol is losing me money', 'what hour do I trade worst') and explicitly names the alternative tool for whole-account performance. It also gives practical guidance on date window omission and using a narrower window to reveal cut symbols.

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

• list_dealsA
  5/5.0
  Behavior5/5

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

  Despite readOnlyHint and openWorldHint annotations, the description adds substantial behavioral context: pagination is manual ('never pages on its own'), exactly one page per call, cursor semantics, and limit defaults/ceiling. It also clarifies that the response reports availability of more deals via a cursor, and that entry is lowercase in the parameter unlike the response field. This goes well beyond annotation signals.

  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?

  Every sentence earns its place. The description starts with the core purpose, then moves to alternatives, pagination rules, and filter guidance. It is appropriately sized for a paginated, filterable tool with six parameters and a cursor, and the structure is logical and easy to scan.

  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?

  The tool is complex (pagination, cursor, multiple filters, sibling differentiation), but the description addresses all key behaviors: what is returned, how pagination works, how to narrow results, and which parameters to use. The existence of an output schema reduces the need to spell out return fields, and the description still lists the main deal attributes. It is fully complete for an agent to invoke correctly without guessing.

  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 already covers all six parameters (100% coverage), but the description enriches each: accountId is explicitly tied to list_accounts.id 'not login', entry warns about lowercase vs uppercase response field, from/to require ISO-8601, limit is per-page not total, and cursor is opaque and must be reused. These clarifications prevent common misuse and are not present in the schema alone.

  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 begins with a specific verb-resource-scope pair: 'List the closed deal history of one MT5 account — the fills that already happened, newest first' and enumerates the fields returned. It clearly distinguishes itself from sibling tools by naming list_positions and list_pending_orders for open/resting state and get_account_performance for aggregates.

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

  Usage Guidelines5/5

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

  Explicit when-to-use vs alternatives: 'For what is open right now use list_positions, and for orders still resting use list_pending_orders. For totals and ratios over a period use get_account_performance rather than adding these rows up.' It also gives pagination guidance and filter-narrowing advice, so the agent knows exactly when to choose this tool and how to use it effectively.

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

• list_draft_attachmentsA
  5/5.0
  Behavior5/5

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

  Annotations cover readOnlyHint and openWorldHint, but the description adds crucial behavioral details: the 64 KiB budget, the response size warning (~33k tokens), handling of duplicate filenames (first only, notes skipped count), and the note about truncation. This goes well beyond annotations and is fully transparent.

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

  Conciseness5/5

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

  While long, every sentence serves a purpose: main function, parameter behavior, edge cases, size warning, and alias. Information is front-loaded and logically ordered, with the critical warning in caps. Efficient and well-structured.

  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?

  The description fully covers all invocation scenarios (with and without filename), duplicates, budget limits, and what the tool does not return. An output schema exists, so no need to detail return fields. Nothing essential is missing for correct invocation.

  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 0%, so the description bears full responsibility. It explains draftId as the id from list_drafts and filename as an exact-name filter with clear semantics (including the omission case). This adds meaning that the schema lacks entirely.

  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 (read) and resource (indicator source files a draft's EA embeds via #resource), and explicitly contrasts with get_draft. It distinguishes itself from siblings 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 Guidelines5/5

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

  The description explicitly explains when to pass filename (to read one attachment whole by exact name) and when to omit it (to get all sources up to a budget), and directs users to get_draft for the EA's own source. It also clarifies how to handle non-unique filenames.

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