Tronsave MCP Testnet

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

Discloses side effects beyond annotations: marks order non-matchable, refunds locked balance, effectively destructive. Also confirms idempotency stated in annotations by noting cancelling an already-cancelled order is a no-op. No contradiction with annotations.

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

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

Description is concise (4 sentences) and front-loaded with the core action. Every sentence adds essential information without redundancy.

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

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

Given the tool's complexity (side effects, idempotency, failure conditions, prerequisites), the description covers all necessary context. The output schema exists, and the description adequately indicates the return value.

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

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

Schema coverage is 100%, but the description adds meaning: orderId must be an active order owned/authorized by the session, and mentions expected failure scenarios. This adds value beyond the schema description.

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

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

The description clearly states the tool cancels an open order by orderId and returns the cancelled order payload. It explicitly distinguishes from sibling tronsave_update_order by advising to use that tool for price/receiver changes.

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

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

Explicitly states when to use (open order, authorized session), when not (fulfilled orders, unauthorized callers), and provides alternatives (tronsave_update_order). Also mentions prerequisites (signature session, mcp-session-id) and a verification step (use tronsave_get_order first).

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

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

Annotations already indicate mutation and non-idempotency. The description adds the side effect 'creates a live order matchable by the market' and critically warns that stale estimates may cause revert or wrong price. No contradictions with annotations.

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

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

Description is several sentences but each adds value. Starts with purpose, lists key inputs, then side effect, prerequisites, derivation, and freshness. Well structured, not overly verbose.

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 complexity (8 params, nested objects, output schema exists), the description covers purpose, key inputs, side effect, prerequisites, derivation steps, and freshness. Does not explain output schema (okay, it exists) or error conditions, but sufficient for a well-documented tool.

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

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

Schema coverage is 100% with detailed descriptions. The tool description adds extra semantic value by explaining the relationship between parameters (e.g., derive orderUnitPrice from estimate) and providing derivation rules beyond what schema offers. Baseline 3 improved to 4.

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 'Create a new buy order on the TronSave market,' with a specific verb and resource. It distinguishes from sibling tools like tronsave_update_order and tronsave_cancel_order by explicitly being the create variant and listing payment method options.

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 usage prerequisites (requires signature session, mcp-session-id) and derivation guidance (always derive prices from latest estimate). It implies when to use by explaining payment methods but does not explicitly compare with the internal create tool (tronsave_internal_order_create). Offers freshness warning.

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

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

The description adds significant behavioral context beyond the annotations: it explains the side effect ('stops all future executions matching that rule; the rule cannot be restored'), affirms idempotency ('deleting a non-existent or already-removed id returns success'), and mentions the requirement for a session. These details are not captured by `destructiveHint` or `idempotentHint` alone.

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 yet comprehensive: a single sentence for the core action, followed by side effects, idempotency, prerequisites, and usage guidance. Every sentence adds value, and the 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?

Given the tool's simplicity (one required parameter) and the presence of an output schema (as indicated by context signals), the description covers all necessary aspects: purpose, side effects, prerequisites, idempotency, and alternative approaches. It is complete and leaves no important gaps.

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

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

The single parameter `id` is fully described in the schema (100% coverage) with type, minimum length, and description. The description does not add further semantic details beyond what the schema already provides. Thus a 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 clearly states the action ('Permanently delete one auto-buy rule by `id`') and the resource ('auto-buy rule'). It distinguishes from sibling tools by explicitly referencing `tronsave_get_user_auto_setting` for listing and suggesting disabling/updating as alternatives for reversibility.

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

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

The description provides explicit usage guidance: it notes required prerequisites ('Requires a signature session and `mcp-session-id`'), suggests listing rules first using a sibling tool, and advises preferring non-destructive actions ('prefer disabling/updating instead when reversibility is desired'). This clearly tells the agent when and how to use the 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?

Description adds behavioral details beyond annotations: no session required, backend rate limits apply, data freshness (every ~3 seconds), and that it is read-only and safe to call repeatedly. All align with annotations (readOnlyHint, idempotentHint, openWorldHint).

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 core purpose. It is slightly lengthy but every sentence adds value. Could be marginally tighter, but overall effective.

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 7 parameters and existence of an output schema, the description is complete: it explains purpose, usage, freshness, alternatives, and output field usage. No gaps remain.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add specific parameter semantics beyond the schema, but it does mention the output fields used to populate create_order inputs, which provides context.

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

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

The description clearly states it quotes price and availability for buying ENERGY or BANDWIDTH before placing an order. It specifies the resource type and the action (estimate), and distinguishes from siblings like tronsave_list_order_books and tronsave_get_min_price.

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

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

Explicit guidance is provided: use before placing an order, re-run immediately before tronsave_create_order, never reuse a quote more than a few seconds old. Also mentions alternatives for order-book depth and minimum unit price.

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 goes well beyond annotations by explaining the side effect of issuing secret material, non-idempotency, key rotation implications, and security warnings (never log raw keys, rejection possible). No contradiction with annotations.

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

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

The description is concise and front-loaded with clear purpose. Every sentence adds value: purpose, return value, side effects, usage guidance, and security notes. 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?

Given the tool has no parameters and an output schema exists, the description covers all necessary aspects: purpose, side effects, security handling, and usage context. It is complete for an effective agent 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 has zero parameters, so the description does not need to add parameter details. Per the criteria, baseline is 4.

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 generates an API key credential for the current user, specifying the verb and resource. However, it does not explicitly differentiate from the sibling tronsave_revoke_api_key, missing an opportunity to distinguish when to generate vs revoke.

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

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

The description provides explicit context for use, including required prerequisites (signature session, mcp-session-id) and behavior on key rotation. It lacks explicit when-not-to-use guidance or direct comparison with alternatives.

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

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

Annotations indicate read-only, idempotent, open-world. Description adds session requirement, API key handling details, and operation constraints, enhancing 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?

Structured with purpose first, then prerequisites, usage triggers, and constraints. Slightly verbose about session types but still concise overall.

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

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

Covers purpose, usage, session requirements, constraints. Output schema exists to define return values, so description is complete for 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?

Schema coverage is 100% for the single parameter. Description adds 'TRX only' context and reinforces minimum deposit, providing marginal added value beyond 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 fetches a specific deposit address for the TronSave internal account, with constraints (TRX only, min 10 TRX). It is specific and distinguishable from siblings.

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

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

Explicitly states when to trigger (user asks for deposit address or top-up) and prerequisites (logged-in session with mcp-session-id). Lacks explicit alternatives but provides good 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?

Annotations already mark readOnlyHint, openWorldHint, and idempotentHint. The description reinforces that it's read-only and does not change chain state, and adds valuable context: freshness of balance updates within seconds, and that it never accepts API keys via arguments. No contradictions.

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 slightly lengthy but well-structured: purpose first, then prerequisites, usage, behavioral notes, and freshness. Every sentence contributes meaningful information, though some phrasings could be trimmed for brevity.

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

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

For a zero-parameter tool with output schema and annotations, the description covers all important aspects: what it returns, preconditions (session), behavioral traits, and data freshness. It is fully adequate for the agent 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 parameters with 100% coverage. Description adds no parameter-level detail, which is unnecessary. A baseline of 4 is appropriate for parameter-less tools.

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 it retrieves the TronSave internal account profile, including represent address, deposit address, and balance in SUN. It specifies 'for the current session,' distinguishing it from related tools like tronsave_get_deposit_address or tronsave_get_user_info.

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 requires a logged-in MCP session from tronsave_login and explains how to include the session ID. It advises using when the user needs linked address, deposit address, or internal balance, and clarifies it's the api-key internal account, not the on-chain wallet. While it doesn't list alternative tools for on-chain queries, the context is sufficient.

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

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

Annotations already declare `readOnlyHint`, `openWorldHint`, and `idempotentHint`. The description adds significant behavioral context: it is read-only and idempotent, no login required, optional session auth, and crucially, data freshness (minPrice changes every ~3 seconds, requiring re-fetch). This information goes beyond annotations and is essential for correct agent 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: purpose first, followed by return type, parameters, auth, idempotency, freshness warning, and pairing suggestions. Every sentence is informative and non-redundant. It front-loads the essential information, making it easy for an AI to quickly parse and act.

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

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

Given the tool has 4 parameters (1 enum), is read-only/idempotent, has an output schema (implied by return description), and has many siblings, the description is remarkably complete. It covers purpose, parameters, return, auth, idempotency, data freshness, and relationships to sibling tools. No critical gaps are evident.

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 defaults and descriptions. The description adds value by explaining the practical significance of parameters: `buyAmount` defaults vary by resource type (100000 for ENERGY, 1000 for BANDWIDTH), `durationSec` must match the real order for comparable quotes, and `address` scopes context when supported. This context helps the agent set parameters appropriately beyond what the schema provides, though it is not exhaustive.

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 purpose: 'Quote the minimum unit price for a buy.' It specifies the return format, source API (GraphQL `market.estimateMinPrice`), and parameters, effectively distinguishing it from sibling tools like `tronsave_estimate_buy_resource` and `tronsave_list_order_books` by noting they pair together for different aspects of quoting.

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

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

The description provides explicit when-to-use guidance by recommending pairing with `tronsave_estimate_buy_resource` for full quotes and `tronsave_list_order_books` for depth. It also includes a freshness directive to re-fetch right before ordering and not reuse stale values, and notes that optional session forwarding mirrors `tronsave_list_order_books`. This covers both when to use and how to combine with alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint. Description adds that it requires a signature session and mcp-session-id, and notes that order state changes quickly. Adds useful behavioral context beyond annotations.

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

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

Description is brief and well-structured. Each sentence adds value: action, usage guidance, freshness warning, requirements. 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?

Given the tool's simplicity (1 parameter, no enums, output schema present), the description is fully complete. It covers purpose, timing, freshness, and prerequisites.

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 a detailed description for the only parameter (id). Description mentions the parameter but adds no new semantics beyond the schema. 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 uses specific verb 'Read' and resource 'order by id', and specifies order types (NORMAL, FAST, EXTEND). It clearly distinguishes from siblings like tronsave_update_order, tronsave_cancel_order which are mutations.

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

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

Explicitly tells when to use (source of truth before mutations) and warns against reusing stale state. Provides actionable guidance: re-read immediately before mutation.

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

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

Annotations already indicate readOnlyHint, openWorldHint, and idempotentHint. The description adds context by detailing the exact return object and the required format for subsequent login, which goes beyond annotations.

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

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

The description is concise with two sentences, front-loaded with the key action, and contains no unnecessary 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 and an output schema present, the description fully covers the tool's purpose, return value, and usage context, making it complete for an AI agent.

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

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

The tool has no parameters, so the description does not need to add parameter information. The schema coverage is 100% and the description complements it by explaining the purpose and usage.

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 purpose: 'Issue a wallet-signable timestamp message helper for signature login.' It specifies the return format and distinguishes itself from the login tool by describing the intended 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 says 'Optional helper only' and provides an alternative: 'clients may also sign their own timestamp payload directly.' It also explains how to use the tool in conjunction with tronsave_login.

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

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

Annotations already declare `readOnlyHint`, `openWorldHint`, `idempotentHint`. Description adds value by requiring a signature session and `mcp-session-id`, and states the return is the full `autoSettings` object. Reinforces read-only and idempotent nature without contradiction.

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

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

Three concise sentences: first states what it returns, second advises when to use it (with specific sibling names), third states requirements and properties. No unnecessary words; 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?

Given the tool has an output schema and no parameters, the description covers usage context, return object, and prerequisites. Could mention potential errors or limits but is sufficient for an AI agent to use 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 schema coverage is 100%. Description doesn't need to add parameter details. It mentions required authentication context (signature session, mcp-session-id) which is not in schema, adding value.

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 'Read the current user's auto-sell configuration (`autoSettings`)', clearly stating the verb and resource. It also mentions specific sibling tools (`tronsave_register_auto_sell` and `tronsave_update_auto_sell_setting`) to distinguish 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?

Explicitly advises to call this tool before modifying auto-sell settings to avoid unintended overwrites. Provides clear context on when to use, though no explicit when-not-to-use instructions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description reinforces this with 'Read-only and idempotent' and adds useful detail about return values potentially being null (info, internalAccount). This adds value beyond the annotations.

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

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

Three sentences: first states purpose and return format, second details potential null fields, third gives usage context. No wasted words, 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 no parameters and rich annotations, the description is complete. It covers return structure, nullability, prerequisites, and alternatives. Output schema is described inline, fulfilling the contextual needs.

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

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

There are no parameters (0 params, 100% schema coverage). Baseline is 4 per guidelines. Description does not need to add parameter semantics, and it appropriately omits them.

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 reads the current authenticated user's profile and linked internal account, specifying the return fields. It distinguishes from siblings like tronsave_get_user_auto_setting and tronsave_get_user_permissions, making the purpose unambiguous.

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

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

Explicitly mentions prerequisites: requires a signature session from tronsave_login and mcp-session-id. Also provides guidance on when to use alternative tools, giving clear context for tool selection.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint. The description adds the return format `{ permitOperations: string[] }` and confirms idempotence and read-only nature. No contradictions.

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

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

Two sentences: first states purpose and return, second gives usage guidance and prerequisites. Every sentence adds value, no 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?

With no parameters, rich annotations, and output schema implied, the description covers purpose, return format, usage context, and prerequisites. Complete for 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?

No parameters exist, so baseline is 4. Description adds no param info, which is appropriate since schema covers all (0 params).

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 specifies the verb 'Read' and the resource 'enabled permission operations (`autoSettings.permitOperations`) for the authenticated user', making the action and scope clear. It distinguishes from sibling tools that deal with orders, auto settings, etc.

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

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

Explicitly states when to use: 'before mutating auto-sell or auto-buy rules to confirm the action is allowed for the wallet'. Also mentions prerequisites: 'Requires a signature session and `mcp-session-id`.'

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?

Discloses key side effects: 'SPENDS internal TRX and creates an extension order; not idempotent.' This adds meaningful context beyond annotations (readOnlyHint=false, idempotentHint=false). No contradiction with annotations is present.

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

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

The description is a single dense paragraph with no wasted words. It is front-loaded with the main purpose, then covers prerequisites, side effects, usage instructions, and return value. 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?

Given the tool has 3 parameters (2 required), a nested array, an output schema, and annotations, the description fully covers session requirements, parameter sourcing, side effects, chaining order, and return format. No gaps remain for the agent.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining that `extendData` should be copied from `tronsave_internal_extend_delegates` output and that `resourceType` defaults to ENERGY when omitted. This enhances semantic understanding beyond the schema.

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

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

The description clearly states the action ('Submit an extension request'), the resource ('existing delegated resources on TronSave'), and the payment source ('paid from the internal account'). It distinguishes itself from sibling tools by explicitly positioning it as 'STEP 2 after tronsave_internal_extend_delegates'.

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

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

Provides explicit chaining guidance: 'Use as STEP 2 after tronsave_internal_extend_delegates — pass its extendData rows unchanged.' Also details session requirements (login via tronsave_login, include mcp-session-id) and clarifies that internal tools do not accept API keys in arguments. This leaves no ambiguity for 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?

Beyond annotations (readOnlyHint, idempotentHint), the description adds critical behavioral details: session requirements, session ID header inclusion, and freshness sensitivity. All consistent with annotations; no contradiction.

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

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

The description is slightly long but well-structured, front-loading the main purpose. Each sentence adds distinct value (purpose, flow, session requirements, read-only, freshness). Minor redundancy in session details could be tightened.

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 role in a multi-step flow, the description covers prerequisites, usage context, and freshness. Output schema exists so return values need not be detailed. Lacks error scenarios or edge cases but sufficient for selection.

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

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

Schema coverage is 100% with clear descriptions for all 5 parameters. The description adds no extra parameter-level meaning beyond what the schema provides, so 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 clearly states the tool returns extendable delegations and an extendData payload, with a specific verb ('Return') and resource. It distinguishes itself from the sibling 'tronsave_internal_create_extend_request' by positioning it as Step 1 in the extension 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?

Provides explicit guidance: use as Step 1 before 'tronsave_internal_create_extend_request', requires a logged-in session from 'tronsave_login', and notes it is read-only. Also includes freshness warning to run immediately before extending.

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?

While annotations already mark it readOnlyHint=true, the description adds critical behavioral context: internal tools bypass API key arguments and rely on session-based resolution; session types (signature vs. api-key) differ in key handling. It also discloses a 3-second freshness window, which is vital for correct agent invocation.

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 (4 sentences) and front-loaded with the core purpose, then session details, usage guidance, and freshness. Every sentence adds necessary context without redundancy.

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

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

Given the tool has a full output schema, annotation coverage, and 100% parameter schema coverage, the description provides all needed contextual completeness: purpose, session prerequisites, usage timing, and live data volatility. No gaps remain.

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 four parameters have full schema descriptions (100% coverage), so the description does not add extra parameter-level meaning. The description provides no additional semantics beyond what the schema already conveys, meeting the baseline for high coverage.

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

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

The description clearly states the tool returns TronSave market depth/price tiers for ENERGY or BANDWIDTH via the REST endpoint. It uses a specific verb ('return') and resource ('market depth/price tiers'), and distinguishes from siblings by noting it is a read-only preview for order creation/estimation.

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

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

Explicitly advises using this tool before `tronsave_internal_order_create` or `tronsave_internal_order_estimate` when live prices are needed. It also specifies the prerequisite of a logged-in session from `tronsave_login` and notes freshness, providing clear when-to-use and 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?

Discloses side effects: spends internal TRX balance and creates a live order. Confirms non-idempotency ('not idempotent — each call places a new order'), matching annotations. Adds caveat about stale quotes older than a few seconds. No contradiction with annotations.

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

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

The description is compact (5 sentences) and front-loaded with the main purpose. Every sentence adds essential information: action, prerequisites, authentication clarification, side effects, sibling differentiation, and pricing guidance. No 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?

Given the tool's complexity (7 parameters, nested options, 2 required), the description covers prerequisites, authentication, side effects, non-idempotency, alternative paths, pricing strategy guidance, and return value. With an output schema existing, the description is thorough.

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 covers each parameter with descriptions (100% coverage). The description adds critical guidance for unitPrice: derive from latest estimate and re-estimate immediately before submitting, which is not in the schema. This adds meaningful value beyond the schema.

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

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

The description clearly states the tool places a new buy order for ENERGY or BANDWIDTH on TronSave using internal account balance. It differentiates from the sibling tool tronsave_create_order by specifying this is the api-key/internal path.

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

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

Explicitly mentions prerequisite: a logged-in MCP session from tronsave_login. Clearly states when not to use this tool (for signature-session market path, use tronsave_create_order instead). Provides actionable guidance to derive unitPrice from latest tronsave_internal_order_estimate.

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?

Disclosures include read-only nature, session handling, and volatility note: 'FRESHNESS: order state changes within seconds — re-read immediately before acting.' Annotations (readOnlyHint, openWorldHint, idempotentHint) are consistent and supplemented.

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 purpose, then authentication, usage, and behavior. Each sentence adds value, though could be slightly more concise.

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 (1 param, read-only, output schema present), the description covers purpose, authentication, usage scenarios, and data freshness. It is fully adequate for agent understanding and 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 only parameter orderId is fully described in the schema (hex string, example source). The tool description does not add additional semantic meaning beyond what the schema provides, so baseline 3 applies.

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

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

The description clearly states 'Fetch full details for one internal-account order by order ID.' It specifies the verb 'fetch' and the resource 'internal-account order', differentiating from sibling tools like tronsave_get_order which target regular 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?

Explicitly states requirement for a logged-in MCP session from tronsave_login, explains authentication modes, and provides concrete use cases: monitoring fulfillment after tronsave_internal_order_create or checking status on a specific order id.

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

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

Adds significant behavioral context beyond annotations: freshness warning with 3-second update interval, session requirement, internal tool behavior (no API keys in arguments), and re-estimation advice. No contradiction with annotations.

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

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

Concise and well-structured: purpose stated first, then prerequisites, usage guidance, read-only declaration, and freshness warning. Each sentence adds value; 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?

Covers all necessary context: session requirement, internal tool behavior, usage scenario, freshness constraints, and linking to the next tool. Output schema exists, so return values need not be explained.

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

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

Schema description coverage is 100% and already documents each parameter thoroughly. The tool description does not add additional meaning to the input parameters beyond mentioning freshness of output fields (unitPrice/estimateTrx). 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?

Clearly states the tool estimates TRX cost and availability for a buy order before submission. Uses specific verb 'estimate' and resource 'TRX cost and availability'. Distinguishes from siblings by mentioning it feeds into 'tronsave_internal_order_create' and is for internal accounts.

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

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

Explicitly states when to use: 'Use when the user wants a quote or price check'. Tells what to do with the result: 'feed the result into tronsave_internal_order_create'. Also provides prerequisite instructions for session handling.

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

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

Annotations already indicate readOnlyHint, idempotentHint, openWorldHint. The description adds that the tool is paginated, returns newest first, and requires session authentication. No contradictions.

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-organized paragraph with purpose first, then authentication, usage, and pairing. Every sentence adds value; no 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?

Given the tool has 2 optional parameters, output schema exists, and rich annotations, the description covers authentication, use cases, pagination behavior, and complementary tools comprehensively.

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 each parameter described. The description adds context like 'newest first' and pagination behavior, but doesn't significantly extend beyond schema descriptions. Baseline 3 applies.

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

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

The description clearly states 'List paginated order history for the internal account linked to the API key, newest first.' It uses specific verbs and resource, and distinguishes from siblings like tronsave_internal_order_details and tronsave_list_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?

It explicitly says 'Requires a logged-in MCP session created by the tronsave_login tool' and gives the session header format. It states when to use ('when the user asks about past purchases, fulfillment, payouts, or delegates on their internal account') and suggests pairing with tronsave_internal_order_details for a single 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?

Description reinforces annotations (readOnlyHint, openWorldHint, idempotentHint) by stating 'Read-only; does NOT create orders or change on-chain state'. Adds context that it's GraphQL market data for discovery only and explains optional suggestData is for planning, not a live order. No contradictions with annotations.

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

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

Description is fairly long but well-structured: main purpose first, then optional parameters, then read-only note, then session behavior, and finally a clear note about the alternative REST endpoint. Each sentence adds value, though some redundancy (e.g., 'Read-only' repeated in multiple sentences). Could be slightly more concise but appropriate for complexity.

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

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

Given the tool has output schema (so return values need not be explained), all aspects are covered: purpose, required parameters, optional parameters with nested structure, read-only guarantee, auth behavior, and explicit guidance on when to use this vs. the REST endpoint. No gaps remain.

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

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

Schema descriptions already cover all parameters (100% coverage). Description adds valuable context: requester parameter explains when it's needed vs. session auth; suggestData emphasizes that partial objects are invalid and it's for hypothetical scoring; resourceType reinforces enum meaning. This goes beyond what schema provides, justifying a score above baseline 3.

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

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

Description clearly states 'List extendable delegate candidates for a receiver and resourceType'. It distinguishes from sibling tools (e.g., tronsave_internal_extend_delegates) by explicitly saying it is read-only and for discovery only, and provides the alternative REST endpoint for actual submission.

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

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

Explicitly states when to use (listing extendable delegates) and when not (does not create orders). Provides specific alternative: 'To actually submit an extension, call the authenticated REST POST /v2/get-extendable-delegates'. Also clarifies that it works without session and auth forwarding behavior.

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

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

Beyond annotations, it adds freshness info: buckets shift every ~3 seconds, advising re-read before acting. No contradictions with annotations.

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

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

Single paragraph that is well-structured, front-loaded with purpose, and packs essential information without redundancy.

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

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

Covers all needed aspects: purpose, parameters, synchronization, usage context, and links to alternatives. Output schema exists, so return details are not required.

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

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

Schema coverage is 100%, so baseline is 3. Description adds value by summarizing how parameters scope the query and mentioning the return structure, but does not add deep new 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 clearly states it reads market depth buckets for ENERGY or BANDWIDTH, and specifies the return format. It distinguishes itself from sibling tools by mentioning tronsave_estimate_buy_resource and tronsave_get_order.

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

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

Explicitly states when to use (before create/update decisions) and how to pair with other tools. Also notes no login required, read-only, and idempotent.

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

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

Annotations declare readOnlyHint, openWorldHint, and idempotentHint, and the description does not contradict these. It adds transparency about paging behavior, filter mapping, authentication requirements for `onlyMyOrder`, and return shape, enhancing understanding beyond annotations.

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

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

The description is highly concise, using a single paragraph with clear structure: action, return format, filter mapping, authentication note, and paging instructions. Every sentence adds value with no redundancy.

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

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

Given 5 parameters, an output schema, and many siblings, the description covers all essential aspects: paging, filtering, authentication, and cross-reference to `tronsave_get_order`. It is complete for an agent to select and 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?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the status mapping, authentication context for `isOnlyMyOrder`, and paging semantics beyond schema descriptions. This justifies a score above 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 explicitly states the tool queries the order list with paging and provides the return structure. It distinguishes itself from the sibling `tronsave_get_order` which retrieves a single full snapshot.

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 when to use paging, how filters like status map to GraphQL, and notes that `onlyMyOrder` requires signature login and session ID. It also advises using `tronsave_get_order` for a single full snapshot before mutating, providing clear when-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?

Annotations indicate readOnlyHint=false and idempotentHint=false, which align with the description's statement that the tool creates a new session. The description adds critical behavioral context: wallet signing must be client-side, private keys must never be sent, and the side effect of session creation. No contradictions.

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 informative and front-loaded with the essential purpose and return value. It explains modes and side effects efficiently, though slightly long. Every sentence is necessary, but minor trimming could improve conciseness.

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 (two modes, client-side signing, session creation), the description covers all needed information: authentication flow, return value structure, header usage, and security caveats. The output schema exists and is explained, making the description 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 schema covers both parameters (apiKey, signature) with descriptions. The description adds significant value: the exact format for signature ('signature_timestamp'), that apiKey is raw without prefix, and that exactly one of the two must be provided. This goes beyond the schema's basic descriptions.

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

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

The description clearly states the tool authenticates and creates a server session, specifying the return value and how to use the session ID. It is distinct from sibling tools, which are all other operations, making the purpose unambiguous.

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

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

The description explicitly details two modes (wallet signature and API key), explains how to format the signature, and mentions the optional helper tool tronsave_get_sign_message. It does not explicitly state when not to use the tool (e.g., if already authenticated), but provides strong usage guidance.

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

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

The description discloses side effects (persists automation settings affecting future behavior) and non-idempotence (calling twice may reset fields). It also states failure scenarios (invalid config, unauthorized session, backend policy). Annotations already indicate readOnlyHint=false and idempotentHint=false, but the description adds specific behavioral context without contradiction.

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

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

The description is concise and well-structured. It front-loads the primary purpose, then addresses side effects, usage guidelines, and failure conditions in a logical order. Every sentence adds value without unnecessary verbiage.

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 (three nested object parameters, 0% top-level schema coverage, and an output schema not detailed), the description adequately covers usage context and behavioral traits but omits parameter semantics and return value structure. It compensates somewhat by guiding correct usage but is incomplete regarding what the tool accepts and returns.

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 3 top-level parameters with 0% schema description coverage. The tool description does not provide any meaning or explanation for these parameters (poolSetting, addOnFeature, paymentConfig) beyond their names. This is a significant gap, as the description should compensate for the lack of schema descriptions but fails to do so.

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 creates the initial auto-sell configuration for the authenticated user. It distinguishes from siblings by explicitly mentioning it is for first-time setup only, contrasting with tronsave_update_auto_sell_setting for subsequent edits.

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

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

The description provides explicit when-to-use (first-time setup) and when-not-to-use (subsequent edits should use update tool). It also advises reading current state first with tronsave_get_user_auto_setting to avoid overwriting unknown fields. Additionally, it mentions prerequisites (signature session, mcp-session-id) and failure conditions.

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

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

Beyond annotations (destructiveHint, idempotentHint), the description discloses important behavioral traits: TTL of in-flight sessions, best-effort immediate cutoff, and idempotency confirmation, adding significant value.

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

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

The description is concise and well-structured, with each sentence adding clear value. Front-loaded with the primary action, followed by side effects, idempotency, requirements, and next steps.

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 empty schema, annotations, and existence of an output schema, the description is complete. It covers side effects, idempotency, requirements, and post-use action, leaving minimal gaps.

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 no parameters, so there is nothing to describe. The description adds context about required session and header, which is beyond the schema but not parameter-specific.

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 'Revoke the caller's current internal API key' with a specific verb and resource. It distinguishes itself from the sibling tool 'tronsave_generate_api_key' by mentioning it as a follow-up action.

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

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

Explicitly states prerequisites ('Requires a signature session and mcp-session-id'), provides context on the best-effort nature of the effect, and directs the user to call 'tronsave_generate_api_key' for continued access.

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

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

Annotations already flag destructiveHint=true, idempotentHint=false. The description elaborates significantly: 'Side effect: broadcasts a market/delegation transaction and may consume balances/resources; not idempotent — each call re-executes.' It also adds authorization nuance. No contradiction with annotations; description adds substantial context.

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

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

Four well-structured sentences, front-loaded with the key action and return value, followed by side effects and usage conditions. No wasted words; each 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?

Given the tool's complexity (3 params, nested objects, output schema exists), the description covers purpose, side effects, prerequisites, and usage order. It is complete for an agent to correctly invoke the tool.

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

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

Schema description coverage is 100%. The description adds value by contextualizing the signedTx parameter ('Must come from client-side signing; never fabricate') and noting the optional paymentAddress override. This goes beyond the schema, though the schema is already thorough.

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: 'Manually execute seller-side fulfillment of an existing order' with a specific resource ('order', 'signedTx'). It explicitly distinguishes from sibling tools by focusing on manual sell fulfillment, contrasting with other tools like 'tronsave_cancel_order' or 'tronsave_create_order'.

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

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

Provides clear guidance: 'Use only when explicit manual sell is intended; call tronsave_get_order first to verify order state before signing.' Also details required session/auth conditions ('Backend requires a signature session and mcp-session-id'), effectively telling the agent when and how 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.

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

Annotations already indicate mutation (readOnlyHint=false) and non-idempotence (idempotentHint=false). Description adds specifics: 'overwrites stored automation settings for the current user; not idempotent across different field sets' and lists failure modes, providing additional behavioral context beyond annotations.

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

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

Highly concise and well-structured: first sentence states purpose and return, then side effects, requirements, usage guidance, and failure conditions. Every sentence adds value and the 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?

Covers purpose, return type, side effects, prerequisites, usage context, alternative tools, and failure cases. Output schema exists, so return values are documented. Minor missing detail on how partial updates merge with existing settings, but satisfactory for a complex tool.

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

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

Schema description coverage is low at top level (0%), but nested schema fields have detailed descriptions. The tool description adds the key concept of 'partial fields' (incremental updates). Baseline 3 is appropriate as schema covers subfields and description adds partial update hint.

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 'Update the existing auto-sell configuration with partial fields' and explicitly distinguishes from sibling tools `tronsave_register_auto_sell` (first-time setup) and `tronsave_get_user_auto_setting` (read baseline).

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

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

Provides explicit guidance: 'Use for INCREMENTAL changes after registration; read the baseline via... to avoid accidental resets, and use... only for first-time setup.' Also specifies prerequisites (signature session, mcp-session-id) and failure conditions.

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?

Discloses side effects (overwrites live order parameters), non-idempotency (each call with different newPrice produces new state), and authentication nuances. Annotations already indicate readOnlyHint=false and idempotentHint=false, and the description adds valuable context that exceeds annotations without contradiction.

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

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

The description is a single, well-structured paragraph of about 80 words. It front-loads the primary action and return value, then covers side effects, prerequisites, alternatives, and failure conditions. Every sentence earns its place with no redundancy.

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

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

Given the tool's complexity (3 parameters, annotations present, output schema exists), the description covers all necessary aspects: purpose, prerequisites, side effects, authentication requirements, failure modes, and return value. It is complete for an agent to decide when and how to invoke the tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context beyond schema by explaining that orderId must correspond to an open/editable order and that newPrice is in SUN, but the schema already includes these details. However, the description connects parameters to failure conditions and usage, providing slight added value.

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 it updates an open order by orderId with partial fields (receiver, newPrice). It distinguishes from sibling tools like tronsave_cancel_order and tronsave_create_order by recommending this over cancel+recreate when only price/receiver should change. It also specifies the return value.

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

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

Explicitly states when to use (prefer over cancel+recreate), prerequisites (verify state with tronsave_get_order first), failure conditions (fails for already-fulfilled, already-cancelled, or non-editable orders), and authentication requirements (signature session, mcp-session-id, public gate but GraphQL rejects api-key-only).

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