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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the description need not restate mutation/destruction. The description adds the account-type restriction, which is a usage constraint rather than behavioral disclosure. With annotations covering the destructive nature, the description's contribution is minimal but not misleading, so a 3 is appropriate.

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 single, front-loaded sentence that states the action and the critical constraint with zero filler. Every word earns its place, making it efficient and easy to parse.

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 simple two-parameter tool with annotations and no output schema, the description covers the essential context: the operation and the simulated-accounts restriction. It does not explain 'working order' or the exact meaning of orderId, but these are likely implicit given the domain. Minor gaps remain, but overall it is adequate.

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 50%: accountId has a useful description ('Trading account ID from list_accounts'), but orderId has none. The tool description provides no parameter-specific information and does not compensate for the missing orderId description. An agent would have to infer orderId's meaning from the tool name, which is not explicit.

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 ('Cancel a working order') with a specific verb and resource, distinguishing it from siblings like modify_order and close_position. The explicit constraint 'Simulated (non-follower) accounts only' further sharpens the purpose and differentiates it from any follower-account order tools.

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 an explicit condition for use: 'Simulated (non-follower) accounts only.' This tells the agent when the tool is applicable, but it does not mention alternatives or when not to use it beyond that condition. Still, it gives clear context that narrows the selection among siblings.

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 signal mutation/destruction, but the description adds crucial behavior beyond that: the close executes at market and does NOT cancel resting stop/target orders. It also instructs the agent to check and cancel leftovers, which materially changes how the tool should be used.

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?

Two short sentences with no filler: the main action comes first, and the critical caveat and follow-up action are second. Every sentence adds operational value.

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 destructive market-close tool with rich schema descriptions and safety annotations, the description covers what the tool does, what it does not do, and what to do next. No output schema exists, but an agent has enough 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 description coverage is 100%, so the schema already documents accountId, contractId, and reason. The description reinforces that contractId refers to the contract whose whole position is flattened, but it does not add substantial parameter-level meaning beyond the 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?

States a specific verb and resource: flatten the whole position in a contract at market. 'Whole' and 'at market' clearly distinguish this from partial_close_position and other order-related 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?

Provides clear context for when to use it (flatten whole position) and an explicit behavioral warning with follow-up routing to list_open_orders and cancel_order. It does not explicitly name partial_close_position as the alternative for partial closes, but 'whole position' makes that boundary 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 declare readOnlyHint and openWorldHint, so the description does not need to restate safety. It adds valuable context by specifying the included fields and defining the trading day boundary (17:00 America/Chicago), which affects how realized P&L and the loss limit should be interpreted.

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?

Two sentences with no filler: the first packs the full content list plus the timezone qualifier, and the second states the intended use. The most decision-relevant information 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 single-parameter read-only snapshot, the description adequately covers inputs, output contents, and usage context. The lack of an output schema is mitigated by the explicit enumeration of the snapshot's components.

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 only parameter, accountId, already has a descriptive schema entry ('Trading account ID from list_accounts'), and schema description coverage is 100%. The description adds no extra parameter-level detail, so the baseline 3 applies.

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 'One-call view of an account' and enumerates the exact contents: balance, open positions, working orders, today's realized P&L, and daily loss limit. This clearly distinguishes it from narrower siblings like list_open_positions or get_performance by emphasizing the composite snapshot nature.

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 closing instruction, 'Use this to monitor between decisions,' gives a clear usage context for a monitoring tool. It does not explicitly name alternatives or state when not to use it, but the intended context is unambiguous enough for an agent.

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 the operation as read-only, and the description adds genuinely useful behavioral context: max 20,000 bars, rate limit 50 requests per 30 seconds, default endTime=now, default startTime covering limit bars, and UTC timestamps. This goes well beyond the annotations and helps an agent predict limits and side effects.

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 information-dense sentences with no repetition or filler. The core purpose is front-loaded, followed by field meanings and then limits/defaults.

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?

This is an 8-parameter tool with no output schema, and the description is not complete enough. live and includePartialBar are never explained, and the output structure is only partially covered via field labels. The defaults and limits are useful, but an agent cannot fully reason about live bars or partial-bar behavior.

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 only 25%, so the description carries extra responsibility. It explains endTime/startTime defaults and the limit cap, but it leaves live, includePartialBar, and unit semantics essentially unexplained in both the description and the 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 identifies the operation as retrieving OHLCV bars for a contract and adds ordering ('oldest→newest'), so an agent can tell it apart from quote or contract tools. It does not explicitly contrast itself with get_quote, but the historical-bars framing is strong enough.

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 implies this tool is for historical OHLCV data, but it provides no explicit when-to-use or when-not-to-use guidance versus siblings like get_quote or search_contracts. Defaults and limits are operational details, not selection criteria.

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, so safety is covered. The description adds cardinality ('one contract') and specific returned fields, but does not disclose error behavior or what happens for an invalid ID. This is acceptable but not rich behavioral context.

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

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

A single, tight sentence that front-loads the action and resource while packing the relevant returned attributes into a parenthetical. There is no filler or repeated title text.

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 simple one-parameter lookup with read-only annotations, the description and schema provide enough for correct invocation. The absence of an output schema is partially mitigated by listing the returned fields, though the full return shape is not disclosed.

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 parameter is fully documented in the schema. The parameter description adds real value beyond the schema by providing a concrete example ID and telling the agent to source it from search_contracts.

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 ('Look up'), a specific resource ('one contract by ID'), and the key returned attributes (tick size, tick value, active month). This clearly differentiates it from list/search contract tools and leaves no ambiguity about what the tool does.

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 parameter description gives explicit workflow guidance: contractId should be obtained from search_contracts. The phrase 'by ID' makes it clear this is for resolving a known contract rather than discovering contracts, though it does not explicitly name alternatives or exclusions.

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, reducing the burden on the description. The description adds useful behavioral context: metrics are net of fees, and the time window defaults to the current trading day. No contradictions 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.

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

The description is a single, tight sentence that front-loads the key metrics and ends with a clear usage cue. No filler, no repetition of schema details, and every phrase contributes value.

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 output schema, the description compensates by listing the returned performance metrics. It also notes the default time window and fee adjustment. Minor gaps remain around timestamp interpretation and per-contract grouping semantics, but for a read-only statistics tool this is reasonably complete.

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?

Only accountId has a schema description (33% coverage), so the description must compensate for the undocumented startTimestamp and endTimestamp. It does add meaning by explaining the 'time window' concept and the default (current trading day), but it omits details like timezone handling or inclusivity. Partial compensation.

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 enumerates specific performance metrics—win rate, net P&L after fees, average win/loss, profit factor, expectancy—and clarifies scope as 'overall and per contract' over a time window. This clearly identifies the resource and distinguishes it from siblings like get_quote or get_bars, even without an explicit verb.

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?

'Use it to grade your own trading' provides clear contextual intent for when the tool is appropriate. It does not explicitly name alternatives or exclusions, but the performance-statistics framing is distinct enough among the sibling tools to guide selection.

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 annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds meaningful behavioral detail beyond the annotations by specifying that a null quote is returned when no quote arrives within the timeout (e.g., market closed), which is important for handling non-responsive markets.

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?

Two sentences with no filler: the first states exactly what is returned and the field list, the second handles the edge case. The most important information 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.

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

With no output schema, the description compensates by listing the returned quote fields and the null-quote behavior. Combined with the schema's contractId guidance and timeoutMs bounds, an agent has enough information to call the tool correctly and interpret its result in a realistic failure case.

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 only 50%; contractId is well documented in the schema, but timeoutMs is only given type/default/min/max. The description indirectly clarifies timeoutMs by mentioning 'within the timeout', but it does not explicitly state that timeoutMs is the maximum wait time in milliseconds, leaving the agent to infer that from context.

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 and resource ('Latest real-time quote ... from the market hub') and enumerates the returned fields (lastPrice, bestBid, bestAsk, session open/high/low, volume), which clearly distinguishes it from siblings like get_bars or get_contract. No ambiguity remains about what the tool does.

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 intended use case clear — fetching the latest real-time quote — and implies this is the right tool for that purpose. However, it does not explicitly contrast itself with alternatives such as get_bars for historical data or get_contract for contract details, nor state 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.

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds value by specifying the exact guardrail fields returned, which gives the agent concrete expectations 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 a single, dense sentence that packs all relevant information without filler. It is front-loaded with the main purpose and then lists specifics, making it efficient and easy to parse.

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 output schema, the description compensates by explicitly listing all key output fields (trading enabled, guardrails, allowed accounts/symbols). For a zero-parameter config tool, this is complete and sufficient for an agent to understand what it will receive.

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 0 parameters, and schema coverage is 100% vacuously. Per the rubric, 0 params baseline is 4. No parameter info is needed, and the description correctly focuses on output.

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 uses a specific verb ('show') and resource ('server config and guardrails'), and explicitly lists the fields returned (trading enabled, max order size, max position, daily loss limit, allowed accounts/symbols). This clearly distinguishes it from trading tools like get_quote or place_order.

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 instructs 'Call this first in every session', which is a clear when-to-use directive. It doesn't mention alternatives or when not to use, but the instruction is strong and contextually sufficient.

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 establish that this is a non-destructive write (readOnlyHint=false, destructiveHint=false). The description adds the useful behavioral context that entries persist for future sessions. No contradiction with annotations. However, it does not disclose what the tool returns after persisting (there is no output schema), and says nothing about appending versus overwriting behavior.

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 purpose is front-loaded in a single opening clause, followed by a compact and efficient taxonomy. Every element earns its place and there is no filler. The dense kind list is slightly less scannable than a bulleted form would be, but it remains appropriately sized.

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 kind ordering implies a full trading workflow (plan → entry → exit → review → lesson), which provides strong context for when entries get written. Since no output schema exists, the lack of any statement about the return value is a modest gap, as is the absence of guidance on linking entries to trades via orderId/contractId/accountId.

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?

With schema coverage at 50%, the description compensates by richly explaining the most important required parameter, kind, which the schema lists only as bare enum values. The parenthetical definitions ("review (post-trade grading...)") add real semantic value. The remaining parameters are mostly covered by schema descriptions referencing list_accounts and search_contracts, though text and orderId get no added meaning.

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: "Persist your reasoning so future sessions can learn from it." The kind taxonomy (plan, entry, exit, review, lesson, note) further sharpens what the tool is for. It reads clearly as the write counterpart to journal_read and is distinct from trade-execution tools, though it never explicitly names its 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 per-kind definitions give meaningful when-to-write guidance (e.g., "pre-session thesis," "post-trade grading: what happened vs. plan"), which helps an agent decide what to log. However, there is no explicit statement of when not to use this tool or when to prefer an alternative such as journal_read or place_order; the differentiation is implied rather than stated.

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, so the safety profile is covered. The description adds useful behavioral detail about ordering and a recommended workflow, but it does not disclose return format, pagination behavior, or what happens when no entries match. 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.

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

Two sentences with no filler. The core action and ordering are front-loaded, and the second sentence provides actionable workflow guidance. Every word earns its place.

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?

There is no output schema, so the description should explain what the tool returns, but it does not. It also omits most parameter semantics and filtering behavior, leaving the agent to infer how tag, limit, since, and contractId affect results. The workflow tip is helpful but not sufficient for a 5-parameter tool.

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 only 20% (only contractId is described). The description mentions kind values 'lesson' and 'review' but leaves tag, limit, and since largely unexplained. With such low schema coverage, the description needed to compensate and did not.

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 ('Read'), a clear resource ('past journal entries'), and an ordering guarantee ('newest last'). It also distinguishes itself from the sibling journal_add by framing this as the read counterpart.

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 explicit guidance to start each session with journal_read({kind:'lesson'}) and recent reviews, which is a concrete when-to-use instruction. It does not mention exclusions or alternatives, but there is no other read-journal sibling, so the context is sufficient.

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, so the safety profile is known. The description adds useful context about scope ('on this login') and the return fields, but it does not disclose effects of the onlyActiveAccounts default or any other behavioral details. 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.

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

A single sentence with no filler, front-loaded with the verb and resource. Every word adds meaning, and the structure is immediately 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 has no output schema and one undocumented parameter. The description partially covers return values (balance, canTrade flag) but omits how onlyActiveAccounts affects results and any other response structure. For an agent to invoke this confidently, additional context is needed.

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%, and the description does not mention the onlyActiveAccounts parameter at all. With only a name, type, and default in the schema, the agent receives no explanation of what the parameter controls.

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 a specific verb ('List'), a resource ('trading accounts on this login'), and the included fields ('balance and canTrade flag'). This differentiates it from account-detail tools like get_account_snapshot, but it does not explicitly name or contrast any sibling 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 no guidance on when to use this tool versus alternatives such as get_account_snapshot or list_open_positions. There is no context about prerequisites, exclusions, or when another tool would be more appropriate.

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

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

Annotations already establish readOnlyHint=true, so the read-only nature is known. The description adds a useful operational detail: 'Large output' warns about performance/response size. It also implies an exhaustive listing behavior, 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?

Two concise sentences with no filler. The core behavior is stated first, and the alternative-tool guidance is delivered efficiently. Every sentence earns its place.

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 and low-complexity, but the 'live' parameter is unexplained and there is no output schema. The description gives enough to understand the basic purpose, but an agent cannot confidently know how the live flag changes results or what exactly the large output will contain.

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 must compensate for the undocumented 'live' parameter. It does not mention the parameter at all, leaving its meaning and effect ambiguous. The schema only provides type/default, which is insufficient for confident invocation.

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 contract available to trade.' It clearly distinguishes itself from search_contracts by emphasizing exhaustive scope ('every contract') versus a targeted lookup, so an agent can tell tools apart.

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 routing rule: 'prefer search_contracts when you know the symbol.' It also implies this tool is for broad exploration, not targeted lookups, which is exactly the guidance needed for tool selection.

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, so the read-only nature is known. The description adds the useful nuance that bracket stop/target legs are included, but it does not disclose other behavioral aspects like rate limits, error conditions, or output format beyond what annotations imply.

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?

A single sentence with a parenthetical nuance. It is concise, front-loaded with the core purpose, 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 simple read-only query tool, the description is adequate but minimal. Without an output schema, it does not mention return fields, ordering, or pagination, leaving an agent to infer the response shape from the tool name and the 'working orders' phrase.

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% and the parameter description clearly explains accountId as the trading account ID from list_accounts. The tool description merely reinforces that the scope is an account, adding no new semantic detail beyond the 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 indicates the tool provides working/open orders for an account, including bracket stop/target legs. It distinguishes from sibling actions like cancel_order and place_order by focusing on a listing operation, though it does not explicitly name search_orders as an alternative.

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?

Usage is implied: it is for viewing working orders on a specific account. However, there is no explicit guidance on when to choose this over search_orders (which may cover broader order queries) 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.

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to restate safety. The description adds a small behavioral detail by defining direction and averagePrice, which clarifies the returned data. It does not disclose pagination, ordering, or whether only currently open positions are returned, but for a simple read-only list tool this is acceptable.

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 short sentences and front-loads the core purpose. The second sentence adds useful field definitions without bloat. It is concise and every sentence earns its place.

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 simple read-only list tool with one parameter and no output schema, the description is mostly complete. It lacks explicit return-value details, but the field definitions hint at the output shape. The absence of pagination or filtering details is a minor gap given the tool's simplicity.

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%, so the schema already documents accountId. The description adds no additional parameter semantics beyond the schema, but the baseline of 3 applies because the schema carries the full burden.

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 clear verb and resource: 'Open positions on an account.' It also clarifies the meaning of two fields (direction, averagePrice), which helps distinguish this from related tools like list_open_orders or close_position. However, it does not explicitly differentiate from siblings such as get_account_snapshot, which may also include position data.

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 implies usage by naming the account context and the required accountId parameter, and the schema notes the accountId comes from list_accounts. There is no explicit when-to-use guidance or mention of alternatives, but the tool's purpose is straightforward enough that an agent can infer when to call it.

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 signal mutation and destructiveness, so the description adds value by warning about the lack of a max-distance check and clarifying that trailPrice is an absolute price level. This goes beyond what readOnlyHint/destructiveHint 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?

Two concise sentences, front-loaded with the core purpose and followed by a targeted warning. Every sentence earns its place 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?

With seven parameters, low schema description coverage, no output schema, and a destructive action, the description is too sparse to fully guide correct invocation. It omits important context such as how partial updates work, which fields may conflict, and what errors or side effects 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?

Schema description coverage is low at 29%, and the description partially compensates by explaining trailPrice and grouping size/price intent. However, stopPrice, limitPrice, orderId, and optional-field semantics remain undocumented in both schema and description, so coverage is incomplete.

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 ('Change') and resource ('size or price of a working order'), with a concrete example ('move a stop to breakeven'). It also distinguishes itself from place_order, which helps disambiguate from the closest sibling.

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 clear this tool is for modifying an existing working order and explicitly contrasts it with place_order by calling out the missing max-distance check. It does not enumerate exclusions like canceling or closing orders, but the usage context is 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 convey that this is destructive and not read-only, and the description adds that execution happens at market rather than as a limit order. It does not contradict the annotations, but it does not disclose additional behavioral details such as partial-fill risk, impact on remaining position, or requirements like an existing position.

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 single, efficient sentence with no filler. Key qualifiers ('part', 'at market', 'scale out') are front-loaded and every word adds value.

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 destructive trading action with no output schema, the description is too thin: it does not state expected response behavior, size limits, or prerequisites such as an existing open position. The schema covers param sources but not the semantics of the size and reason fields, leaving an agent under-equipped to call this 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 descriptions cover only accountId and contractId, leaving size and reason undocumented, and the tool description does not compensate. 'Part of a position' hints that size is the partial quantity, but the description does not clarify size units, constraints relative to the open position, or the purpose of reason.

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 uses a specific verb ('Close'), resource ('position'), and qualifiers ('part', 'at market', 'scale out'), making the purpose immediately clear. It also distinguishes itself from the sibling close_position by explicitly limiting the action to a partial close.

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 phrase 'Close part of a position' implies the use case of scaling out versus fully closing, but it does not explicitly name close_position or state when not to use this tool. The guidance is present only by implication rather than as an explicit routing rule.

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 the call as non-read-only and destructive, and the description adds meaningful behavior beyond that: guardrails may reject the order, bracket support depends on the account configuration, trailPrice is an absolute level rather than a distance, and rationale is persisted to the journal. No contradiction with 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 dense but every sentence earns its place: order types, price prerequisites, bracket caveat, guardrail warning, and rationale side effect. It is front-loaded with the verb and uses compact notation to avoid unnecessary prose.

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 12-parameter, 6-required, no-output-schema trading tool with destructive annotations, this description is largely complete for invocation: it covers conditional requirements, an important account-level dependency, and an execution guardrail. The main gap is that it does not describe the expected return value after a successful submission.

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?

With only 33% schema description coverage, the description carries important parameter meaning: it maps each order type to its required price field, clarifies trailPrice semantics, and confirms brackets are measured in ticks. It does not discuss every parameter, but the schema already handles accountId, contractId, customTag, and rationale.

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 'Submit an order' and then enumerates every supported order type with its conditions, making it clear this is the create-new-order tool rather than modify_order, cancel_order, or close_position. It does not explicitly name those siblings, but the semantic contrast and order-type detail make 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 explicit conditional guidance: brackets only work when Auto OCO Brackets is enabled, and otherwise the agent should place a separate stop order after the fill. It also warns that server guardrails may block the order. Broader selection rules against modify/cancel/close siblings are not stated, so it stops short of full when/when-not coverage.

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 this as read-only and open-world, so the description only needs to add behavioral context beyond that. It does: returns up to 20 results, exposes id/tickSize/tickValue/activeContract, and specifies tickValue units. 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.

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

Two dense sentences with no fluff. The core search behavior and examples come first, followed by the result cap, fields, and a practical trading note. Every sentence earns its place.

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 simple two-parameter, read-only search tool without an output schema, the description is complete: it explains how to search, what is returned, the result limit, and which returned contract is actionable. Nothing critical 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 coverage is only 50% because searchText lacks a description, but the description compensates by explaining searchText through examples. The live parameter is already described in the schema. Together, both parameters receive enough meaning for correct invocation.

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: 'Find tradable contracts by text'. It gives concrete examples (MNQ, ES, CL) and describes the result fields, which clearly distinguishes it from siblings like list_available_contracts and get_contract.

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 intended use case is clear: search for contracts by text symbol. However, it never explicitly contrasts this with alternatives such as list_available_contracts or get_contract, nor does it say when not to use this tool. Some guidance is implied by the 'Trade the activeContract=true front month' note, but exclusions are absent.

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, so the safety profile is covered. The description adds useful behavioral detail beyond annotations: results include all statuses, and trailPrice is defined as a trail distance rather than a level. This prevents misinterpretation of returned data.

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?

Two short sentences front-load the primary function and then add a single targeted caveat. There is no filler, and every sentence earns its place.

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 covers the core query semantics and one important output nuance, but with no output schema it leaves the return shape, ordering, and pagination unspecified. It also does not clarify the behavior of the optional endTimestamp parameter. These are noticeable gaps for an agent invoking the tool.

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 only 33%, with only accountId described. The description mentions a time window, which loosely maps to startTimestamp/endTimestamp, but it does not explain how the window is bounded, whether endTimestamp is optional or defaults to a value, or any parameter-specific semantics. The trailPrice note concerns output data, not input parameters, so it does not compensate for the schema gap.

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 identifies the resource (orders), the scope (created in a time window), and the status coverage (any status). The title 'Order history' reinforces this. However, it does not explicitly distinguish itself from sibling tools like list_open_orders or search_trades beyond the time-window phrasing.

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?

There is no explicit guidance on when to use this tool versus alternatives. The phrase 'Orders created in a time window' implies a historical query, but it never tells the agent when to prefer search_orders over list_open_orders or search_trades, nor does it mention any exclusions.

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 adds useful behavioral details beyond the readOnlyHint annotation: it notes that profitAndLoss is null on the opening half of a round turn and set on the closing fill, and that it defaults to the current trading day. This helps an agent interpret the returned data. However, it does not cover other aspects like pagination, ordering, or what happens when no fills exist. Since annotations already declare read-only safety, the added context is valuable but not comprehensive.

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 short (two sentences) but the first sentence is vague and poorly structured. It does not front-load the key purpose. The second sentence provides a specific behavioral detail, but overall it reads like a cryptic hint rather than a clear, organized explanation. It could be more concise and clear if it stated the purpose directly.

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 tool with three parameters and no output schema, the description is insufficient. It does not mention that the tool returns a list of fill records, nor does it describe the response structure, pagination, or ordering. It also does not explain that accountId is required or how the time window is applied. The description leaves out many details an agent would need to call the tool correctly and interpret 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?

Schema description coverage is only 33% (only accountId has a description). The description compensates slightly by stating 'Defaults to the current trading day,' which implies that startTimestamp and endTimestamp are optional and default to the current day. However, it does not clarify the time range semantics (inclusive/exclusive), timezone handling, or format expectations beyond what the schema pattern provides. It adds some meaning but not enough to fully cover the undocumented 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 says 'Fills in a time window' which is ambiguous – it could be interpreted as a verb (filling something) rather than the noun (trade fills). It does not explicitly state that the tool returns a list of trade fills (execution history) for a given account. While 'profitAndLoss' and 'halfTurn' hint at fill data, an agent would have to infer the primary function. It lacks a clear verb+resource statement like 'Returns trade fill history for an account.'

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?

No guidance is given on when to use this tool versus its siblings (e.g., search_orders, get_bars). The only contextual note is 'Defaults to the current trading day,' which describes a default behavior but not selection criteria. There is no mention of alternatives, prerequisites, or typical scenarios.

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