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 discloses a prerequisite: 'Requires PRIVATE_KEY in .env.' and the 'pending' constraint. However, it does not disclose what happens on successful cancellation (e.g., irreversible, no confirmation), potential error conditions, or whether the order is removed from the book immediately. This is some context, but not rich behavioral detail.

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 entire description is two short sentences, immediately stating the purpose and the key prerequisite. It is front-loaded and free of unnecessary detail, making it easy for an agent to process quickly. Every word earns its place.

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

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

The tool is simple with two well-documented parameters, but there is no output schema and the description does not mention what the tool returns (e.g., success status, transaction hash, or error details). It also does not clarify behavior for invalid or already-cancelled orders. Given the lack of output schema, the description should have provided at least a hint about the return value or expected outcome, but it is otherwise adequate for the tool's simplicity.

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

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

The input schema already provides 100% coverage with descriptions for both parameters, each directing the user to 'get_orders' for finding valid values. The tool description does not add additional parameter semantics beyond this. Since the schema already explains the parameters well, 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?

The description clearly states the tool's action with a specific verb and resource: 'Cancel a pending trading order.' This distinguishes it from other trading tools like create_order or get_orders, though it does not explicitly name any sibling alternatives. The phrase 'pending trading order' adds useful scoping.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives. It implicitly suggests that only pending orders can be cancelled, but it does not explain when cancellation is appropriate or mention any related tools (e.g., get_orders for finding order IDs is only in the schema, not the description). There is no 'when not to use' or comparison with other tools.

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 the PRIVATE_KEY requirement and the asset transformation, but it omits details on reversibility, idempotency, or failure conditions. This is a clear but incomplete behavioral disclosure.

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 three short sentences, front-loaded with the core purpose, then adding sequencing and a prerequisite. Every sentence earns its place with no fluff 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?

For a simple 3-parameter claim operation, the description provides the essential context: purpose, sequence, and key requirement. The schema fully covers parameters. It lacks mention of output or edge cases, but the overall package 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?

All three parameters are fully documented in the schema, including pool index meanings, a 'must match' constraint, and an example collateral token. The description adds no additional parameter-level semantics, so the schema provides the baseline 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?

The description clearly states the tool's action ('Claim redeemed TLP tokens back as underlying collateral') and positions it as the final step in a defined sequence, distinguishing it from siblings like 'redeem_tlp' and 'unstake'.

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 places this tool in the 'unstake → redeem → claim' flow, giving clear timing relative to other operations. It also notes the PRIVATE_KEY prerequisite. However, it does not explicitly name alternatives or state when not to use it beyond the implied order.

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 full responsibility for behavioral disclosure. It only mentions the need for a PRIVATE_KEY, which implies authentication but does not explain side effects, reversibility, or what happens during collection. The tool likely mutates state (e.g., transfers funds), but this is not 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 a single sentence that states the primary action and a critical requirement. It wastes no words and front-loads the essential information, making it highly concise and well-structured.

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 this is a financial mutation tool with no annotations and no output schema, the description is too sparse. It does not explain the behavioral outcomes, edge cases, or prerequisites beyond a private key, leaving significant gaps for an agent to safely invoke the tool. The schema covers parameters but not operational context.

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

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

Schema coverage is 100% with both parameters described in detail, including the pointer to get_positions for marketIndex. The description itself adds no parameter-specific detail beyond the schema, so the baseline of 3 is appropriate given that the schema handles semantics effectively.

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: 'Collect accumulated funding fees for a position.' This is a specific verb and resource, making the purpose unambiguous. However, it does not explicitly distinguish this tool from siblings like claim or harvest_reward, which could overlap in function, so it lacks direct 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 provides a prerequisite ('Requires PRIVATE_KEY in .env.') and the schema hints to use get_positions for finding marketIndex, which offers some contextual guidance. Yet there is no explicit statement about when to use this tool versus alternatives such as claim or harvest_reward, so usage is only implied rather than clearly contrasted.

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 transparency burden. It discloses the PRIVATE_KEY requirement, which is a meaningful behavioral trait (needs authentication). However, it does not mention side effects on positions, return values, or failure modes, which would be valuable for a mutation 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 description is concise at three short sentences, front-loaded with the purpose, followed by the prerequisite and a key parameter tip. Every sentence contributes essential information without waste.

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 10-parameter trading mutation with no output schema, the description gives the essential prerequisite and a pointer for decimals, but it lacks higher-level context such as when to use it versus swap, or what the expected outcome is (e.g., order visible via get_orders). The schema covers parameters well, so this is adequate but not comprehensive.

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's note that 'Size and collateral amounts are raw integers' is redundant with the schema's detailed parameter descriptions and adds no new semantic value beyond reiterating what the schema already 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 clearly states the tool's function with a specific verb and resource: 'Create a trading order on Typus Perp.' This distinguishes it from sibling tools such as get_orders and cancel_order, as it is the creation action in the order lifecycle.

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 concrete usage context: it requires PRIVATE_KEY in .env and instructs the agent to use get_markets for size_decimal, which is a prerequisite and a preparatory step. It does not explicitly mention alternatives or 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?

With no annotations, the description carries the full transparency burden. The verb 'Get' implies read-only behavior, and the description specifies the returned data types (TVL and per-token amounts), but it does not explicitly state side-effect freeness or other behavioral traits.

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

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

The description is a single, well-structured sentence that front-loads the action and lists the key data points without unnecessary words. Every word contributes to understanding the tool's 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 parameterless getter, the description provides adequate context on purpose and output content. However, it does not explicitly state whether it returns all pools or a single pool, nor the return structure, but these are easily inferred from the zero-parameter 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?

The tool accepts zero parameters, so the schema has full coverage and no parameter descriptions are needed. The baseline for 0-parameter tools is 4, and the description adds sufficient context about what information is returned.

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 the specific verb 'Get' and clearly identifies the resource as 'TLP liquidity pool information' with explicit mention of TVL and per-token liquidity amounts. This distinguishes it from sibling tools like get_markets and get_stake_pools, which target different data.

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

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

No explicit when-to-use guidance or alternative tools are mentioned. The description implies usage through the name and content, but there is no exclusionary language to help differentiate from similar getter tools.

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 must carry the transparency burden. It clearly discloses that this is a read-only operation returning 'active' markets, which implies filtering and no side effects. It doesn't mention any caveats like pagination or authentication, but for this simple getter, the behavior is well understood.

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

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

The description is a single, front-loaded sentence that includes the action, resource, and key details. Every part is relevant and it is concise without wasting 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?

Given the tool's simplicity (no parameters, no output schema), the description provides sufficient context by specifying the content of the return data. It covers the essential information an agent needs to decide whether to use 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 tool has no parameters, so the baseline is 4. The description adds context by listing return fields (leverage, fees, funding rates), which helps the agent understand what to expect, though it doesn't explain any parameter usage since 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?

The description clearly states the tool fetches all active trading markets and their configurations on Typus Perp, mentioning specific data types like leverage, fees, and funding rates. This aligns with a specific verb (Get) and resource (markets), and is distinct from sibling tools like get_positions or get_orders.

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 for retrieving market data when needed. While it doesn't explicitly mention alternatives or exclusions, the purpose is clear enough to differentiate from other tools. In context of the sibling list, this is the only market-related getter, so usage context is evident.

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 burden. It discloses the filtering behavior (pending/unfilled) and the query scope, but does not explicitly confirm it is read-only or describe return format/pagination. The verb 'Get' implies a read operation, which adds some transparency.

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

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

The description is a single, front-loaded sentence that contains no redundant information. It earns its place by clearly and efficiently conveying the tool's purpose and scope.

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

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

This is a simple read-only tool with one parameter and no output schema. The description fully explains what the tool does and the query scope. While it does not explicitly describe the return format, that is implied by the tool name and description, making it sufficiently complete for this complexity.

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 for the single parameter is 100%, so the baseline is 3. The description mentions 'for a specific wallet address', which aligns with the schema but adds no additional meaning beyond what the schema already states.

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 'Get', the resource 'trading orders', and the scope 'pending (unfilled) for a specific wallet address'. This distinguishes it from siblings like create_order, cancel_order, and get_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?

The description provides clear context: it retrieves pending orders for a given address, which implies when to use it. However, it does not explicitly mention alternatives or exclusions, so it falls slightly short of a 5.

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

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

No annotations are provided, so the description carries the full burden. It discloses that this is a read-only operation ('Get') and lists the specific return fields, providing useful transparency about the response. It does not mention error handling, rate limits, or authorization, but for a simple query this is sufficient.

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

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

The description is a single, efficient sentence that front-loads the action and lists key fields without unnecessary words. No redundancy or 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?

Given the tool's simplicity (one parameter, no output schema), the description is complete enough: it states what is returned and the granularity ('for each position'). It does not specify the response structure (e.g., array), but this is implied. It adequately covers the main 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 fully describes the single parameter 'address' with a clear description. The tool description only repeats 'for a wallet address' without adding extra semantic meaning beyond the schema, so it does not compensate beyond the baseline.

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

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

The description clearly states the tool's function: 'Get all open positions for a wallet address' and specifies the data returned (liquidation price, unrealized PnL, etc.). This is specific and differentiates from sibling tools focused on stakes, orders, and markets.

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 when open positions are needed, but does not explicitly mention when to use this tool over siblings or list exclusions. No alternative tools are referenced, so guidance is minimal.

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. The verb 'Get' implies a non-destructive read operation, and it mentions the specific data fields returned. However, it does not disclose whether the response is a list or single object, potential rate limits, or any other behavioral nuances beyond the basic read-only implication.

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

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

The description is a single, concise sentence that front-loads the primary purpose and key included data. Every word earns its place, with no filler or redundancy.

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

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

Given the tool's simplicity (no params, no output schema), the description is mostly sufficient. It states the two key data points returned, but it does not specify whether the result is a collection or single item, and it may omit other fields. This is a moderate gap for a tool with no output schema to fall back on.

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 is 4. The description adds context about the operation, but there are no parameter semantics to clarify. It appropriately avoids unnecessary detail.

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 gets TLP staking pool information, including current TLP price and total staked shares. The verb 'Get' plus specific resource 'TLP staking pool information' makes the purpose clear. It does not explicitly distinguish from siblings like get_lp_pools, but the TLP-specific focus provides reasonable 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 provides no guidance on when to use this tool versus alternatives such as get_user_stake or get_lp_pools. There is no mention of scenarios, prerequisites, or exclusions. This leaves the agent to infer usage purely from the name and description.

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 must carry the burden. The verb 'Get' implies a read-only operation, and it discloses the return fields, but it does not explicitly state side effects, permissions, or error behavior. Basic behavior is implied but not fully 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 a single sentence, front-loaded with the verb and resource, and every phrase adds value (staked share amounts, claimable rewards, unstaking cooldown). 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?

For a simple one-parameter read tool with no output schema, the description provides a reasonable summary of the response ('staked share amounts, claimable rewards, cooldown shares'), which is sufficient. It could mention error handling or return format, but given the simplicity, it is nearly 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?

The input schema fully documents the sole parameter 'address' with a clear description ('Sui wallet address (0x...) to query staking info for'), so schema coverage is 100%. The description adds little beyond the schema, so the baseline 3 is appropriate.

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

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

The description uses a specific verb 'Get' with a clear resource ('user's TLP staking positions') and enumerates the specific data returned (staked share amounts, claimable rewards, unstaking cooldown). This clearly distinguishes it from sibling tools like get_stake_pools or get_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?

The description implies this tool is for reading a specific user's staking data, but it does not explicitly state when to use it over siblings like get_stake_pools or provide exclusions/alternatives. Usage context is implied by the purpose.

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 adds the critical prerequisite that PRIVATE_KEY is required in .env, which is valuable context. However, it does not disclose that harvesting is an on-chain transaction involving gas fees, potential failures, or that rewards are transferred to the user. More detail on side effects is needed.

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 consists of two short, information-dense sentences. The first sentence states the core action and purpose; the second provides a crucial prerequisite. There is zero redundancy or irrelevant phrasing.

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

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

This is a mutation tool with no output schema and no annotations, so the description must explain return values and failure behavior. It does not mention what the tool returns on success, whether it can be called when no rewards are pending, or any failure conditions. The description is insufficient for a tool that likely executes a financial transaction.

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

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

The input schema already provides full documentation for the only parameter (stakePoolIndex), including the meaning of '0' and '1'. The description adds no additional parameter semantics, so baseline 3 applies due to high schema 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?

The description clearly states the action 'Harvest' and the resource 'pending staking reward tokens', making its purpose unmistakable. It also gives a concrete example (TYPUS tokens) to remove ambiguity. This distinguishes it from siblings like 'claim' or 'collect_funding_fee'.

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 is for collecting staking rewards, but does not explicitly state when to use this tool versus alternatives like 'claim' or 'collect_funding_fee'. There is no mention of exclusions or preferred contexts, so guidance is only 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?

The description discloses the private key requirement and the effect of reducing liquidation risk, which are behavioral traits not covered by the schema. With no annotations, it carries some burden but does not fully disclose other important aspects such as whether it's an on-chain transaction, what it returns, or if it is reversible.

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 consists of two concise sentences: the first states the action and purpose, and the second highlights the prerequisite. It is front-loaded, contains no filler, and every word contributes meaning.

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 financial mutation with no annotations or output schema, the description is somewhat sparse. It covers the core action and a key prerequisite, but does not specify what the agent should expect as a return value (e.g., transaction hash) or any additional side effects, leaving gaps for an agent to infer.

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 100% description coverage, with each parameter clearly explained (e.g., 'raw integer with token decimals' and 'Use get_positions to find the marketIndex'). The tool description adds no additional parameter semantics, so the baseline score 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?

The description uses a specific verb ('Add') and identifies the resource ('collateral to an existing position'), making the action clear. It also states the purpose ('reduce liquidation risk'), which distinguishes it from sibling tools like release_collateral and helps the agent understand 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?

The description provides clear context for when to use the tool ('to reduce liquidation risk') and specifies it applies to an existing position, which helps differentiate it from position creation. However, it does not explicitly mention alternatives like release_collateral or scenarios where this tool should not be used.

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 a prerequisite (PRIVATE_KEY) and lacks details about token transfers, minting, staking side effects, or reversibility. This is insufficient for a write-heavy DeFi 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 concise, with one clear sentence and a prerequisite note. It is front-loaded and contains no redundant or filler 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?

Despite the schema covering parameter semantics, the description omits critical operational context such as when to use this tool, the on-chain flow, or potential failures. With no output schema and no annotations, the description is insufficient for a complex 6-parameter transaction.

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 covers all 6 parameters with 100% description coverage, so the added value from the tool description is minimal. It does not elaborate on how parameters interact (e.g., stakePoolIndex must match poolIndex) beyond what the schema states.

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: deposit tokens into the TLP liquidity pool and optionally stake the resulting TLP. It distinguishes itself from siblings like stake_lp and redeem_tlp by combining minting and staking.

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 compare with alternatives like stake_lp. The phrase 'optionally stake' implies a choice but provides no guidance on when to use this tool versus staking existing TLP. The prerequisite note about PRIVATE_KEY is helpful but not a usage guideline.

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 transparently states a non-obvious behavior: redeeming does not directly return tokens to the wallet and requires a subsequent claim() call. This is critical context that prevents incorrect use.

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 yet informative, consisting of three sentences. It leads with the main purpose, immediately flags the critical claim() requirement, and ends with the flow and environment prerequisite. 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?

Despite no output schema or annotations, the description provides the necessary context for a two-parameter redeem step: the full workflow, the non-direct return behavior, and the required environment variable. This is sufficient for an agent to select and 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?

The input schema already provides thorough descriptions for both parameters: share ('raw integer, omit to redeem all') and poolIndex ('0' = mTLP, '1' = iTLP). The tool description adds no additional parameter-specific meaning, so the baseline score of 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 purpose is clearly stated with a specific verb and resource: 'Redeem TLP tokens (already unstaked) for underlying assets.' It distinguishes from siblings by emphasizing the 'already unstaked' precondition and by placing itself between unstake and claim in the full flow.

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 explains when to use the tool via the full flow: unstake → redeem_tlp → claim. It also warns that tokens are not returned directly and that claim() must be called afterward, which is a clear behavioral guideline. The PRIVATE_KEY requirement is a concrete prerequisite.

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 mentions the need for PRIVATE_KEY but says nothing about the effect on the position, irreversibility, gas costs, or return value. For a mutation tool, this is under-specified.

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

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

The description is a single sentence that front-loads the action and includes a necessary prerequisite. It is appropriately minimal with no wasted words, making it highly scannable.

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

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

This is a mutation tool with no annotations and no output schema. The description does not mention what the tool returns, whether the withdrawal is permanent, or any side effects. While the schema covers parameters, the overall context is incomplete for a transaction-bearing 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?

All three parameters have thorough schema descriptions (100% coverage), so the baseline is 3. The description itself adds no parameter-specific meaning beyond what the schema already 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 clearly states the action ('Withdraw excess collateral') and the resource ('existing position'), using a specific verb that distinguishes it from sibling tools such as increase_collateral. The purpose is immediately apparent and 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?

The description implies when to use the tool (when excess collateral exists) but does not explicitly contrast it with alternatives like increase_collateral. The only usage guideline provided is the requirement for PRIVATE_KEY in .env, which is a prerequisite rather than a usage context.

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 the private key requirement and does not disclose that staking is a transaction with side effects (e.g., gas costs, potential failure, irreversible state changes). This is a significant gap for a write-action 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 description is a single sentence that is front-loaded with the action and resource, and includes a necessary prerequisite. Every word adds value, with no 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 tool has a simple 2-parameter schema and no output schema, but as a staking (mutation) tool with no annotations, it lacks essential contextual details such as potential error conditions, transaction confirmation expectations, or gas implications. The description is minimally viable but has clear gaps in operational context.

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

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

The input schema fully documents both parameters (amount and stakePoolIndex) with descriptions and allowed values. The description adds no additional parameter-level context, so it meets the baseline of 3 for high schema coverage without enhancement.

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 specific action (stake), the resource (existing TLP tokens), and the purpose (to earn rewards). The phrase 'existing TLP tokens' effectively differentiates it from sibling tools like mint_stake_lp, making the tool's role 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?

The description provides a clear prerequisite ('Requires PRIVATE_KEY in .env') and implicitly distinguishes this tool from minting via 'existing TLP tokens.' However, it does not explicitly name alternative tools or state when not to use this tool, so it falls short of full 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 of behavioral disclosure. It only mentions that a PRIVATE_KEY in .env is required, which is a useful security detail, but fails to disclose that this is an on-chain transaction with potential slippage, fees, or the nature of the returned result (e.g., transaction hash). The scope of side effects remains largely opaque.

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

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

The description is two short sentences, front-loaded with the core action in the first sentence and a key requirement in the second. Every word is useful, with no filler or redundancy.

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

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

For a mutating swap tool with no annotations and no output schema, the description is under-specified. It omits any guidance on expected return values, transaction lifecycle, failure scenarios, or slippage/deadline parameters. While the schema covers parameters, the overall context for invoking the tool safely and understanding outcomes is incomplete.

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 descriptions for all four parameters (100% coverage), so the description adds no extra meaning beyond what is already in the schema. The baseline for full schema coverage is 3, and the description does not compensate or clarify any parameter semantics further.

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 ('Swap') and resource ('tokens using Typus Perp liquidity pool'), which clearly states the tool's function. It distinguishes itself from sibling tools (e.g., create_order, collect_funding_fee) by being the only token swap tool in the list.

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 when one wants to swap tokens, but it does not explicitly describe when to use it compared to alternatives like create_order or cancel_order. No exclusions or alternative tool references are provided, leaving usage context implicit rather than directive.

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 disclosing behavioral traits. It notes that the action begins an unlock countdown and requires PRIVATE_KEY, which is useful. However, it does not mention reversibility, side effects, or what happens after the countdown, leaving some behavioral gaps.

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

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

The description is concise with two short sentences: one defining the action and one stating the prerequisite. Every word earns its place, no unnecessary detail.

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 adequately conveys the core function and prerequisite, and the schema handles parameter details. It is reasonably complete for a transactional tool, though it could briefly mention the link to unstake_redeem or the overall flow. Given the schema richness, this is sufficient.

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 thorough descriptions for all three parameters (share, poolIndex, stakePoolIndex), covering semantics fully. The tool description adds no parameter-specific information, and since schema coverage is 100%, 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?

Description clearly states 'Begin unstaking TLP' and adds the distinctive 'starts the unlock countdown', making it specific to initiating a timed process. This distinguishes it from siblings like unstake_redeem or redeem_tlp which likely handle later steps.

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 for starting the unstaking process and mentions the PRIVATE_KEY prerequisite, but does not explicitly differentiate from alternatives or provide when-not-to-use guidance. Clear context but no exclusions or alternative references.

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 explicitly warns that tokens are NOT returned directly to the wallet and that a separate claim() call is required, plus the PRIVATE_KEY prerequisite. This adds important behavioral context beyond the 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?

The description is succinct with exactly two sentences and a brief warning. Every sentence provides essential information, and the most critical detail (the claim() requirement) is prominently placed.

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 is a transaction with no output schema, the description adequately covers the action, the required follow-up, and the environment prerequisite. It doesn't describe return values or failure modes, but these are less critical when the schema is complete and the warning covers the main usage 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?

Schema description coverage is 100%, so all parameters are already documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, so the baseline of 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 clearly states the tool unstakes and immediately redeems TLP for underlying tokens in one transaction. The verb 'unstake and immediately redeem' is specific and the resource (TLP) is named, distinguishing this combined operation from sibling tools like unstake and redeem_tlp.

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 'in one transaction' implies a combined operation versus separate calls, providing clear context. The warning that claim() must be called afterwards is a crucial usage directive, though it does not explicitly name alternative approaches or list when not to use this tool.

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