dMoERA Creator

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

With no annotations provided, the description carries the behavioral disclosure burden. It does well by stating that this starts the personal router, deploys capital according to weights and risk caps, and pauses the main platform router while active. It also adds the ownership requirement for user_id, though it could say more about reversibility or error cases.

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 appropriately sized and front-loaded with the core purpose. Every sentence contributes meaning, including side effects and argument ownership. The 'Returns success or error' line is slightly redundant given the output schema exists, but it is compact and not harmful.

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 fund activation tool with no annotations and an output schema, the description covers the essential behavioral context: what starts, what gets paused, how capital is deployed, and the ownership constraint. It lacks explicit guidance on deactivation or interactions with sibling tools, but it is largely complete for invoking 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 description coverage is 0%, so the description must compensate. It provides brief semantic meaning for both parameters: user_id is the user's ID and must own the fund, and fund_id is the fund's ID. This is useful but minimal, and does not add much beyond what the schema's names and types already suggest.

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

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

The description opens with a specific verb and resource: 'Activate Manager Mode for a fund — starts the personal router.' It clearly differentiates this from sibling tools like deactivate_fund or close_fund by naming the exact action and its effect.

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 context of when to use this tool is implied through the behavior described: deploying capital and pausing the main platform router while Manager Mode is active. However, it does not explicitly mention alternatives like deactivate_fund or state when not to use it, leaving some routing 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?

With no annotations provided, the description carries the behavioral burden. It discloses that the operation mutates the fund's roster ('Add'), states an ownership/permission constraint, and tells the caller it returns the updated roster entry. It could mention duplicate-handling or invalid-weight behavior, but the core behavioral expectations are clear.

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

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

The description is compact and front-loaded: a one-sentence summary, followed by a terse Args list and a single return-value sentence. Every line adds necessary semantic value without filler.

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

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

For a 5-parameter mutation tool with no annotations, the description covers all parameters, the key permission requirement, and the return contract. It could add edge cases such as duplicate bots or weight validation, but an agent has enough information to invoke the tool correctly.

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

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

Schema coverage is 0%, and the description fully compensates. It defines user_id as the owner, fund_id and bot_id by role, gives concrete examples for bot_id and bot_domain, and explains weight as an initial allocation percentage with a default of 20.0. This is far more informative than the raw schema.

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

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

The description opens with a precise verb and object: 'Add a bot to a fund's roster.' This clearly distinguishes the tool from siblings such as remove_bot_from_fund, swap_bot_in_fund, and update_fund_weights, and the parameter list reinforces the specific action being performed.

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

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

The description provides useful context by noting the user must own the fund, which is a prerequisite for use. However, it does not explicitly state when to choose this tool over close alternatives like swap_bot_in_fund or update_fund_weights, so the usage boundaries are implied rather than stated.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose the output form ('Returns a JSON array') and the content ('performance stats and available capacity'), plus a runtime requirement. It does not explicitly state that this is a read-only operation or describe failure behavior, though 'Browse/Shows/Returns' implies a non-mutating lookup.

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

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

The description is compact and well-ordered: purpose first, then what is shown, the prerequisite, parameter explanations, and return type. Every sentence adds value, and there is no redundant or filler content.

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

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

For a simple tool with only two optional parameters and an output schema, the description covers the essential invocation details: purpose, operational prerequisite, filter semantics, and return shape. The main gap is the lack of differentiation from the similarly named 'get_marketplace_bots,' but overall the description is adequate 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?

The input schema provides almost no semantic coverage, so the description must compensate. It does give one-line explanations for both parameters: 'domain' is a filter with an example, and 'min_sharpe' is a minimum Sharpe ratio filter. This adds meaning beyond the bare schema, but details like defaults, null behavior, or filter format are not addressed.

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

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

The description uses a specific verb and resource: 'Browse bots available for adding to a fund roster.' It also clarifies what is shown (performance stats and capacity). However, it does not distinguish this tool from the sibling 'get_marketplace_bots,' which appears to have an overlapping purpose.

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 clear context for when the tool is relevant: adding bots to a fund roster. It also mentions an operational prerequisite: the trading engine must be running. However, it provides no explicit alternatives or exclusion guidance, especially regarding the similar 'get_marketplace_bots' sibling.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states irreversibility, return of capital to the wallet, and preservation of the performance record for reporting and copy-trader settlement. It does not mention side effects on associated bots or marketplace listing, but the most important destructive behaviors and data-retention policy are disclosed.

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

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

Every sentence earns its place: the first combines purpose and outcome, the second adds irreversibility and record preservation, and the Args section is compact yet sufficient. No filler or redundancy. The 'Returns success or error' line is minimal and acceptable.

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 two-parameter mutation tool with no annotations but an output schema, the description covers the operation's purpose, irreversibility, capital return, record preservation, ownership requirement, and return type. It omits details like required fund state or effects on bots, but these are either inferable or secondary for a close operation. The context is sufficient for an agent to call it correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It adds real semantics to user_id ('must own the fund') but only restates the schema for fund_id ('The fund's ID'). This is partial compensation: one parameter gains meaningful context, the other adds little beyond the schema title.

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

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

The description states a specific verb and resource ('Permanently close a hedge fund') and immediately gives the primary consequence ('Returns all capital to the wallet'). The word 'Permanently' and the explicit 'This is irreversible' distinguish it from sibling tools like deactivate_fund, making the tool's unique role clear.

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 establishes that this is a permanent, irreversible action, which strongly implies it should be chosen over deactivate_fund when the intent is final closure. It also notes the ownership prerequisite for user_id. However, it does not explicitly name alternative tools or state 'use this instead of X when Y', leaving a small inference burden.

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?

With no annotations provided, the description carries the burden of disclosing behavior. It does so well by stating that the fund is created inactive, that initial capital is deducted from wallet_cash, and that the created fund object is returned. This goes beyond the schema and gives the agent useful behavioral expectations, though it could also mention side effects such as capital deduction irreversibility or possible failure conditions.

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 well-structured with a brief summary, bullets for Args, and a return statement. Every sentence adds value, and the most important behavioral details (inactive state, capital source, activation path) are front-loaded. No filler or redundant content.

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 creation tool with no annotations and low schema coverage, the description provides a complete picture: what it does, key side effects, parameter semantics, and return value. The output schema exists, so return details need not be exhaustive. The description is fully sufficient for an agent to correctly select and invoke this tool.

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

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

The input schema has 0% description coverage, so the description must compensate. It does, explaining all five parameters: user_id, fund_name, router_preset with allowed values, aggression_mode with allowed values, and philosophy with a max length. This is exactly the kind of semantic enrichment the schema lacks.

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

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

The description states a specific verb and resource: 'Create a new hedge fund for the user.' It clearly differentiates from the sibling activate_fund by explaining that the fund starts inactive and requires activation. This makes the tool's purpose unmistakable.

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

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

The description explicitly says the fund starts inactive and directs the agent to call activate_fund to start Manager Mode. It also notes that initial capital is taken from wallet_cash, giving important context for when this tool should be invoked. This provides clear usage guidance relative to the sibling activation tool.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It transparently states the destructive side effect of closing all roster bot positions and returning capital to the wallet, plus the ownership requirement. It does not mention whether the action is reversible, but the core side effect is clearly disclosed.

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

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

The description is compact and well-structured: a one-line purpose, a one-line side effect, and a clear Args list. There is no filler or redundant repetition of schema information; every sentence earns its place.

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

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

For a two-parameter mutation tool, the description covers purpose, side effects, parameters, and return behavior ('Returns success or error'). Since an output schema exists, return details need not be expanded. The only notable gap is explicit routing to sibling tools, which is already accounted for in usage guidelines.

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

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

Schema description coverage is 0%, so the description must compensate. It provides meaningful semantics for both parameters: user_id is the user who must own the fund, and fund_id identifies the target fund. This is enough to understand each argument's role, though it could add types or format details.

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

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

The description uses a specific verb ('Deactivate') and resource ('Manager Mode'), and clearly states the effect: closing all roster bot positions and returning capital to the wallet. It distinguishes itself from activate_fund and other fund operations, though it does not explicitly differentiate from close_fund.

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 tool should be used when leaving manager mode and returning to the main platform router, and states the ownership prerequisite. However, it does not explicitly say when to use this tool versus alternatives like close_fund or activate_fund, leaving some selection burden on the agent.

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

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

With no annotations available, the description carries the full behavioral burden. It discloses that this is an estimation step, explains what the cost represents (winding down old positions and opening new ones), and specifies the return unit: estimated friction in bps of fund AUM. It does not explicitly state that no mutation occurs, but the 'estimate' framing and the 'before calling swap_bot_in_fund' context make this adequately clear.

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

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

The description is compact and well-organized: a one-sentence summary, a usage directive, an Args list, and a return explanation. No extra fluff or repetition of schema types is included, and every sentence serves a purpose.

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

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

For a tool with four simple and required parameters, the description covers its main purpose, when to use it, what the result means, and the return unit. Minor gaps remain, such as not explaining where to find valid new_bot_domain values or any prerequisites (e.g., whether the fund must be active), but the core invocation context is sufficiently clear.

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

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

Schema description coverage is 0%, so the Args section is essential. It adds meaning for three of the four parameters: old_bot_id is 'the bot being considered for removal', new_bot_id is 'the replacement bot', and new_bot_domain is 'the replacement bot's doman'. Only fund_id ('The fund's ID') merely restates the schema title, but the other parameters are meaningfully clarified.

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

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

The description opens with a specific verb and resource: 'Estimate the friction cost (in bps) of swapping a bot in a fund.' It clearly distinguishes this estimation tool from the actual mutation tool, swap_bot_in_fund, by naming the operation and its purpose.

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

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

The description explicitly says 'Use this before calling swap_bot_in_fund' and explains why it should be used: to understand the cost of winding down the old bot's positions and opening new ones. This is a clear when-to-use directive tied to a specific sibling tool.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It clearly states that the tool returns either the active fund object or null when Manager Mode is inactive, which is a meaningful behavioral trait. It does not mention potential errors or permissions, but the getter nature and null condition are well covered.

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 extremely concise and well structured: a one-line purpose, an Args line, and a Returns line. Every sentence earns its place and the key behavior (null when Manager Mode is inactive) is front-loaded through the purpose statement.

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

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

For a simple getter with one parameter, the description is largely complete: it identifies the resource, the parameter, and the null-case behavior. Since an output schema exists, the full return structure is presumably available. The main missing context is explicit differentiation from sibling fund tools, but the active/Manager Mode qualifier mitigates this.

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

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

The only parameter, user_id, has 0% schema description coverage. The description's 'user_id: The user's ID' is a minimal clarification that ties the parameter to the user whose fund is being fetched, but it adds little beyond the parameter name and schema title. It is adequate for a single self-explanatory parameter but does not go deeper into expected format or semantics.

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 ('Get'), a clear resource ('the user's currently active (Manager Mode) fund'), and explicitly distinguishes it from the broader get_fund/list_funds siblings by qualifying it as the active Manager Mode fund. This is unambiguous and actionable.

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

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

No guidance is given about when to prefer this tool over siblings like get_fund or list_funds. The null-return condition implies a use case, but there is no explicit statement such as 'Use get_fund when you have a specific fund ID' or 'Use this only when checking the active Manager Mode fund.'

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the complete return payload (performance metrics, position, trade history) and conveys read-only intent via 'Get', which is adequate for a non-destructive lookup. It does not mention error behavior when bot_id is unknown, but that is a minor gap for a simple get 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?

The purpose is front-loaded in the first sentence, followed by a compact Args/Returns structure. The return-field enumeration is partially redundant with the existing output schema but remains readable and serves as a quick-reference without bloating the text.

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

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

Given the tool's low complexity (one required parameter) and the presence of an output schema, the description covers the essentials: operation, parameter semantics, and return content. The only omission is routing guidance against siblings like list_bots/get_strategy_report, which is already accounted for under usage_guidelines.

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

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

Schema description coverage is 0%, so this dimension falls entirely on the description. The Args section explains bot_id ('The bot identifier') and gives a concrete example ('Eth_Full_Ensemble'), compensating well for the bare schema; it stops short of saying where the identifier comes from (e.g., list_bots).

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?

Opens with a specific verb+resource ('Get detailed profile and performance stats for a specific bot'), making the operation and target unambiguous. The 'specific bot' phrasing distinguishes it from the list-oriented sibling list_bots, and the output list clarifies scope versus analytics siblings like get_strategy_report.

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 its use case — query a known bot by ID — but never states when to choose it over alternatives such as list_bots or get_strategy_report, and names no exclusions. Usage context must be inferred from the word 'specific', so a less experienced agent gets no explicit routing 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?

With no annotations, the description carries the disclosure burden; it covers output shape (JSON with price, bid, ask, source, change_24h_pct, volume_24h), the macro scope (all tracked symbols), and sources (Binance/Coinbase/Kraken). It does not mention auth requirements or potential rate limits, but for a read-only getter 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?

Two compact sentences front-load the main action and follow with a structured return description. No filler or redundant schema 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?

For a parameterless price tool, the description is complete: it defines the exact symbols, exchanges, and return shape. The presence of an output schema further covers the response details, leaving an agent with everything needed to invoke correctly.

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

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

The input schema has zero properties and 100% description coverage by default, so the baseline of 4 applies; the description adds value by explaining what data is returned for the fixed symbol set. There are no parameters to clarify.

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 precise verb ('Get') and a specific resource ('current live prices for all tracked symbols'), then enumerates the exact tracked symbols (ETHUSDT, BTCUSDT, SOLUSDT) and data sources. This clearly differentiates the tool from the fund/bot/strategy siblings.

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

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

The description makes the tool's use case self-evident—fetching live market prices—and no sibling tool appears to offer price retrieval, so there is no ambiguity about when to choose it. It does not explicitly contrast it with alternatives, but it provides clear context and no exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the two statuses ('live' vs 'planned'), states what can be required, and lists the exact returned fields. It does not mention potential side effects, but the verb 'List' and the catalog nature make read-only behavior reasonably clear.

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 well-structured and front-loaded: the first sentence states the core purpose, the second clarifies usage context, the third defines status semantics, and the fourth covers the return shape. Every sentence adds value and there is no redundant filler.

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

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

For a zero-parameter catalog-listing tool, the description is complete. It explains the domain context, the status logic that affects usage, and the return structure in enough detail. Since an output schema exists, the description does not need to separately document each return field's deeper semantics.

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 has zero parameters, so the baseline of 4 applies. The description adds no parameter-specific information because there are none to document, and the schema already indicates that no arguments are 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?

The description uses a specific verb ('List') and names the resource ('all data feeds available to strategies via ctx.features'), making the tool's purpose immediately clear. It also explains how features relate to strategy execution and required_features, distinguishing it from sibling tools that handle funds, strategies, or prices.

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 clear context for when to use this tool: it lists available data feeds and clarifies that only 'live' features can be used in required_features. It does not explicitly name alternative tools that would be preferred in other scenarios, but no direct alternative is evident among the siblings, and the usage context is strong.

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?

With no annotations, the description carries the burden of disclosure. It does state the return shape (JSON with fund details and active roster entries including specific fields), which is useful. However, it does not mention error behavior, access requirements, or whether only active funds can be queried.

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

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

The description is compact, front-loads the main purpose, and uses a clear Args/Returns structure. Every sentence adds meaningful information without fluff.

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

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

For a simple lookup tool with one parameter and an output schema, the description is mostly complete. It names the returned roster fields and the input, but lacks explicit sibling differentiation and edge-case behavior, leaving a small gap.

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 only one parameter and the schema provides no description, so the description must clarify it. Saying 'fund_id: The fund's ID' adds a minimal semantic pointer, but it is largely tautological and does not explain where the ID comes from or how it is used.

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

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

The description states a specific verb and resource: 'Get detailed info for a specific hedge fund, including its roster.' It clearly distinguishes this from listing tools like list_funds by emphasizing 'specific' and by naming the roster contents.

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

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

The description implies usage: call this when you need details for one fund and have a fund_id. It does not explicitly compare against siblings such as list_funds or get_active_fund, nor does it state when not to use it, so guidance 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?

With no annotations, the description carries the behavioral burden. It clearly indicates a read-only listing operation and reveals that returned stats are 'cached,' which is an important behavioral nuance. It stops short of mentioning rate limits or auth requirements, but for a list tool the core behavior is well disclosed.

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 well-structured with a clear purpose line, an Args block, and a Returns block. Every sentence adds value, and the parameter details are concise and directly usable by an agent.

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

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

For a simple read-only listing tool, the description covers all invocation details: optional parameters, valid values, defaults, and the return shape. The explicit mention of cached stats adds useful context beyond the output schema, making the definition effectively 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?

Schema description coverage is 0%, so the description must fully explain the parameters, and it does. It gives the domain format with an example, enumerates valid sort values, and specifies limit defaults and maximum. This is strong compensation for the schema gap.

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

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

The description starts with 'List bots published to the marketplace,' which clearly identifies the verb, resource, and scope. It does not explicitly distinguish from sibling tools like list_bots or browse_fund_marketplace, but the 'marketplace' qualifier provides enough specificity for basic 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?

The description implies this tool is for viewing marketplace bots, and the parameter guidance (e.g., 'Omit for all domains') is useful. However, it never states when to prefer this over list_bots or browse_fund_marketplace, nor does it provide when-not-to-use guidance.

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

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

No annotations are provided, so the description carries the full burden. 'Get' implies a read-only operation, and the description covers output contents well, but it does not disclose whether the data is live or cached, whether authentication or initialization is required, or any other behavioral caveats. Acceptable for a zero-parameter getter but not thorough.

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

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

The description is compact and front-loaded with purpose. Each subsequent line adds interpretive value, whether listing output fields or mapping regime values to allowed trade directions. 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?

With no parameters, an output schema, and a simple read operation, the description covers the core semantics and return-value interpretation. The missing piece is an explicit statement of when to call it (e.g., 'call this before opening any position'), though the regime rule lines imply that timing.

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 has zero parameters, so the schema trivially covers everything and the description has no parameter information to add. Baseline 4 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 ('Get'), a clear resource ('current market regime classification'), and enumerates the exact returned data (aggregate/per-symbol regimes, crisis score, and derivatives data). The regime semantics further separate it from the unrelated sibling trading/fund management tools.

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

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

The description does not explicitly name alternatives or when-not-to-use this tool. However, the line 'Regime determines which trade directions are allowed' implies it should be consulted before trading, so usage is conveyed through implication rather than explicit 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?

With no annotations, the description carries the full burden. It discloses useful behavioral details: the report includes validation runs for all 7 stages, performance metrics, and the integrity block (code hash, AST hash, parameter fingerprint), and notes that it returns the latest validation runs. This goes beyond the tool name and schema, though it does not explicitly mention side effects or failure modes.

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

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

The description is compact and well-structured: opening purpose statement, content details, explicit Args line, and Returns line. Each sentence adds distinct information with no fluff or repetition, and the most important information is front-loaded.

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

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

The tool has one required parameter, an output schema that can describe return values, and no nested objects. The description covers purpose, content, and parameter semantics completely enough for correct invocation. Any missing usage guidance is captured in the usage dimension, not a completeness gap here.

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

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

Schema description coverage is 0%, but the description explains the sole parameter, strategy_id, as 'The strategy's database ID.' This adds semantic meaning beyond the raw integer type in the schema. It lacks extra guidance on where to find the ID, but for a single simple parameter it provides adequate meaning.

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

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

The description states a specific verb ('Get') and resource ('detailed report card for a strategy'), and elaborates with concrete contents: validation run results for all 7 stages, performance metrics, and an integrity block. This clearly distinguishes it from sibling tools like delist_strategy or sandbox_backtest, as it is specifically a reporting/read tool for strategy status and health.

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

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

The description implies usage: whenever an agent needs a detailed report card for a strategy, including validation and metrics. However, it does not explicitly state when not to use it or mention alternatives from the sibling list, leaving selection conditions 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?

With no annotations provided, the description carries the full behavioral burden. It discloses the return structure and notable context about tournament cadence and scoring weights. It does not mention read-only guarantees or data freshness, but 'Get' and the absence of side-effect language make the behavior adequately transparent.

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 no fluff. The primary action is front-loaded, and the additional tournament scoring context is directly relevant to interpreting the results. Every sentence earns its place.

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

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

For a zero-parameter read-only status tool with an output schema available, the description is complete. It explains what data is returned, the tournament mechanics, and the scoring formula, giving the agent enough context to invoke the tool and interpret results 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?

There are zero parameters, so the baseline is 4 by the rubric. The description correctly focuses entirely on return semantics rather than parameters, and no parameter clarification is needed.

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

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

The description starts with a specific verb and resource: 'Get current tournament round status and leaderboard.' It clearly differentiates from sibling tools like get_market_regime or get_strategy_report because no other sibling is focused on tournaments.

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 when to use this tool by defining what it returns and how tournaments work. It lacks an explicit 'use this instead of X' statement, but since no sibling covers tournament status, the usage context is sufficiently 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?

With no annotations provided, the description compensates by disclosing the ranking behavior, the return as a JSON array with a specific list of fields, and the default/max behavior for limit. It does not mention authorization, pagination beyond the limit, or whether results are restricted to certain bot statuses, but coverage is solid for a read-only list operation.

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 efficiently organized: a one-sentence purpose followed by clear Args and Returns sections. Every sentence contributes useful information without redundancy or 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?

The description covers parameters, return fields, default behavior, and ranking, which is sufficient for an agent to call the tool correctly. It lacks only explicit routing against sibling tools, which is more of a usage-guideline gap than a completeness one, and no output schema is provided so the listed return fields are the only documentation.

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

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

Schema description coverage is 0%, and the description fully compensates by explaining the domain parameter with examples and omission behavior, and the limit parameter with default and maximum values. This adds meaning far beyond the raw schema.

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

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

The description clearly states the tool lists trading bots ranked by performance, which identifies the specific verb, resource, and ranking criterion. It is distinct enough from siblings like list_strategies, but it does not explicitly name overlapping siblings like get_marketplace_bots or get_open_source_leaderboard to differentiate them.

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 explains parameter usage (domain filter, limit) but gives no guidance on when to use this tool versus alternatives. No sibling tools are mentioned, and there is no explicit when-to-use or when-not-to-use context, leaving the agent to infer the appropriate choice.

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?

With no annotations, the description carries the full behavioral disclosure burden. It clearly states that the tool returns a JSON array of domain objects and enumerates the exact fields, which is strong transparency for a read-only listing operation. It does not mention authentication, rate limits, or pagination, but those are less critical for a parameterless list endpoint.

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

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

The description is compact and well-organized: a one-sentence purpose, a two-sentence domain primer, and a one-sentence return contract. Every sentence earns its place, and the most important information is front-loaded.

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

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

For a parameterless listing tool with an output schema, the description is complete. It defines what a domain is, why it matters (strategies must declare one), and precisely what the response contains. There are no parameters to document and no significant missing behavior that would prevent an agent from invoking the tool correctly.

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

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

The tool has zero parameters, so parameter documentation is not needed. The description adds value by explaining the meaning and structure of the returned domain objects, including examples of time horizons and the field list, which is more context than the empty schema provides.

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

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

The description opens with a specific verb and resource: 'List all available trading domains on dMoERA.' It explains what domains are and how they relate to strategies, which makes the purpose concrete and distinguishable from the sibling tools, which all deal with funds, bots, strategies, or market data rather than domain listing.

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 clear contextual guidance: strategies must declare a domain, so the tool is the natural way to discover what domains exist. It does not explicitly state when not to use it or list alternatives, but there are no sibling tools that list domains, so the lack of explicit exclusions is not a meaningful gap.

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?

With no annotations provided, the description carries the behavioral disclosure burden. It clearly states that the tool returns a JSON array and enumerates the fields in each fund object, plus the active+closed inclusion. It could mention error behavior or ordering, but for a simple list operation it is transparent.

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

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

The description is compact, front-loaded with the core purpose, and organized with Args and Returns sections. Every line provides useful information without redundancy or filler.

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

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

For a one-parameter read-only list tool, the description covers the operation, the parameter, and the return shape. It lacks pagination or error-handling details, but those are not essential given the 'all funds' wording and the explicit field list.

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 description names user_id and says it is the user's ID, which adds minimal meaning beyond the schema's required string property. Since schema description coverage is 0%, the description does not fully compensate, but the single parameter is straightforward enough that this is still adequate.

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

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

The description clearly states the verb ('List'), the resource ('all hedge funds'), and the scope ('for a user' with active and closed). This distinguishes it from siblings like get_fund, get_active_fund, and create_fund by describing a collection-level read operation.

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 clear context for when to use this tool: to retrieve all hedge funds for a user, including both active and closed funds. It does not explicitly name alternatives or state when not to use it, but the scope is unambiguous.

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?

There are no annotations, so the description carries the disclosure burden. It explicitly says the tool returns a JSON array and lists all returned fields, which tells an agent what to expect. The verb 'List' implies a non-mutating read, though it does not mention authorization, ordering, or edge cases.

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 definition is compact and front-loaded: a one-sentence purpose, an Args line, and a Returns line. The return-field list adds a little redundancy given the output schema exists, but it is still brief and scannable.

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

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

For a simple one-parameter listing tool, the description covers the action, argument meaning, and return shape. It omits alternative routing and edge-case behavior, but nothing essential is missing for calling it correctly.

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

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

The input schema only provides the property name and type string, so the description is the sole source of meaning. 'user_id: The creator's user ID' fully conveys the parameter's role. It could go further with format guidance, but for a single required parameter this is sufficient.

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 first sentence, 'List all strategies created by a user,' uses a specific verb and resource and makes the scope (per creator user_id) explicit. This cleanly differentiates it from sibling list tools like list_bots and list_funds.

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 establishes that the tool is appropriate for listing strategies by creator and requires a user_id, which is clear context. However, it does not state when to prefer an alternative such as get_strategy_report, nor does it give exclusions or prerequisites beyond the user_id argument.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the non-obvious consequence of triggering wind-down of the bot's positions and requires fund ownership. It stops short of stating whether the removal is irreversible or what other positions or fund settings may be affected as a cascade.

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

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

The description is compact, front-loaded with the core purpose, and the Args block is easy to scan. The final "Returns success or error" line is redundant given that an output schema exists, but it does not add meaningful bloat.

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 four-parameter mutation tool with no annotations, the description covers the core behavior, side effect, ownership constraint, and optional parameter. The output schema appears to handle return shape, so the description is reasonably complete. It lacks guidance on failure modes and alternatives, but the agent has enough to invoke correctly in the primary use case.

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

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

The schema has no descriptions (0% coverage), so the description's Args list is necessary and does add meaning: user_id is tied to fund ownership, reason is marked optional, and bot_id is identified as the removal target. However, fund_id is just restated as "The fund's ID" and bot_id adds only minimal semantic value beyond its name.

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

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

The description clearly states the action: "Remove a bot from a fund's roster," and adds the important side effect of triggering wind-down of positions. This distinguishes it from related sibling tools like add_bot_to_fund and swap_bot_in_fund without requiring the agent to infer from the name alone.

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 usage context is implied by the action and the ownership prerequisite is noted via "must own the fund." However, there is no explicit guidance about when not to use this tool or which alternatives (e.g., swap_bot_in_fund for replacement, close_fund for closing the whole fund) should be preferred in other scenarios.

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?

With no annotations provided, the description carries the full disclosure burden and does so well. It states the code is run through static checks and a full historical backtest, that nothing is persisted, and that no Strategy or StrategyVersion rows are created. It also describes the JSON return shape including success, metrics, and error details, giving the agent a solid model of behavior.

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

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

The description is well-structured and front-loaded with the key behavioral distinction: sandbox, no persistence, fastest path. The Args and Returns sections are compact and every sentence adds value. There is no filler or repetition of the tool name.

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

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

Given the tool's moderate complexity, an output schema exists, and 4 parameters are documented directly in the description, this is complete. The agent knows the required input shape, the strategy contract constraints, the defaults, the lack of side effects, and the return structure. 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 0%, so the description must compensate, and it does thoroughly. Every parameter is explained with types, examples, and constraints: code must define METADATA and extend Strategy with on_bar, domain and symbol get concrete examples, and user_id's purpose is disclosed. It even references CREATOR_API.md for the full contract.

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

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

The description opens with a specific verb and resource: 'Run a sandbox backtest of strategy code without persisting anything.' It distinguishes the tool from submit_strategy and similar persistence-heavy siblings by explicitly stating no Strategy or StrategyVersion rows are created. This leaves no ambiguity about what the tool does.

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

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

The description clearly says this is the fastest way to test a strategy and should be used for rapid iteration. It implies but never explicitly names the alternative for when persistence is desired, such as submit_strategy. The guidance is clear on context but not exhaustive on when-not-to-use.

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?

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses the complete validation pipeline (including holdout being pass/fail only), the post-condition of status='incubating', and that promotion to live requires a proven track record. It also states the structure of the return JSON, including error details.

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 organized efficiently: purpose, numbered pipeline, post-conditions, argument list, and return format. Every section adds necessary information and the pipeline breakdown is valuable rather than fluff. It remains readable despite its length.

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

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

Given the tool's complexity (7-stage pipeline, registration side effects, multiple parameters), the description is complete: it covers the validation process, success/failure outcomes, promotion path, parameter semantics, and return schema. The only mild gap, alternative tool selection, is already covered under usage guidelines. An agent has enough context 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 0%, so the description must compensate and largely does. The Args section explains all five parameters with meaningful semantics: 'code' is described as 'Python source code implementing the Strategy contract', 'domain' gets an example, and 'symbol' is tied to historical data. It could go further with constraints or allowed values, but with no enums present it is solid.

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

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

The description states a specific verb and resource: 'Submit a strategy for full validation and live deployment.' It then enumerates the 7-stage validation pipeline, making it clear what the tool does and how it differs from simpler test or report tools. The mention of live paper trading adds further distinction from sibling tools.

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

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

The description implies when to use the tool (submitting a strategy for full validation and live deployment) but does not explicitly contrast with alternatives such as sandbox_backtest, which seems like the main alternative for testing without deployment. There are no exclusion criteria or when-not-to-use guidance, leaving routing decisions partially 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?

No annotations exist, so the description carries full burden. It discloses side effects (closing old positions, opening new ones), a prerequisite (user must own the fund), cost implication (friction), weight default behavior, and the return shape (updated roster entry and friction estimate). This is robust for a mutating 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?

Purpose and behavior are front-loaded in the first line, followed by a brief warning, then a tight Args block and return statement. No filler; every sentence adds information that is not in the 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?

The description covers purpose, side effects, prerequisite, parameter meanings, cost warning, and return value. With an output schema present and all parameters described, nothing essential is missing for an agent to call it correctly.

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

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

Schema description coverage is 0%, yet the description documents all seven parameters with meaningful semantics: ownership requirement for user_id, role of old vs new bot IDs, a domain example, weight defaulting to old bot's weight, and optional reason. This fully compensates for the schema's lack of 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 and resource ('Swap one bot for another in a fund's roster'), describes the mechanism (closes old positions, opens new ones), and naturally distinguishes itself from sibling tools like add_bot_to_fund and remove_bot_from_fund by describing the combined atomic operation.

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

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

Provides clear context: the tool is for replacing a bot, and explicitly instructs to 'use estimate_swap_cost first' because it incurs friction cost. It does not explicitly contrast with add/remove alternatives, so it falls just short of full exclusion 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 are absent, so the description carries the behavioral disclosure burden. It clearly discloses partial-update semantics ('Only provided fields are updated; others remain unchanged'), an ownership requirement, and a return status. It doesn't detail side effects or validation rules, but for a mutation tool this is solid.

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

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

The description is compact, well-structured, and front-loaded with a one-sentence purpose. The Args list, partial-update note, and return statement each earn their place without filler or redundancy.

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

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

For a five-parameter mutation tool with no annotations, the description covers parameter semantics, authorization, mutation behavior, and return status; the output schema fills in return shape. The main gap is the lack of explicit guidance on when to prefer this over a sibling like update_fund_weights.

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

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

Schema description coverage is 0%, so the per-parameter explanations are essential and well done. Each argument gets meaningful semantics: examples for percentage fields, a plain-language explanation of regime_veto_enabled, and the note that omitted fields remain unchanged.

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

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

The description clearly states the action and target: 'Update a fund's risk caps and settings' and enumerates the specific fields involved. It doesn't explicitly distinguish itself from sibling tools like update_fund_weights, but the resource and purpose are unambiguous.

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

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

There is no explicit guidance about when to use this tool versus alternatives such as update_fund_weights or create_fund. The description does provide a prerequisite ('must own the fund'), but it doesn't mention exclusions or alternative routing, leaving usage context mostly implicit.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions that the user must own the fund and that it 'Returns success or error.' It does not explain whether the update replaces existing weights, validates that weights sum to 100, or has other side effects.

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

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

The description is fairly concise and well-structured, with Args and Returns sections. It avoids excessive verbosity, though the Args block repeats parameter names that are already in the 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?

The description covers the core parameters and the return result, and an output schema exists. However, it omits important operational context such as whether weights are merged or replaced, whether there are constraints on the weights, and what error conditions beyond ownership look like.

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

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

Schema description coverage is 0%, so the description must compensate. It provides useful meaning for all three parameters, especially for 'weights' with an example mapping bot_id to weight percentage. The 'must own the fund' note adds important context to user_id.

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 action ('Update allocation weights') and a specific resource ('bots in a fund's roster'). It is clear enough to distinguish from siblings like update_fund_caps, though it does not explicitly name that sibling.

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

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

The description implies the tool is used to change bot weight allocations and gives a prerequisite ('user_id must own the fund'), but it does not explicitly describe when to use this tool versus alternatives like swap_bot_in_fund or update_fund_caps.

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