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

Beyond the readOnlyHint annotation, it discloses meaningful behavior: the summary is fixed-size and does not grow with the window, and a null live block means the terminal was unreachable rather than the account being empty. These are exactly the kind of non-obvious behavioral details an agent needs.

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

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

Every sentence earns its place: the first defines the tool's output, the second establishes its default role, and the remaining sentences clarify parameter gotchas and null semantics. The most important usage guidance is front-loaded, with no filler.

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

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

Given the output schema exists, the description does not need to spell out return fields, yet it still covers defaults, parameter identity traps, and the live-block null meaning. For a read-only summary tool with one required parameter, this is fully sufficient for an agent to invoke it correctly.

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

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

Schema coverage is 100%, but the description adds essential disambiguation: accountId is the id from list_accounts and not the MT5 login, reporting is a currency code rather than a reporting period, and omitting from/to defaults to the last 30 days. This goes well beyond the schema's own descriptions.

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

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

The description names a specific verb (summarize), a specific resource (one MT5 account over a date window), and enumerates the exact metrics returned (net P&L, win rate, profit factor, gross profit/loss, deal counts, etc.). It also explicitly positions itself as the default tool for performance questions, which distinguishes it from breakdown and timeseries siblings.

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

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

The description clearly says this is the default tool for any performance question and explains that the response stays fixed-size regardless of window length, which guides selection. It also gives concrete invocation guidance like omitting from/to for the last 30 days, but it does not name specific sibling alternatives to use instead for specialized performance breakdowns.

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

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.

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.

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.

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.

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.

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.

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

Annotations declare readOnlyHint=true and openWorldHint=true, and the description complements them by disclosing the potentially huge response size (up to ~105,000 tokens), the duplication of content, and the exclusion of attachment source. These are significant behavioral details beyond the annotations, and there is no contradiction.

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

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

The description is longer than average but every sentence earns its place: the core purpose is front-loaded, the size warning is critical and placed early, and the sibling alternatives are at the end. The structure is logical and scannable; a slight trim could improve conciseness but it remains efficient.

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

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

Given the output schema exists (though not shown) and the annotations cover safety, the description fully equips the agent: it covers the payload contents, response size, what is not included, and when to use alternatives. No critical information is missing for correct invocation.

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

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

Schema coverage is 0%, so the description must compensate. It explains that draftId is the id field from list_drafts, which gives the agent a concrete way to obtain a valid value. It doesn't describe format constraints, but for a single string parameter that's sufficient; it adds meaningful context beyond the bare schema.

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

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

The description clearly states the action ('Read one MQL5 draft') and the resource, enumerating the exact payload fields (source code, compiler log, diagnostics, compile-match status). It explicitly differentiates from siblings by naming list_drafts and list_draft_attachments and explaining what each offers, so an agent can unambiguously pick this tool.

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

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

The description provides explicit use cases ('why did this fail to compile', 'show me the code'), states the parameter source (draftId from list_drafts), and gives clear alternatives with conditions: list_drafts for a cheap overview, list_draft_attachments for attachment code. This is comprehensive routing guidance.

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

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.

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.

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.

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.

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.

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.

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

The description discloses response shaping that annotations don't cover: per-account rows and running totals are dropped, at most ten symbols are kept, the hourly grid is totalled, and cuts are reported in `notes`. It also warns to read `notes` before concluding a symbol was untraded and notes that narrowing the window reveals cut symbols. This adds substantial behavioral context beyond readOnlyHint=true and openWorldHint=true, and does not contradict them.

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

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

The description is dense but front-loaded: purpose first, then usage guidance, then behavioral caveats, then parameter disambiguation. A few phrases like 'THIS RESPONSE IS SHAPED.' are slightly opaque and the accountId warning repeats the schema, but no sentence is pure filler.

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

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

With an output schema present and readOnly/openWorld annotations, the description covers all operational essentials: what data is returned, how it may be truncated, how to detect cuts, default time window, and the accountId-vs-login trap. An agent has everything needed to invoke the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds non-redundant meaning: omitting `from`/`to` defaults to the last 30 days, `reporting` is disambiguated from a reporting period, and accountId is re-emphasized as list_accounts.id, not login. Some duplication exists with schema descriptions, but the default-window behavior is genuinely new.

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

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

The description states a precise action: breaking one MT5 account into three series (day-by-day P&L/volume/notional, per-symbol P&L/deal-count, and P&L by hour) over a date window. It also names the sibling get_account_performance and explicitly says what this tool is not (a single whole-account figure), making it easy to distinguish without opening schemas.

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

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

It gives concrete example questions ('which symbol is losing me money', 'what hour do I trade worst') for when to use it, and directs the agent to get_account_performance for single whole-account figures, calling it 'the default for a performance question.' This is explicit when/when-not guidance with a named alternative.

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

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

Annotations already declare readOnlyHint=trueabc and openWorldHint=true, so the read-only safety profile is covered. The description adds meaningful behavioral context by stating exactly what each returned account entry contains and that `id` is the accountId used by other endpoints, which 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.

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

The description is two sentences with no filler: the first states the action and scope, the second lists the output fields and adds the critical id/login distinction. Every sentence provides necessary information and the most important usage detail is front-loaded.

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

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

For a zero-parameter, read-only list tool with an output schema, the description is complete. It identifies the resource, the output fields, and the cross-tool meaning of `id`. No additional pagination or ordering details are necessary for correct invocation.

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

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

Parameter count is 0 and schema coverage is 100%, so the baseline is 4. The description goes further by explaining the meaning and downstream use of the returned `id` field, which is effectively the most important semantic information an agent needs for parameterizing future calls.

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

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

States a specific verb ('List') and a specific resource ('MT5 trading accounts linked to the configured Senti Quant API key'), then enumerates the returned fields. It clearly differentiates from siblings like list_brokers and list_account_strategies by identifying exactly which account-level data is returned.

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

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

The description makes the tool's role obvious: it is the way to discover linked MT5 accounts and obtain the canonical accountId. It gives downstream guidance ('pass id, not login') that helps an agent choose and use the result correctly. It does not explicitly name sibling alternatives or exclusions, but the context is otherwise clear.

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

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

Annotations already provide readOnlyHint and openWorldHint, so the description does not need to repeat safety properties. It adds useful behavioral context beyond them by clarifying that this returns only strategies deployed on the account and that accountId must be the id field, not the MT5 login. The description is consistent with the annotations and does not contradict them.

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

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

The description is compact and front-loaded: the first sentence states what the tool does and what it returns, the second sentence prevents a common input error, and the third sentence routes to the sibling tool. Every sentence earns its place, with no filler or repetition of annotation properties.

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

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

Given a single required parameter, an output schema, and annotations that cover the safety profile, the description provides everything an agent needs to call the tool correctly. It explains the output fields, clarifies the critical accountId semantics, and disambiguates against list_strategies. There is no meaningful gap in context.

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

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

The input schema already documents the accountId parameter at 100% coverage, so the baseline is 3. The description goes further by explicitly warning that login is the MT5 account number and is not a valid accountId, and by tying accountId to the output of list_accounts. This adds practical meaning beyond the schema's simple field description.

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

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

The description states a specific verb ('List') and resource ('strategies (expert advisors) currently deployed on one MT5 account'), and even enumerates the output fields (symbol, timeframe, status). It clearly distinguishes this from the sibling list_strategies by saying that list_strategies is the platform-wide catalog.

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

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

The description explicitly names the alternative tool for a different use case: 'For the platform-wide catalog of strategies available to deploy, use list_strategies instead.' It also clarifies the correct input source for accountId, telling the agent to take it from list_accounts rather than using the MT5 login, which prevents a common invocation error.

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

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.

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.

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.

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.

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.

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.

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

Annotations declare readOnlyHint=true and openWorldHint=true, already conveying safety and variability. The description adds valuable behavioral detail: endpoint is paginated, limit defaults to 50/max 500, one call returns one page, tool never pages on its own, cursor semantics, and case sensitivity for entry. It does not go into rate limits or error scenarios, but given annotation coverage, the description adds substantial non-redundant context.

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

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

The description is about 150 words, well-structured: purpose first, then sibling routing, then accountId note, then pagination, then narrowing advice. Every sentence adds functional value; there is no fluff. The most critical info (what it does and when to use it) is front-loaded.

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

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

Given the tool's complexity (6 params, pagination, output schema exists), the description covers: what it returns, how to navigate pagination, how to narrow results, and how to identify the account correctly. It also directs users to appropriate alternatives. Output schema is present so return structure is not needed in the description. This is a complete and self-sufficient definition for an agent.

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

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

Schema coverage is 100% — every parameter already has a description. The tool description reinforces and contextualizes: clarifies accountId is the id from list_accounts not login (though schema says the same), adds the 'one call returns exactly one page' nuance for limit, explains cursor as nextCursor from a previous call, and emphasizes lowercase for entry. This goes beyond mere repetition by tying parameters to the pagination behavior, though some of it mirrors schema text.

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

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

States a specific verb ('List') and resource ('closed deal history of one MT5 account'), enumerates the fields returned (symbol, direction, entry kind, volume, price, realized profit, costs, time), and explicitly distinguishes from siblings list_positions, list_pending_orders, and get_account_performance. An agent can immediately grasp what this does and how it differs.

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

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

Explicitly names alternatives and when to use them: '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.' Also provides clear guidance on pagination (must call again with cursor) and advises narrowing (via entry and from/to) instead of paging. This is textbook usage guidance.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds substantial behavioral detail: duplicate filenames return only the first with `notes` indicating skipped count, truncated lists are reported via `notes`, and responses can reach roughly 33,000 tokens. It also clarifies what the tool never returns, which is valuable beyond the structured fields.

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

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

The description is dense but every sentence earns its place: purpose, parameter behavior, budget limits, duplicate handling, response size warning, and the sibling alternative. Key operational constraints are front-loaded before the large-response warning.

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

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

For a read tool with two parameters, an output schema, and read-only annotations, the description covers all critical decision factors: how to select an attachment, what happens with duplicates, budget truncation, response size, and the distinction from get_draft. Nothing needed for correct invocation is missing.

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

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

Schema description coverage is 0%, so the description carries full parameter documentation. It defines `draftId` as the `id` field from list_drafts and explains that `filename` is an exact name used to read a single attachment or one omitted by the default call, including omitted-parameter behavior.

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

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 indicator source files a draft's EA embeds via `#resource`.' It clearly differentiates from the sibling get_draft by stating 'this tool never returns' the EA's own source, so an agent can select it correctly.

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

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

It explicitly explains when to pass `filename` versus omit it, including the exact-name matching behavior and the 64 KiB budget fallback. It also names the alternative for a related need: 'Use get_draft for the EA's own source.'

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

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

Annotations already mark readOnlyHint, and the description adds meaningful behavior beyond that: the list carries sizes and hashes rather than bodies, and a non-null compileLogBytes is explained even when diagnosticsCount is 0. This gives the agent important interpretation context that annotations alone would not provide.

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

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

The description is dense but well-organized: the core action and ordering are front-loaded, followed by use cases, payload constraints, and sibling routing. Every sentence adds useful selection or interpretation detail with no filler.

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

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

For a zero-parameter tool with an output schema, the description fully covers purpose, usage context, response content, and alternatives. An agent has everything needed to decide when to call it and how to interpret the results.

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

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

The input schema has zero properties, so there are no parameter meanings for the description to clarify. The description appropriately focuses on what the response contains, which is the relevant semantic information for a parameterless listing tool.

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

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

The description states a specific verb and resource ('List the MQL5 drafts this API key owns'), specifies ordering ('most recently updated first'), and enumerates the returned fields. It also distinguishes itself from get_draft and list_draft_attachments by explicitly stating what it does not include.

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

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

It provides concrete use cases: find a draftId, answer 'what am I working on' and 'which of my drafts are broken', or check if a held copy is current. It names the alternative tools for deeper content and tells the agent when to call them.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds substantial context beyond that: the data is 'read live from the terminal' (volatility/freshness), the 'NOT been filled' scope constraint, that each order's `ticket` is the handle used to cancel it, and the crucial semantics that an `sl`, `tp`, or `priceStopLimit` of 0 means the level is unset. This materially enriches what an agent needs to interpret results correctly.

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

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

The description is a dense multi-sentence block, but every sentence earns its place: scope, returned fields, the exclusion of filled orders, the accountId clarification, ticket usage, and zero-value semantics. It is appropriately sized for the information it carries, though it front-loads the core purpose well in the opening clause. No filler or redundancy.

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

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

The tool has an output schema (so return values need no elaboration) and annotations covering the safety profile. The description covers what is returned, what is excluded, accountId semantics, ticket-as-cancellation-handle usage, and zero-value field meanings. For a single-parameter list tool, essentially everything an agent needs to call it correctly and interpret results is present.

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

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

Schema description coverage is 100% — the schema itself already documents accountId as 'The `id` field from list_accounts. Not the `login` (MT5 account number).' The description repeats this same guidance ('accountId is the id field from list_accounts, NOT login') without adding new information. This is useful reinforcement but adds no value beyond the schema, so the baseline 3 is appropriate.

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

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

The description states a specific verb ('List'), a precise resource ('pending limit and stop orders resting on one MT5 account'), and the scope ('one MT5 account', 'read live from the terminal'). It enumerates the returned fields (symbol, order type, volume, trigger price, stop loss, take profit) and explicitly distinguishes itself from list_positions by clarifying these are unfilled orders. This fully differentiates it from siblings.

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

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

The description explicitly names the alternative tool (list_positions) and the condition that selects it ('for filled positions currently open'). It also disambiguates the accountId parameter by warning it is the `id` field from list_accounts, NOT `login`. Both the when-to-use and the common pitfall are addressed explicitly.

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

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

Annotations already declare readOnlyHint=true, and the description adds valuable behavioral context: it clarifies that sl/tp=0 means no stop loss/take profit is set, and that the ticket field is the handle for closing positions. It also reiterates the accountId caveat. These details go beyond the annotation's safety profile and help the agent interpret the output correctly.

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

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

The description is two sentences with zero fluff. It front-loads the primary purpose, then delivers critical caveats about accountId, ticket, and sl/tp semantics. Every sentence earns its place, and the structure is highly scannable.

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

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

The tool is simple (single parameter), has an output schema, and annotations covering safety. The description explains the return field semantics (sl/tp=0, ticket handle) and the accountId caveat, covering everything an agent needs to call it correctly and interpret results. No missing essential context for a read-only list operation.

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

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

Schema coverage is 100% – the schema already describes accountId as the id field from list_accounts, not the login. The description repeats this caveat, adding no new semantic information. However, the description's explanation of output fields (ticket, sl/tp) indirectly reinforces the parameter's purpose. Baseline 3 is appropriate because the schema fully covers the parameter.

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

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 a single MT5 account, enumerates the returned fields (symbol, direction, volume, prices, SL/TP, swap, floating profit), and distinguishes it from siblings like list_pending_orders and list_deals by specifying 'open positions.' The verb and resource are explicit, and the 'read live from the terminal' phrase adds context.

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

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

The description provides clear context (positions currently open, live from terminal) and important usage guidance (accountId is the id field, not login; ticket is the close handle). It does not explicitly exclude alternatives like list_pending_orders or list_deals, but the resource distinction is sufficiently clear. The lack of an explicit when-not statement prevents a 5.

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

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

Annotations already provide readOnlyHint=true and openWorldHint=true, covering the safety and open-world nature of the call. The description adds useful behavioral context beyond annotations: it returns what COULD be deployed, not what is running, lists the included fields (symbols, timeframes, rating, presets), and explains id semantics. It could mention pagination or rate limits, but with zero parameters and an output schema, the burden is low.

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

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

Three sentences with every clause earning its place: the core action and contents, the scope warning, and the sibling routing plus deployment hint. It is front-loaded with the most important information and contains no filler.

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

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

For a zero-parameter, read-only list operation with an output schema and safety annotations, this description is complete. It explains scope, content, the key sibling distinction, and how the returned id should be used downstream. There are no material gaps for an agent to call it correctly.

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

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 still adds a meaningful semantic hint by telling agents to use `id` as `eaDefinitionId` when deploying, which helps connect this catalog to deployment even though the tool itself takes no parameters.

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

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

The description states a specific verb and resource: 'List every strategy (expert advisor) available to deploy on Senti Quant.' It explicitly says this is the platform-wide catalog, distinguishing it from list_account_strategies. An agent can immediately understand exactly what the tool returns and how it differs from siblings.

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

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

It clearly states when to use this tool: to see the platform-wide catalog of deployable EAs, not what is currently running. It names the alternative, list_account_strategies, for account-specific strategies, and gives a concrete deployment hint about using `id` as `eaDefinitionId`. No ambiguity remains.

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