Gogi

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

Annotations already flag destructive/non-idempotent/open-world, and the description adds substantial behavioral context beyond them: the two-step confirm handshake, the cumulative ≤ policy max_total_capital constraint, the capital > equity hard block, warning_level thresholds, and post-success fields to verify (engine_started, is_live, symbols).

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?

Dense but front-loaded: the action and the ID-provenance caveats come first, then the confirm workflow. A few clauses restate schema content (capital_allocation definition) and could be trimmed, but nearly every sentence carries operational weight.

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, multi-step activation tool with nested risk_advanced params and an output schema, this description covers the workflow, prerequisites, guardrails, and what to verify on return. Nothing an agent needs to invoke it safely 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 100%, so baseline is 3, but the description still adds real meaning: capital comes from broker buying power and accumulates into AI Trading Power, risk_preset enumerates the same values but frames it as an override, and confirm_allocation's alias is documented. It repeats the capital_allocation semantics already present in the schema, keeping it short of a 5.

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+resource+scope: 'Link an algorithm to a trading instance with capital allocation and start live trading.' It even distinguishes the algo_id source (create_algo / list_my_algos) from the LinkedAlgo id, which is exactly the confusion an agent would have among the many sibling algo 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?

Gives explicit when-to-use and sequencing: ask user for capital, first call with confirm_allocation=false, surface allocation_requires_confirm data, then retry with true after explicit OK. It also names the alias acknowledge_capital_risk and the hard-block condition, leaving little to inference.

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 readOnly, idempotent, open-world, non-destructive, so the safety profile is fully covered by structured data. The description adds one genuinely non-schema behavior: an instruction to summarize the steps performed when presenting results, plus the fact that overlay defaults to patterns. It says nothing about cost, latency, or data scope 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?

Three short telegraphic fragments with zero padding, and the capability statement is front-loaded ahead of the presentational instruction and the routing note. The fragment style is efficient but slightly clipped, sacrificing readability of the core action for brevity.

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 full annotation coverage, a complete schema, and an output schema covering return values, the description does not need to explain results and correctly avoids doing so. What remains thin is guidance on overlay/timeframe/lookback selection, which the schema handles by declaring defaults, so the overall definition is adequate 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 description coverage is 100%, so all five parameters are already documented in the schema, including the defaults and accepted timeframes. The description's only added parameter information is restating 'Default overlay=patterns,' which is already in the schema, 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 names the concrete analytical capabilities (chart patterns, support/resistance, Fibonacci, indicators), which tells an agent exactly what this tool produces and distinguishes it from the CRUD/order-management siblings. It never states the verb explicitly (the title 'Analyze' carries that), and the telegraphic fragment style means the agent infers the action rather than reading it.

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 one explicit routing rule to an alternative: 'Use get_market_data for quotes,' which cleanly separates this analytical tool from the raw-quote sibling. However, it offers no guidance on when to pick this over other analysis-flavored siblings or when it is inappropriate, so the condition for use is only partially covered.

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 flag destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description adds crucial context: the timing constraint (before in-app confirmation) and failure conditions for executed/expired/resolved trades. This goes beyond annotations, though it doesn't explain the exact impact of cancellation or whether it can be undone.

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 action and immediately followed by the key limitation. No wasted words.

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?

Complete for a simple cancel operation: purpose, timing, and exclusions are clear. The presence of an output schema means return values needn't be explained. Minor gap: no guidance on error handling or whether the trade ID can be reused.

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 (pending_trade_id with its origin). The description adds no extra parameter details, which is acceptable given the high coverage.

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?

Specific verb (cancel) and resource (pending trade) with an explicit precondition ('before in-app confirmation'). This distinguishes it from sibling tools dealing with executed trades or status queries.

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?

Clearly states when the tool works (pending trades before confirmation) and excludes already executed, expired, or resolved trades. However, it does not name alternative tools (e.g., use get_pending_trade_status to check first) or describe when cancellation is appropriate versus other actions.

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 destructiveHint=true, idempotentHint=false and openWorldHint=true. Beyond that, the description discloses the HITL flow ('May return pending_confirmation when HITL is on') and the flatten-all semantics of omitting symbol, which are genuine behavioral facts not present in structured data. It could say more about irreversibility or broker auth requirements.

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 compact sentences, no redundancy, with the primary action and the flatten behavior front-loaded before the edge-case HITL note.

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?

Output schema exists so return values needn't be documented, yet the description still flags the pending_confirmation response shape and the confirm_close_all prerequisite, covering what an agent needs to invoke this destructive tool safely.

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 schema already documents all five parameters, and the description largely restates them (omit symbol, confirm_close_all when multiple, side for multiple sides). Baseline 3 applies since the description adds little parameter syntax or format 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?

States a specific verb ('Close') and resource ('open positions') plus scope ('Connections account, all asset classes'), which cleanly separates it from the read-only sibling get_positions and from cancel_pending_trade.

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?

Gives explicit conditional usage: omit symbol to flatten, confirm_close_all=true when multiple positions, side required when multiple sides exist. It doesn't name an alternative tool to use instead, so it stops short of full when/when-not routing.

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 cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), so the bar is lower. The description adds nothing about side effects, permissions, rate limits, or — crucially — whether the created algorithm is started or left inactive, which is exactly the ambiguity created by the presence of create_and_start_algo and activate_algo.

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 anti-invention rule is front-loaded and clear, but the same warning ('do NOT invent EMA 9/21' / 'never always the same MA pair' / schema's 'Never invent EMA 9/21') recurs across description and schema. The template-selection clause is useful but wordy, so structure is adequate rather than tight.

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 nested-schema mutation tool with an output schema, the essentials are covered (required params, indicator shape, the no-invention rule). What is missing is its position in the algorithm lifecycle relative to create_and_start_algo, activate_algo, and run_backtest, which is the main remaining ambiguity.

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% and the nested strategy_params shape is fully documented, so the baseline is 3. The description's instructions about indicator choice are behavioral guidance rather than additional parameter semantics, and it says nothing about name, symbols, or timeframe.

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+resource: 'Create a trading algorithm strategy with technical parameters.' An agent can tell it apart from update_algo or delete_algo. However, it never distinguishes itself from the close sibling create_and_start_algo, leaving the create-vs-create-and-start distinction to inference.

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?

Strong when/when-not guidance: 'Use the strategy the user (or this conversation) specified' and 'If indicators/entry conditions were not specified, ASK — do NOT invent.' It also scopes the one exception where the agent may pick freely. It does not, though, address when to use this tool rather than create_and_start_algo or activate_algo.

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 destructive=true, non-idempotent, open-world, so the safety profile is partly covered. The description adds real behavioral context beyond them: a two-step confirmation gate, the policy constraint that cumulative live capital must stay within max_total_capital, a preference for paper/demo, and the post-success presentation step. It stops short of describing failure modes or rollback.

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?

Front-loaded with the core action and the confirmation sequence, and no sentence is purely filler. However, the anti-EMA-9/21 warning and the indicator example list are restated across the description and two schema fields, adding redundancy to an already dense paragraph.

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 destructive tool with nested objects and an output schema, the description supplies the missing operational context: prerequisites (id source), gating (confirmation flow), policy limits, and the terminal success step. Since an output schema exists, return-value explanation is correctly omitted.

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 baseline is 3. The description still adds meaning beyond the schema by clarifying broker_account_id is the internal id (not the external number), that risk numbers should be preferred over risk_preset, and that confirm_allocation must start false and only flip after user acceptance — a workflow detail the schema only hints at.

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 compound action (create algo + instance + start live trading) and the resource (broker_account_id), which cleanly distinguishes it from the atomic siblings create_algo, create_instance, and start_instance. An agent can tell what this does without opening the schema.

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 when-to-use and when-not-to-act guidance: use the user's specified strategy, ASK if indicators were not specified, never invent EMA 9/21, only pick a template when explicitly invited, and ask for capital_allocation. It also names list_brokers as the source of the account id and prescribes the confirm_allocation=false → true sequencing.

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 write (readOnlyHint=false), non-idempotent, non-destructive, open-world. The description adds real behavioral context beyond that: the instance is created in a default 'pending' state and only runs immediately when explicitly requested. It still doesn't say what happens on failure or duplicate names, which would be needed for a 5.

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 tight sentences, front-loaded with the core action and its required input, followed by the two behavioral rules. No filler and nothing redundant with the title.

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?

An output schema exists, so return values need not be described. The description covers the required linkage, default state, and conditional start flag, which is sufficient for a 4-parameter create tool; only marginal gaps remain (no mention of permission requirements or behavior on name collisions).

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 baseline is 3, but the description adds decision semantics for start_immediately (only when user wants live now) and clarifies broker_account_id is the internal id sourced from list_brokers rather than an external account number. That goes beyond the field-level 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?

States a specific verb (create) and resource (trading instance), names the linking key broker_account_id and its source tool (list_brokers), and pins the default state (pending). An agent can distinguish this from create_algo, create_and_start_algo, and create_instance's siblings without opening a schema.

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?

Gives explicit conditional guidance: 'Prefer paper/demo unless user chooses live' and 'start_immediately=true only when user wants live now', which tells the agent when to set the risky flag. It does not, however, route to a named alternative such as create_and_start_algo or explain the relationship to start_instance, 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 only declare the safety profile (destructiveHint false, idempotentHint false); the description adds behavior they cannot express: the saved algorithm is preserved, the action is reversible, and deactivation does not flatten broker exposure. That last point is a high-value operational caveat.

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?

One dense sentence with the core action front-loaded, followed by sequencing, reversibility, and risk in a logical order. 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 an output schema present, return values need not be described. Purpose, sibling routing, reversal path, and the exposure caveat are all present, leaving nothing an agent needs 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 description coverage is 100% and both params (algo_id, instance_id) are documented in the schema. The description adds no further meaning about the identifier semantics or constraints, 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?

States a specific verb pair (deactivate and unlink), names the resource (algorithm) and scope (from a trading instance), and clarifies the non-deletion semantics that distinguish it from delete_algo. An agent can differentiate it from siblings without opening a schema.

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 sequences the tool relative to siblings ('Use this before delete_algo'), names the reversal path (activate_algo), and gives a precondition warning (inspect open positions first). Both when-to-use and the alternative are covered.

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 destructiveHint=true and non-idempotent, so safety is partly covered. The description adds genuinely new behavior: the confirm=true gate and the constraint that a linked algorithm must be deactivated first to avoid disrupting execution history. Return format is not described, but an output schema exists, so this is a minor gap.

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 tight sentences, front-loaded with the core action, then the confirm requirement, then the linking constraint. Every sentence earns its place with no redundancy.

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

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

With an output schema covering return values and annotations covering the safety profile, the description supplies the key operational prerequisites (confirm, linked-instance restriction) an agent needs to call it correctly. It stops short of naming alternatives, but nothing essential is missing for correct invocation.

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

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

Schema description coverage is 100%, so both parameters are already fully documented in the schema (algo_id sourcing, confirm meaning). The description restates 'requires confirm=true' but adds no syntax, format, or semantics beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description states a specific verb (Archive) and resource (a saved algorithm owned by the user), which is precise and actionable. It does not name or contrast against siblings like update_algo or deactivate_algo, and it quietly reconciles the 'delete_algo' name by describing an archive operation. Clear purpose, but no explicit sibling differentiation.

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 clear context for use: an algorithm must not be linked to a trading instance (until deactivated) and confirm=true is required. This states a 'when-not' condition. However, it never names an alternative tool (e.g., update_algo or delete_instance), so the routing is implied rather than explicit.

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 destructiveHint=true, but the description adds substantially more: slot freeing behavior, the stop-vs-delete distinction, the exact error_type returned, and the critical warning that deletion closes all open positions. This goes well beyond what annotations 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?

Front-loads the core action, then layers the conditions and error path efficiently. Dense but each sentence earns its place; slight density makes it less scannable than ideal but nothing is wasted.

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?

Covers the mutation's destructive nature, the two guard flags, the exact error contract, and the required user-confirmation workflow. With an output schema present, return values needn't be explained, and no gaps remain 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 100%, so baseline is 3. The description adds meaning not in the schema by explaining WHEN each flag is needed (force for live, confirm_close_positions for open positions) and the ordering of the recovery flow, which the schema's terse descriptions don't convey.

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?

Clear verb+resource: 'Permanently delete a trading instance and free a slot (max 10 per user).' It explicitly distinguishes from the sibling stop_instance with 'Stop ≠ delete,' so the agent can tell it apart without inspecting 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?

Provides explicit conditions and alternatives: use force=true for live instances, and a full three-step recovery path (show open_positions, warn, retry with confirm_close_positions=true after explicit OK). This is about as prescriptive as usage guidance gets.

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 destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description goes beyond that by warning the order may be irreversible and noting that policy and in-app confirmation still apply when enabled — real behavioral context not encoded in annotations, though it says nothing about failure/partial-fill 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?

Three tight sentences with zero filler, and the highest-stakes fact (money-moving, may be irreversible) is front-loaded before the confirmation caveat and sibling routing hint.

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?

An output schema exists so return values needn't be explained, and annotations carry the safety profile. The description supplies the irreversibility caveat, confirmation policy, and ticker-lookup route, leaving only minor gaps such as what happens on a rejected or partially filled order.

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 all five parameters (side, ticker, platform, contracts, price_cents) are already documented in the schema. The description only adds that the ticker can be resolved via search_predictions, which is a routing hint rather than added parameter meaning, 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?

States a specific action (money-moving order execution) with the exact venue scope (Kalshi/Polymarket) and resource (prediction-market contract order). An agent can distinguish this from the co-listed execute_trade because the prediction-market constraint is explicit.

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 routes the agent to search_predictions when the ticker is unknown, which is a concrete alternative-plus-condition. It does not, however, distinguish itself from execute_trade or state when not to use it, so it falls short of a full 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 declare destructive=true and non-idempotent, but the description adds behavior annotations cannot: real money movement, a conditional pending_confirmation return when mcp_require_confirm is set, and the required Confirm step in Gogi Activity. That confirmation workflow is the key operational context 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?

Three tight sentences that front-load the highest-risk fact (money-moving, real order) before mechanics. Every clause carries a constraint, default, or routing instruction; nothing is padding.

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, non-idempotent, open-world mutation with 100% schema coverage and an output schema, the description covers the essential extras: real-order consequence, confirmation state, and the flatten alternative. Return-value detail is correctly left to the output schema.

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 schema already defines all six parameters and baseline would be 3. The description still adds decision-level meaning for instance_id (algo-tracked live instance vs on-demand default on broker_account_id), clarifying the optional-vs-omit tradeoff beyond the raw field docs.

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+resource (execute a broker trade) and immediately flags the stakes ('Money-moving broker trade (may place a real order)'), which lets an agent distinguish it from non-mutating siblings. It also names the sibling it is not (close_positions).

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?

Gives explicit routing: use close_positions to flatten rather than synthesizing a sell, and explains instance_id (algo-tracked live) vs omitting it (on-demand on broker_account_id/default). It does not cover when to prefer execute_trade over execute_prediction or create_algo, so it stops short of a full when/when-not matrix.

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, idempotentHint, non-destructive, and openWorld, so the safety profile is covered. The description adds the ownership constraint (only the user's own algorithms are retrievable), which is real behavioral context beyond the annotations, though it does not discuss auth requirements or error behavior.

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

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

Two tight sentences with zero filler, and the core action is front-loaded before the routing hints. Every clause 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 an output schema present and complete annotations, the description need not explain return values. For a single-parameter read tool, the stated purpose, ownership scope, and sibling routing are sufficient 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% and the single algo_id parameter is already documented as coming from list_my_algos. The description restates the same sourcing hint without adding format, type, or validation detail, so this is the baseline 3 when the schema carries the load.

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 (Retrieve) plus resource (one saved algorithm) with scope qualifiers (owned by the user, by ID). It explicitly contrasts itself with the sibling get_linked_algo, so an agent can distinguish the two without opening either schema.

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?

Gives an explicit prerequisite route ("Use list_my_algos first when the ID is unknown") and names the alternative tool for a different scenario ("use get_linked_algo for an instance-specific runtime copy"). This is textbook when/when-not/alternatives 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 the full safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds a meaningful access-scope constraint that annotations do not cover: the run must belong to this user's agent, which tells the agent an ownership check can fail.

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?

One sentence, front-loaded with the action and keyed on the required parameter, with no filler. It is appropriately sized for a trivial single-parameter lookup, though 'details' stays slightly vague.

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, has an output schema so return shape needn't be described, and the description states the one non-obvious constraint (ownership). Little else is required 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 description coverage is 100% and the schema already explains run_id comes from run_backtest or list_backtest_runs, so the baseline is 3. The description only reinforces the ownership condition on the id rather than adding format or validation 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?

States a specific verb and resource ('Get details for a backtest run') and scopes it by run_id, which cleanly distinguishes it from the sibling list_backtest_runs. It does not name the alternative tool explicitly, but the singular/plural contrast is obvious.

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 - fetch a single run once you have its run_id - and the ownership constraint hints at a precondition, but there is no explicit when-to-use versus list_backtest_runs or run_backtest guidance in the description itself.

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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: output varies by feed type (FMP-backed financials/insider/congress data vs. a text preview for uploaded files), which helps the agent anticipate results.

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, front-loaded with the core action and scope, then the query requirement and return behavior. No filler sentences.

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, the description needn't detail return fields, and it correctly summarizes the divergent return behavior across feed types. It is essentially complete for a two-parameter read tool, with only discovery/prerequisite guidance absent.

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 a concrete format example ('e.g. AAPL') for the query ticker and clarifies that query values map to feed types (marketplace vs. uploaded file id). That is modest but genuine 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?

States a specific verb ('Query') and resource ('subscribed marketplace data feed') scoped by feed_id, which cleanly distinguishes it from the sibling list_data_feeds. An agent can tell it retrieves data for one feed rather than enumerating feeds.

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 conveys the mechanics of usage (pass a ticker in query for marketplace feeds) and implies different behavior for uploaded file ids, but never states prerequisites or names the alternative (e.g. list_data_feeds) for discovering feed_ids. Usage context is implied rather than explicit.

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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real context beyond that: the instance must be 'live' and 'owned by this agent', and it discloses inheritance semantics ('mcp_require_confirm (null=inherit)') plus an 'effective_confirm' resolution field, which is genuine behavioral detail about how the value is computed.

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 dense sentence that front-loads the verb and resource before the field list; nothing is filler. Slightly list-heavy but every clause maps to a real returned element.

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, return values need not be spelled out, and annotations cover safety. Parameters are fully documented in the schema and the scoping/auth context is given, so an agent has what it needs; only the when-to-use framing against update_linked_algo 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 100% and both parameters (instance_id, linked_algo_id) carry their own descriptions naming list_instances as the source. The description adds the 'live instance owned by this agent' scoping constraint on instance_id but nothing on the ID format, so the schema still does the heavy lifting – baseline 3.

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 ('Read') plus the exact resource ('a LinkedAlgo on a live instance owned by this agent') and even enumerates the contents returned (parameters, capital, symbols, confirm flags). An agent can immediately distinguish it from the write sibling update_linked_algo.

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 by the resource ('read a linked algorithm') but the description never states when to reach for this versus update_linked_algo or how it fits relative to get_portfolio/list_my_algos. No exclusions or prerequisites are given, so guidance is only inferable from the name.

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 real context beyond annotations with 'No broker required' (no auth dependency) and the default timeframe. However, readOnlyHint=false combined with the openWorldHint=true on an obviously read-style tool is never reconciled, and no rate-limit or data-delay behavior is disclosed. Useful but incomplete against a non-trivial annotation profile.

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 dense sentences, front-loaded with what the tool returns, then the operational note, then the sibling routing. No filler and every clause carries signal.

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, return format need not be described, and coverage of inputs, scope, and alternatives is strong. The one unresolved item is why readOnlyHint is false for a retrieval tool, which an agent deciding on side effects would want clarified.

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 the default value ('default 1day') that the schema does not state, and identifies the timeframe as controlling the technicals. That is meaningful value beyond the structured fields.

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?

Names a specific verb (get) and resource (market data), enumerates the covered asset classes (stocks/crypto/FX/commodities/indices) and the payload (FMP quote + OHLC + compact technicals). This makes it immediately distinguishable from data-plumbing siblings like get_data_feed.

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 routes the agent: 'Use get_data_feed for marketplace SKUs; analyze_chart_structure for patterns/S/R.' Two named alternatives with the conditions that select each, which is exactly the when/when-not guidance the dimension rewards.

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, idempotentHint, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds the status vocabulary (pending, executed, cancelled, expired, failed), which tells the agent what outcomes to expect, but says nothing about polling cadence, expiry timing, or what happens if the ID is unknown. Modest added value above 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 front-loaded sentence with the action and resource leading and the status enumeration trailing as a parenthetical. Every clause earns its place, though the dense parenthetical list makes the sentence slightly harder to parse than a clean two-sentence split would be.

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, the description needn't explain return values, and annotations cover the safety profile. For a one-parameter, idempotent status-check tool the definition is nearly sufficient; only the lack of guidance on repeated polling or handling an unknown/stale ID keeps it from being fully 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?

There is a single parameter at 100% schema description coverage, and the schema already explains it is the 'ID from execute_trade pending_confirmation'. The description adds no additional syntax, format, or provenance detail beyond that, so the baseline of 3 for schema-carried semantics 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?

States a specific verb and resource ('Check status of a pending MCP trade') and scopes it to the in-app Confirm lifecycle, which is far more informative than the bare title. It doesn't explicitly name the sibling it complements (list_pending_trades) or contrast polling a single trade vs listing all pending trades, so it stops short of the sibling-differentiation bar.

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 'awaiting in-app Confirm' implies the usage context (a trade handed off for approval that may not yet be settled), which is useful implied guidance. However there is no explicit when-to-use, no when-not-to-use, and no routing to list_pending_trades or execute_trade, so the agent must infer the trigger condition.

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 only cover safety hints, and the description adds substantive context beyond them: the tool is optional, the content is also delivered at initialize, and the payload covers permissions, no-advice, and user-borne losses. The only tension is readOnlyHint=false on a pure 'Return' tool, but with zero parameters it cannot mutate anything, so this is a server-default oddity rather than a described-vs-declared conflict.

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 dense sentence, purpose front-loaded, no wasted preamble. The trailing clause summarizing disclosure contents is slightly more than an agent needs to decide to call it, but it usefully previews the payload.

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 no parameters to document, the description only needs to justify the call and characterize the return, which it does. Nothing essential is missing; it could be marginally stronger by stating a trigger for fetching it versus relying on the initialize summary.

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 tool takes no parameters, so there is nothing for the description to disambiguate; the baseline for a zero-parameter tool applies. The description correctly signals that invocation requires no arguments.

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 ('Return Gogi's trading/MCP risk disclosure') that no sibling tool duplicates, so an agent can distinguish it immediately from the algo/trade/market tools. It also qualifies the retrieval as optional and duplicated at initialize, which sharpens the intent.

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?

'optional; also summarized in initialize' tells the agent when the call is unnecessary and names where the same information already appears, which is real routing guidance. It stops short of explicitly saying when an agent SHOULD fetch it (e.g., before first trade, or on user request).

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, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds meaningful behavioral context beyond annotations: it explains that the policy has a default mcp_require_confirm setting and that LinkedAlgo overrides are scoped to a single live binding, which is important for interpreting 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?

Two dense sentences with zero waste, front-loading the primary fetch purpose before explaining override semantics. The second sentence is somewhat cryptic for readers unfamiliar with 'mcp_require_confirm', but every clause carries functional information.

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 has no parameters, rich annotations, and an output schema, the description need not explain return values. It adequately covers what is fetched and the key override scoping rule, though it stops short of describing what a policy broadly contains or when an agent should call it.

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 tool accepts zero parameters, so per the rubric the baseline is 4. There is no parameter information to add, and the description does not need to compensate for schema gaps.

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 ('Fetch') and resource ('global policy constraints plus per-live-instance HITL/AITL overrides'), clearly distinguishing this tool from siblings like get_linked_algo or get_platform_disclosure. However, it leans on domain jargon (HITL/AITL, mcp_require_confirm, LinkedAlgo) that an agent may not fully parse, and it does not explicitly contrast itself with 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?

Usage is only implied: one would call this to learn the agent's policy constraints, but the description never states when to use it (e.g., before executing a trade) or when not to. It hints at scope via 'LinkedAlgo overrides apply only to that live binding' but offers no actionable guidance or named alternatives.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the useful scope fact that it aggregates across multiple connected brokers and wallets, but says nothing about auth/permission requirements or pagination/limits. This is adequate but modest value 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?

Two sentences, zero waste, with the resource scope front-loaded and the routing hint immediately after. Every clause 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?

An output schema exists, so return values need not be explained in prose. With read-only annotations covering safety, a clear scope statement, and explicit sibling routing, an agent has everything needed to select and invoke it.

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 tool takes zero parameters, so there is no parameter semantics to document; the baseline for a 0-param tool applies. Nothing in the description misleads about inputs.

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 (Get) and resource (portfolio), then enumerates exactly what it returns: account-level balances, equity, buying power, positions, and Web3 wallet holdings across brokers and wallets. It also differentiates from the sibling get_positions, so an agent can distinguish it without opening any schema.

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 the alternative (get_positions) and the condition that selects it ('when you only need normalized open exposure'). This tells the agent both when to use this tool and when to route elsewhere.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety and side-effect profile is fully covered. The description adds the scoping context (brokers, normalization) which is useful, but doesn't disclose return format, pagination, or broker connection requirements. With annotations carrying the safety burden, 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?

Two sentences with zero waste. The first sentence states the core capability, and the second immediately clarifies scope relative to the sibling. Front-loaded and 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?

For a zero-parameter read tool with an output schema, the description is nearly complete: it states what is returned and clarifies the scope boundary against get_portfolio. With annotations covering safety and an output schema covering return values, little else is needed. The main gap is not stating whether this aggregates across all brokers by default or requires broker selection.

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 zero parameters, the baseline is 4. There is no parameter information needed or provided, and the description correctly focuses on what the tool returns rather than inputs. No schema compensation is required.

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 ('Get') and resource ('normalized current open positions and exposure across connected brokers'), and explicitly distinguishes itself from the sibling get_portfolio by scoping what it does not cover. An agent can tell it apart from get_portfolio without inspecting either schema.

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?

Names the sibling alternative (get_portfolio) and clarifies the boundary by stating it 'does not replace account balances or wallet holdings.' This gives clear context for when this tool is the right choice. However, it doesn't specify the positive condition that selects this tool over get_portfolio (e.g., 'use this when you only need position exposure').

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: results are limited to non-terminal states (completed or running) and span four distinct channels (MCP, chat, voice, API), which the agent could not infer from annotations or 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?

Two sentences, zero filler, front-loading what the tool returns before the routing guidance. Every clause 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?

An output schema exists so return values need no explanation, annotations cover the safety profile, and the single parameter is fully documented. The description supplies the remaining scope and routing context, leaving nothing an agent needs 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?

Only one parameter (limit) and schema description coverage is 100%, so the schema already documents default (20) and max (100). The description adds no parameter-level detail, which is the expected baseline when the schema does the heavy lifting.

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 (backtest runs) with clear scope: recent runs in completed or running state, across MCP, chat, voice, and API. An agent can distinguish this listing tool from get_backtest_run and run_backtest without opening any schema.

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 routes to alternatives: get_backtest_run for a single run's details and run_backtest to start a new run. This names both the read-alternative and the write-alternative with the conditions that select 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, idempotentHint, and destructiveHint=false, and the description adds real value beyond them: the shape of each row (display_label composition and the integer `id` field), the fact that the id maps to broker_account_id, and the explicit empty-result behavior. It stops short of describing pagination or ordering, but that is minor for a small list tool.

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 short sentences, front-loaded with the scope statement, then output shape, then the safety caveat and empty-state fallback. The display_label format string is dense but it is genuine information rather than filler; nothing is redundant.

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?

An output schema exists, so the description is not obligated to explain return values at all, yet it still covers scope, row identity semantics, the no-invented-IDs safety rule, and the empty state. Nothing an agent needs to call this correctly 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?

The tool takes zero parameters, so the baseline is 4. The description's discussion of row fields describes output rather than inputs, which does not conflict with the schema and adds no confusion.

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?

Specific verb+resource ('List all connected broker accounts and wallets') with an explicit scope qualifier ('not Alpaca-only') that prevents the agent from confusing this with the Alpaca-oriented trading tools in the sibling set. An agent can distinguish it from list_instances, list_my_algos, and list_pending_trades without opening any schema.

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?

Offers operational guidance ('Prefer paper/demo; never invent IDs') and an explicit empty-state fallback URL, which is more than most list tools provide. However, it never states when to reach for this versus another lookup tool, nor any prerequisites (e.g., whether a connection must exist first), so usage is only implied.

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, idempotentHint, and openWorldHint, so the safety profile is covered and the description does not need to restate it. The description adds the useful detail that results span plan/marketplace/user-upload sources, but says nothing about auth requirements, rate limits, or result size.

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 zero waste, front-loading the action and then the result scope. Nothing could be removed without losing information.

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 and full annotation coverage, the description is nearly sufficient. The only minor gap is that it does not contrast with the singular get_data_feed sibling, leaving list-vs-get routing to be inferred.

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 tool takes zero parameters, so the baseline is 4; there is no parameter semantics for the description to clarify. The description appropriately focuses on what is returned rather than inventing input options.

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 ('data feeds') and clarifies the scope with the parenthetical breakdown (plan, marketplace subs, user uploads). It does not explicitly name the singular sibling get_data_feeds/get_data_feed, but 'List all' implicitly distinguishes it from a single-feed retrieval.

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 the usage context by enumerating the feed categories returned, but it never states when to call this versus get_data_feed or other catalog tools. No exclusions, prerequisites, or alternatives are given.

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 readOnly/idempotent/non-destructive, so safety is covered. The description adds non-obvious behavior beyond that: stopped and pending instances still consume a slot toward the max-10 limit until deleted, which is genuinely useful operational context an agent cannot infer from the schema or 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 tight sentences, front-loaded with the action and resource, followed by the one non-obvious constraint. No filler or repetition.

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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. For a parameterless read-only listing tool the description supplies everything an agent needs to call it correctly, including the quota caveat.

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?

Zero parameters, so with schema coverage at 100% and annotations present there is nothing for the description to disambiguate. The parenthetical field list describes the shape of results, which is mildly useful but not a parameter concern.

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?

Specific verb+resource ('List trading instances') plus the key returned fields (id, name, status, is_live, broker), which makes the resource unambiguous against siblings like list_my_algos, list_backtest_runs, and list_pending_trades. It stops short of naming a sibling to contrast against, so it lands at 4 rather than 5.

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 by the tool's nature (enumerate instances, e.g. to find an id for start_instance/stop_instance/delete_instance), but the description gives no explicit when-to-use or when-to-prefer-an-alternative guidance. The max-10 slot note hints at the delete decision context, which is a partial help.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered without the description. The description adds only the returned-field list, which duplicates the existing output schema, and says nothing about result volume, pagination, or ordering.

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, no filler, with the identity of the returned data front-loaded before the routing condition. Every clause carries information.

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 one-parameter, read-only list tool with full annotations and an output schema, the description covers what is needed to select and call it. It omits any statement of result size limits or whether it returns all algos versus a paginated subset, which is a minor gap given the schema already documents the filter.

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 single parameter is documented at 100% schema coverage ('Include archived algorithms (default false)'), so the baseline is 3. The description's mention of 'archived' as a returned field loosely echoes include_inactive but adds no syntax or default behavior 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?

Specific verb+resource ('List saved algorithms') plus an enumeration of the returned fields, which tells the agent what a result looks like. It stops just short of 5 because it never names the sibling it replaces (get_algo) explicitly, leaving the differentiation to inference from 'rather than supplying its ID.'

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 clause 'Use when the user names an algo rather than supplying its ID' gives a concrete selection condition that implicitly points at the ID-based alternative. There is no explicit when-not or named alternative tool, so it falls short of the top band.

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 read-only, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description's contribution is the 'awaiting in-app Confirm' state qualifier, which usefully signals that returned items are blocked on human action, but it adds nothing about freshness, scope limits, or whether the list can be empty.

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?

One short sentence, front-loaded with the verb and resource and with no filler. Every word carries information.

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 with an output schema describing the return shape, the description is nearly sufficient. The only gap is the absence of a pointer to the sibling that returns the status of an individual pending trade.

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 tool takes no parameters, so the baseline is 4; there is nothing for the description to disambiguate. No parameter meaning is missing because none exist.

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 (pending trades) and narrows scope with 'for this agent awaiting in-app Confirm', which helps separate it from the generic read siblings. It does not explicitly distinguish itself from get_pending_trade_status, which an agent could easily confuse with it.

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 'awaiting in-app Confirm' implies the scenario (trades needing the user's confirmation before execution), but the description never says when to call this versus get_pending_trade_status or execute_trade, nor does it state any prerequisite. Usage is inferable but not 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=false and idempotentHint=false, but the description adds important context: records are permanent, retained indefinitely, visible in the UI activity feed, and repeated calls create duplicate timeline records. It also warns that redundant logging creates database spam, which is valuable behavioral guidance 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 front-loaded with the core write behavior and then cleanly separated into WHEN TO USE and WHEN NOT TO USE. Every sentence earns its place by clarifying permanence, duplication, or correct usage.

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, return values need not be explained. Annotations cover the safety profile, while the description fully covers when to use the tool, when not to, and the consequences of misuse.

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 input schema already documents event_type, payload, and description. The description adds usage context for event_type via examples like inner thoughts, reasoning steps, and milestones, but does not add syntax or format details beyond the schema, so the baseline of 3 is appropriate.

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

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

States a specific verb and resource: logging and persisting a custom activity event to the backend database and UI timeline. It also distinguishes itself from siblings by naming execute_trade, close_positions, and execute_prediction as tools that already emit their own events.

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?

Contains explicit WHEN TO USE and WHEN NOT TO USE sections. It names the alternative behavior directly, explaining that standard action tools automatically emit timeline events and should not be duplicated.

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, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: it returns metadata plus a capped UTF-8 text preview, and binary files yield metadata only, which tells the agent what to expect from the call. It does not cover error behavior for non-owned or missing files.

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 tight sentences with the primary action and ownership constraint front-loaded, followed by the return-shape caveat. Every clause earns its place with no 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 rich annotations and an output schema present, the description need not explain return values, yet it helpfully summarizes them anyway and states the ownership requirement. Only a note on failure modes (missing file, foreign ownership) is absent, which is minor for a simple read 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 100% with a single parameter, so the schema already documents file_id, its origin (list_data_feeds), and the ownership constraint. The description only restates 'owned by this agent', adding no format, casing, or sourcing detail beyond the schema. 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?

States a specific verb (read) and resource (a user-uploaded file owned by this agent), which clearly separates it from siblings like get_data_feed, get_market_data, and list_data_feeds. The description also previews the return shape, so an agent can distinguish it from list/read tools without opening the schema.

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 rather than stated: the schema notes file_id is 'returned by list_data_feeds', which hints at a discovery-then-read flow, but the description itself offers no explicit when-to-use guidance or alternatives. No exclusion criteria (e.g., when to use list_data_feeds or get_data_feed instead) are given.

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=false, openWorldHint=true, idempotentHint=false, so the agent knows this is a non-idempotent external write. The description adds genuinely useful context the annotations lack: results location (Backtesting tab and Activity feed) and a Pro plan requirement. It still omits whether a run is asynchronous, whether it consumes quota, or how long results take, which matters for a backtest.

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 short sentences, front-loaded with the action, then the outcome location, then the gating requirement. 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 an output schema present, return-value explanation is not needed, and annotations cover the mutation profile. What's missing is async/sync behavior and typical duration for a 13-parameter, possibly long-running backtest, plus routing to the get_backtest_run/list_backtest_runs siblings.

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 every one of the 13 parameters is documented in the schema, making a 3 the baseline. The description adds no parameter detail at all, and notable nuances (respect_policy defaults false/opt-in, symbol cap of 10, timeframe units) are all already in 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 (run) and resource (policy-aware historical backtest), scoped to 'this agent', which distinguishes it from sibling read tools like get_backtest_run and list_backtest_runs. However, it doesn't reference those siblings or explain what 'policy-aware' means beyond the name.

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?

Gives an implied gating condition ('Requires Backtesting Pro') which tells when it will succeed, but provides no guidance on when to use this vs the get_backtest_run/list_backtest_runs siblings or prerequisites like needing a saved algo.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful non-annotation context: the markets are public and no broker account/authentication is required, which is the key operational trait an agent needs before invoking it.

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 short sentences with zero filler. The core action and venue scope are front-loaded, followed by the auth precondition and the sibling routing, which is the right priority order.

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?

An output schema exists, so return values need not be explained. For a two-parameter search tool, the description covers scope, authentication requirements, and the alternative for write actions — nothing an agent needs in order to call it correctly 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 100%, and the schema already documents both 'query' (text or ticker) and 'platform' (venue filter with enum, omit to search both). The description adds no additional parameter semantics, 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?

States a specific verb ('Search') and resource ('public prediction markets'), names the two venues covered (Kalshi, Polymarket), and explicitly routes betting to the sibling execute_prediction. An agent can distinguish this read/search tool from execute_prediction without opening either schema.

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?

Gives a clear precondition ('No connected Kalshi/Polymarket broker account required') and names the alternative for the written action ('To place a bet, use execute_prediction with a connected account'). It stops short of stating explicit when-not conditions, such as cases where a private/account-scoped search would be needed, but 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 declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety bar is lowered. The description still adds meaningful context beyond them: the required prior state (stopped/pending) and the warning that starting can enable live trading, i.e. real-money execution. It stops short of describing failure behavior for an already-running instance.

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 tight sentences with zero filler; the action and its precondition are front-loaded, and the sibling caveat follows. Nothing is wasted.

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, return values need not be explained. The description covers action, precondition, side effect, and sibling scope, but omits what happens on invalid state (e.g. instance already running) or permission requirements for enabling live trading.

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?

Single parameter with 100% schema description coverage, so the schema already documents instance_id fully. The description adds no format, range, or lookup guidance beyond what the schema provides; 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?

States a specific verb+resource (start ... instance) plus the precondition state (stopped/pending) and the notable side effect (can enable live trading). It also names two siblings it is not a substitute for, so an agent can distinguish it from activate_algo and create_instance without opening either schema.

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 implied usage condition (instance must be stopped/pending) and a negative exclusion (does not replace activate_algo or create_instance), but never states positively when to choose this over siblings like create_and_start_algo, which also starts execution. Guidance is inferable rather than explicit.

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 destructiveHint=false and readOnlyHint=false, but the description adds the crucial behavioral detail that stopping is reversible and leaves positions intact — exactly what an agent needs to know before a mutation. It does not address the non-idempotent hint (repeat-call behavior) or whether other automation state is affected, keeping it short of a 5.

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 tight sentences, front-loaded with the primary action and follow-up constraints, with zero redundant restatement of the name or schema.

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?

An output schema exists and annotations cover the safety profile, so the description only needs to carry the semantic distinction between stopping and closing — which it does explicitly. Nothing an agent needs to call this correctly 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?

With a single parameter and 100% schema description coverage, the schema already fully documents instance_id ('ID of the trading instance to stop'). The description adds no syntax or format detail beyond it, so the baseline 3 for schema-covered parameters 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?

States a specific verb (stop) and resource (a running instance) scoped to 'automated execution', and explicitly distinguishes itself from both start_instance (the reverse operation) and close_positions (the position-flattening alternative). An agent can pick it apart from the 35+ siblings without opening any schema.

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?

Gives an explicit when-not condition ('Does not flatten positions — use close_positions when the user wants that') and names the inverse operation for resumption via start_instance. Nothing about tool selection is left to inference.

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 readOnly=false, destructive=false, idempotent=false. The description adds genuinely useful context beyond them: 'Only supplied fields change' documents partial-update semantics, and it clarifies that the edit does not propagate to linked live instances. A 4 rather than 5 because no auth/permission or error behavior is mentioned.

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, zero waste, with the core purpose and partial-update behavior front-loaded before the sibling disambiguation. 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 an output schema present, annotations covering the safety profile, and 100% schema coverage, the description's remaining job is scope and sibling disambiguation, both of which it handles cleanly. Nothing an agent needs to invoke it correctly 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 100%, so every parameter is already documented in the schema. The description adds the PATCH-style semantics ('only supplied fields change'), which explains why only algo_id is required, but provides no field-specific meaning beyond that. 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?

States a specific verb (update) and resource (saved algorithm) and scopes ownership ('owned by the user'). It explicitly distinguishes itself from the sibling update_linked_algo, so an agent can route correctly without opening either schema.

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?

Names the alternative (update_linked_algo) and the condition that selects it ('instance-specific runtime change'), and clarifies that this tool does not touch live instances. Both when-to-use and when-not-to-use are covered.

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 destructive=true, idempotent=false and openWorld=true. The description adds meaningful context beyond that: toggling is_live=true can launch live trading and needs explicit user intent. It does not explain whether omitted fields are preserved or how name conflicts are handled, so it is good but not complete.

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, front-loaded with the core action, then the caveats. Every clause 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 an output schema present and annotations covering the safety profile, the description supplies the remaining high-value information (sibling exclusions and the live-execution side effect). Nothing critical to calling it correctly 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 100%, so the baseline is 3. The description goes beyond the schema by flagging that is_live=true may start live execution, adding risk meaning the boolean type alone does not convey.

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 (update), resource (an owned trading instance), and scope (name or runtime settings), which lets an agent separate it from adjacent tools at a glance. It also names the siblings it does not replace (activate_algo, update_linked_algo), removing ambiguity.

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 exclusions ('does not replace activate_algo or update_linked_algo') and a usage condition ('setting is_live=true... requires explicit user intent'). It stops short of saying when to prefer this over start_instance/stop_instance, so it is strong but not fully exhaustive.

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?

Adds substantial context beyond the annotations: the override scope is per-instance-only, the first call returns a 'loop_mode_requires_confirm' disclosure, and the agent must retry with confirm_loop_mode=true. This is exactly the kind of behavioral disclosure the agent needs for a multi-step mutation flow. The annotation set (non-readonly, openWorld, non-idempotent) is already sensible and not contradicted.

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, front-loaded with the core purpose, then the confirm-loop mechanics. Dense but justified. Slightly cumbersome phrasing ('for THAT live instance only') but no wasted 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 an output schema exists and the schema describes all parameters, the description supplies the crucial missing piece: the two-step confirmation contract and the scope of overrides. That is the non-obvious operational knowledge an agent needs to invoke this 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%, and the description mostly restates what is already in the schema. It does explain the semantic difference of mcp_require_confirm values and the two-step confirm mechanism, but parameter-level details for parameters/name/description are not added.

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 specific verb+resource ('Update this agent's LinkedAlgo on an instance') and names the two updateable fields (parameters, mcp_require_confirm). Distinguishes from sibling update_algo by the 'LinkedAlgo on an instance' scope, though the distinction is somewhat implicit rather than contrasted explicitly.

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?

Describes the retry flow and how new instances behave, giving clear context for the confirm_loop_mode path. However, it does not explicitly contrast with sibling tools like update_algo or get_linked_algo, so the alternative selection guidance is incomplete.

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