TronSave MCP Server

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

Beyond annotations (destructiveHint, idempotentHint), the description reveals side effects: marks order non-matchable, refunds locked balance, idempotent behavior, and failure cases for fulfilled/unauthorized. 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?

Four sentences, front-loaded with the main action. Every sentence adds distinct value: purpose, side effect, idempotency, error cases, and usage guidance. 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 single-parameter cancellation tool with output schema, the description covers purpose, side effects, idempotency, error conditions, prerequisites, and sibling references. It is fully sufficient for correct invocation.

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

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

Schema covers 100% of the single parameter with a description. The tool description adds further context: 'Must be an active order owned/authorized by the current session; already-fulfilled or already-cancelled orders are expected to fail', which provides meaningful guidance 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 'Cancel an open order by `orderId`', uses a specific verb and resource, and distinguishes from sibling tools by referencing `tronsave_get_order` and `tronsave_update_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 explicit when-to-use (cancel open order), when-not-to-use (fulfilled orders, unauthorized callers), and alternatives (verify with `tronsave_get_order`, update with `tronsave_update_order`). Also mentions prerequisites (signature session, `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?

The description discloses side effect ('creates a live order matchable by the market') and preconditions (requires estimate, signature session). Annotations indicate write operation (readOnlyHint=false) and non-destructive; description aligns and adds context about market matching and staleness risks.

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 (6-7 sentences), front-loaded with purpose, and every sentence adds essential information. 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 complexity (8 params, nested objects, output schema exists), the description covers main action, inputs, payment methods, side effects, prerequisites, and freshness warning. It does not detail output or error handling, but output schema covers return values.

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 descriptions for all parameters, but the description adds value by grouping key inputs and explaining their relationships (e.g., unit price in SUN, derive from estimate), and the critical advice about avoiding stale estimates.

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

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

The description states 'Create a new buy order on the TronSave market' with specific verb and resource. It lists key inputs and mentions the order becomes matchable, but does not explicitly differentiate from siblings like tronsave_internal_order_create or tronsave_update_order.

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

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

The description provides explicit guidance: always derive price and amount from tronsave_estimate_buy_resource, re-quote immediately before submitting, and explains when to use onchain vs internal payment methods. It also mentions prerequisites like 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?

Adds beyond annotations: side effect stops future executions, rule cannot be restored, idempotent behavior (deleting non-existent returns success), and requirement for signature session and mcp-session-id. 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?

Three compact sentences, each adding essential information. Front-loaded with main action, 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 side effects, idempotency, prerequisite (list first), alternative actions, and requirements. Output schema exists (context signals), so no need to describe return values.

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 description for 'id' (MObjectId). The description further clarifies the parameter's role and context, adding full meaning.

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

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

The description clearly states the action 'permanently delete one auto-buy rule by id' and distinguishes from sibling tools like tronsave_get_user_auto_setting (list) and tronsave_update_auto_sell_setting (update/disabling).

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 instructs to list rules first via tronsave_get_user_auto_setting and advises preferring disable/update for reversibility, 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?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds important behavioral context: backend rate limits apply, and market data freshness (unitPrice/availability changes every ~3 seconds). This goes beyond annotations and informs the agent about temporal constraints and safety.

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 coherent paragraph that is well-organized: starts with the core purpose, then usage guidelines, then behavioral notes, then alternatives. Each sentence contributes meaning. Slightly verbose due to the FRESHNESS notice, but still concise for the information conveyed.

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, output schema present, rich annotations), the description is complete. It explains the return fields and their relationship to a subsequent tool, mentions freshness and rate limits, and differentiates from siblings. No missing information likely to confuse an 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?

Input schema has 100% description coverage for all 7 parameters. The description adds value by explaining how the output fields (unitPrice, paymentAmount, availability) directly map to inputs of tronsave_create_order (orderUnitPrice, paymentPaymentAmount). This contextual linkage enhances parameter understanding beyond the schema alone.

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: to quote price and availability for buying ENERGY or BANDWIDTH before placing an order. It specifies the verb (estimate/quote) and resource (price and availability for resource purchase), and distinguishes itself from sibling tools like tronsave_create_order (which uses these estimates) and tronsave_get_min_price (which only returns minimum 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?

The description provides explicit guidance: use before placing an order, never reuse a quote more than a few seconds old, and lists alternatives (tronsave_list_order_books for depth, tronsave_get_min_price for minimum price). It also notes that it is safe to call repeatedly and no session is required, making usage conditions clear.

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

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

The description discloses side effects (issues secret material, not idempotent, destructive), security warnings (never log raw keys, requires signature session and session-id), and policy checks. Annotations confirm idempotentHint=false and destructiveHint=true, 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 concise yet comprehensive: it states purpose, usage, side effects, warnings, and prerequisites in just a few sentences. Every sentence contributes value, with key information 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 zero parameters, rich output schema, and comprehensive annotations, the description completes the picture with behavioral details, security implications, and integration with sibling tools. 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?

With zero parameters, schema coverage is 100% and no additional parameter semantics are needed. Baseline score of 4 is appropriate as the description adds no parameter details, but none are required.

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

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

The description clearly states the tool generates a new internal API key credential, using the verb 'Generate' and specific resource. It distinguishes from siblings like 'revoke_api_key' and 'login' by explicitly mentioning the key's use with 'tronsave_login'.

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: store the key securely and pass it to 'tronsave_login' for internal access. It also advises key rotation behavior. While it lacks explicit when-not-to-use, the context covers primary use cases and 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=true, openWorldHint=true, and idempotentHint=true. The description adds value by detailing authentication requirements (session dependency, API key handling), constraints (TRX only, minimum 10 TRX), and clarifying it's a read-only operation. While it doesn't mention error responses or rate limits, it provides substantial 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?

The description is well-structured with four sentences, each serving a distinct purpose: purpose, session requirement, auth clarification, trigger conditions, and constraints. It is front-loaded with the main action. Minor redundancy (e.g., mentioning 'TRX only' twice) could be trimmed, but overall efficient.

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

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

With an output schema present (not detailed), the description covers essential context: purpose, session dependency, authentication mechanism, constraints, and trigger conditions. It omits details like whether the address is user-specific or if multiple calls return the same address (idempotentHint covers this). Overall, it is adequately complete for a read-only 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% for the single parameter (amountTrx). The description enhances understanding by stating 'minimum deposit amount is 10 TRX' (matching schema minimum) and reinforcing 'TRX only.' It also introduces a non-schema parameter (mcp-session-id) in the session context, adding meaning beyond the input 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 starts with a specific verb ('Fetches') and resource ('specific deposit address for the TronSave internal account'), clearly stating the tool's function. It distinguishes itself from siblings by focusing on deposit address retrieval, with no ambiguity.

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

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

The description explicitly states 'Trigger this tool if the user asks for a deposit address or needs to top up their TronSave TRX balance.' It also provides prerequisites (requires a logged-in session from tronsave_login) and instructions for including the session ID, making usage very clear.

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

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

The description discloses session requirement, internal API key handling (signature vs api-key sessions), and balance freshness. While annotations already mark readOnlyHint and idempotentHint, the description adds valuable context beyond these annotations, such as requiring a login session and explaining session types. 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 fairly concise and front-loaded with the main purpose. Each sentence contributes meaningful information (fields, prerequisites, behavior, freshness). It is slightly lengthy but well-structured with clear sections, earning a 4.

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 that there is an output schema (not detailed here), the description does not need to explain return values. It covers session dependency, authentication, and data freshness. It misses error conditions or handling of invalid sessions, but for a read-only tool with no parameters, it is largely 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 has zero parameters, so the description does not need to add parameter details. According to guidelines, 0 parameters yields a baseline score of 4. The description implies no arguments are needed, which is consistent.

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

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

The description states a specific verb ('Retrieve') and resource ('TronSave internal account profile'), listing exact fields (represent address, deposit address, balance in SUN). It clearly distinguishes from sibling tools that deal with orders, keys, etc., 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 explains when to use (user needs linked address/deposit address/internal balance), prerequisites (logged-in session from tronsave_login), and how to include the session ID. It also notes what it is not (on-chain wallet). However, it does not explicitly exclude alternatives or state when not to use this tool, missing a clear contrast with sibling 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint. Description adds no-login requirement, optional auth forwarding, and crucial freshness detail (live market data changes every 3 seconds). 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?

Concise 5-sentence description with front-loaded purpose. Every sentence adds distinct value: purpose, return type, parameters, auth, freshness, related tools. 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?

Covers core functionality, return structure, and critical freshness guidance. Missing details about error conditions or exact expected usage in complex scenarios, but sufficient for a simple quote tool given annotations and schema.

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

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

Schema coverage is 100% with good descriptions. The description adds value by contextualizing parameters (e.g., same units as order book, duration must match real order, optional address) and explaining defaults.

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 quotes the minimum unit price for a buy, specifies return format ({ minPrice }), source (GraphQL), and distinguishes from sibling tools by mentioning tronsave_estimate_buy_resource and tronsave_list_order_books.

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 when to use (before placing an order), freshness guidance (re-fetch every ~3 seconds), and related tools. Does not explicitly state when not to use, but context is generally clear.

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

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

Annotations declare readOnlyHint, idempotentHint, openWorldHint. Description adds that state changes within seconds and requires signature session and mcp-session-id. 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?

Single paragraph with clear front-loading of purpose, followed by usage guidance and freshness warning. Every sentence adds value 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?

With readOnly and idempotent annotations, output schema present (mentioned), and description explaining return snapshot, all essential context is covered.

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 3. Description mentions 'by id' and the schema fully describes the parameter, adding no extra syntactic or semantic detail beyond what schema provides.

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

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

Clearly states 'Read one order by id and return its full snapshot for NORMAL, FAST, or EXTEND order types.' Specifies verb, resource, scope, and distinguishes from sibling mutation tools.

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

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

Explicitly advises using as source of truth before tronsave_update_order, tronsave_sell_order_manual, or tronsave_cancel_order. Warns about freshness and to re-read immediately before mutations.

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. Description adds specific workflow details: returns {message, timestamp}, requires exact signing and submission format, and clarifies it's a helper with no side effects. 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 efficiently convey purpose, return format, optional nature, and alternative approach. No wasted words, front-loaded with key information.

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

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

Given zero parameters, existing output schema, and rich annotations, the description covers all necessary context: what it returns, how to use it with tronsave_login, and that it's optional. Complete 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?

Input schema has zero parameters, so schema coverage is 100%. Baseline per instructions is 4. Description adds no parameter info as 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?

Description explicitly states it issues a wallet-signable timestamp message for signature login, with the exact return structure. It distinguishes itself from sibling tools like tronsave_login by explaining it's a helper for signature mode.

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

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

Clearly states it's an optional helper and that clients may also sign their own timestamp payload directly as an alternative. Specifies the required format for tronsave_login, providing both 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true. The description reinforces these ('Read-only and idempotent') and adds useful context about the risk of overwriting fields if not called beforehand. 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?

Three sentences with no filler: first sentence states purpose, second explains usage context, third lists prerequisites and a safety property. Efficient and well-organized.

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 zero parameters, rich annotations, and an output schema, the description covers everything needed: action, resource, usage scenario, prerequisites, and behavioral traits. No 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 zero parameters (100% coverage implicitly). The description adds no param details but does mention non-schema requirements (signature session, mcp-session-id). Baseline 4 for zero params 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 ('Read') and the resource ('current user's auto-sell configuration'). It references the field name `autoSettings` and explicitly calls out sibling tools (`tronsave_register_auto_sell`, `tronsave_update_auto_sell_setting`) to distinguish usage.

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 this tool (before register/update to avoid overwriting fields) and prerequisites (signature session and mcp-session-id). It does not explicitly state when not to use it or list alternatives, but the guidance 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?

Beyond annotations (readOnlyHint, idempotentHint), the description reveals that 'info' may be null, 'internalAccount' is null when not provisioned, and confirms read-only and idempotent behavior. No contradiction with annotations.

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

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

Two sentences with a note, efficiently conveying purpose, prerequisites, return structure, and alternatives. No wasted words, front-loaded with core function.

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 input requirements, output shape with null conditions, and usage context (when to use alternatives). Despite the tool being simple with no params, the description is fully informative.

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 description adds no parameter-level detail, which is appropriate. Baseline for 0 params is 4, and no additional value is needed.

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

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

The description clearly states 'Read the current authenticated user's profile and linked TronSave internal account' with specific verb and resource. It differentiates from sibling tools by naming tronsave_get_user_auto_setting and tronsave_get_user_permissions for alternative use cases.

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 specifies prerequisites ('Requires a signature session from tronsave_login and mcp-session-id') and provides alternatives ('Use tronsave_get_user_auto_setting for auto-sell config or tronsave_get_user_permissions for permission flags when full profile is unnecessary').

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, and idempotentHint. The description confirms these and adds context about prerequisites and return structure, but adds minimally 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?

Two efficient sentences with no wasted words, front-loaded with the verb 'Read' and key details.

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

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

For a tool with no parameters and annotations covering behavior, the description provides all necessary context: purpose, usage timing, prerequisites, and return format. Output schema exists but description already addresses 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?

No parameters exist (schema coverage 100%), so baseline 4. Description adds value by explaining return type and usage context, compensating for lack of parameters.

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

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

The description clearly states it reads enabled permission operations for the authenticated user, specifies the return format `{ permitOperations: string[] }`, and distinguishes from sibling tools that perform 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 advises using this tool before mutating auto-sell or auto-buy rules to confirm allowed actions, and mentions required 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?

Description adds significant behavioral context beyond annotations: 'Side effect: SPENDS internal TRX and creates an extension order; not idempotent.' Annotations only give hints (idempotentHint=false, readOnlyHint=false), but description explains concrete effects and non-idempotence.

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 compact and front-loaded: first sentence states purpose, second covers authentication, then side effects and usage step. Every sentence adds value; 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?

Covers all necessary aspects: purpose, step usage, authentication, side effects, parameter origin, and return format (orderId). Complete for a 3-param tool with nested objects and output schema mentioned.

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

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

Schema coverage is 100%, and description adds meaning: clarifies that extendData rows must come from tronsave_internal_extend_delegates unchanged, and receiver is a TRON base58 address. Provides usage guidance beyond schema 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?

Description clearly states the action: 'Submit an extension request for existing delegated resources on TronSave, paid from the internal account.' It distinguishes from sibling tools by positioning 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?

Explicitly provides usage context: 'Use as STEP 2 after tronsave_internal_extend_delegates — pass its extendData rows unchanged.' Also details authentication requirements (logged-in session, mcp-session-id) and explains internal tool behavior (no API keys via arguments).

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, idempotentHint, openWorldHint. The description adds behavioral context: 'Read-only; does not submit anything' and freshness warning ('pricing/availability change within seconds — run immediately before extending'). 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 moderately concise (approx. 120 words) and front-loaded with purpose. Every sentence adds value, including prerequisites and freshness note. Could be slightly shorter but efficient.

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

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

Given 5 parameters (2 required) and output schema existence, the description covers purpose, prerequisites, usage as step 1, and freshness. Does not explain output schema but that's handled by the schema itself. Minor omission: no error handling notes, but sufficient for a read-only list 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?

Input schema covers 100% of parameters with descriptions. The description does not add extra parameter semantics beyond the schema, and baseline for high coverage is 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?

The description clearly states the tool returns extendable delegations and an extendData payload. It distinguishes itself from sibling tools like tronsave_list_extendable_delegates and notes its role as STEP 1 before tronsave_internal_create_extend_request.

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 when to use this tool (before tronsave_internal_create_extend_request to extend delegation time) and provides prerequisites (logged-in MCP session via tronsave_login, session ID handling). It lacks explicit 'when not to use' but the context is clear.

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

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

Beyond annotations (readOnlyHint, idempotentHint, openWorldHint), the description adds key behavioral info: the live market depth changes every ~3 seconds (one TRON block), recommends re-reading before orders, and clarifies authentication mechanics (no API keys in arguments, session ID required). No contradictions with annotations.

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

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

The description is concise (3-4 sentences) with the primary purpose front-loaded. Each sentence adds essential context (purpose, auth, usage, freshness) without redundancy or extraneous 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?

Given the tool's complexity (4 optional params, output schema present, rich annotations), the description covers purpose, authentication, usage guidance, and data freshness. The output schema handles return value documentation, so no gap remains.

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?

Input schema covers all 4 parameters with full descriptions (100% coverage). The description does not elaborate on parameter usage beyond mentioning resource types (ENERGY/BANDWIDTH), so it adds minimal value 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?

The description clearly states the tool returns 'current TronSave market depth/price tiers for ENERGY or BANDWIDTH', specifying the exact resource and action. It distinguishes itself from siblings by noting its use before order creation/estimation and by being explicitly internal.

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 advises to use this tool before `tronsave_internal_order_create` or `tronsave_internal_order_estimate` for live prices, and details authentication prerequisites (logged-in session via `tronsave_login` with session ID). It also covers session types and freshness considerations.

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 non-idempotent and non-read-only. The description adds crucial behavioral details: 'SPENDS internal TRX balance and creates a live order; not idempotent — each call places a new order.' It also warns about stale quotes reverting and explains the session key resolution mechanism, providing rich context beyond the annotations.

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

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

The description is well-structured: purpose first, then prerequisites, then differentiation, then critical usage guidance, then return value. Each sentence is informative and necessary, avoiding tautology or filler. It is concise given the tool's 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's complexity (7 params, nested objects, authentication requirements, state effects), the description addresses all key aspects: prerequisites, side effects, non-idempotence, sibling tool, and output format. No gaps are apparent.

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 guiding how to derive unitPrice from the estimate tool and emphasizing that internal tools never accept API keys via arguments. This extra context helps correct understanding beyond the schema 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 explicitly states the action ('Place a new buy order'), the resource type ('ENERGY or BANDWIDTH'), and the context ('paid from the internal account balance'). It also distinguishes itself from the sibling tool 'tronsave_create_order', clearly indicating 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?

The description provides explicit prerequisites (requires logged-in MCP session via tronsave_login, include mcp-session-id), differentiates from the sibling tool, and gives critical advice to derive unitPrice from the latest estimate and re-estimate immediately before submitting. It also explains the two session types (signature and api-key) and when to use each.

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 beyond annotations: describes auth mechanisms (signature vs api-key sessions) and includes FRESHNESS warning about data staleness. No contradictions with readOnlyHint and idempotentHint.

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?

Well-structured with front-loaded purpose, but includes necessary details; slightly verbose but each sentence adds value.

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

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

Fully covers purpose, auth, usage, and freshness for a single-parameter tool with output schema present. No 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?

Schema coverage is 100% and schema already describes the parameter. Description adds value by giving example source (value from order create response), enhancing understanding.

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?

Describes fetching full details for one internal-account order by order ID, clearly specifying the verb, resource, and scope. Distinguishes from sibling tools like tronsave_get_order and tronsave_internal_order_history.

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 prerequisite of a logged-in MCP session from tronsave_login and explains when to use (after order creation or for order status). Lacks explicit exclusions but context is clear.

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

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

Annotations mark the tool as read-only, and the description reinforces this by stating 'Read-only'. It adds valuable behavioral context: unitPrice/estimateTrx are live and change every 3 seconds. It also explains the internal session and API key handling, which annotations do not cover.

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 paragraph with clear, front-loaded purpose. Each sentence adds value: purpose, session requirement, usage note, read-only flag, and freshness warning. No superfluous content.

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

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

Given the tool's simplicity and rich annotations/schema (100% coverage, output schema present), the description covers all necessary aspects: purpose, usage context, session handling, and data freshness. No missing information for an estimate 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% – all 7 parameters have descriptions in the input schema. The description does not add significant extra meaning beyond what the schema provides, so baseline 3 is appropriate. Some defaults are mentioned (MEDIUM, 259200 seconds) but also appear in 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 'Estimate the TRX cost and availability for a buy order before submitting it'. This is a specific verb-resource pair and distinguishes from siblings like `tronsave_internal_order_create` which creates the order after 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?

The description explicitly says 'Use when the user wants a quote or price check; feed the result into `tronsave_internal_order_create`.' It also explains the prerequisite of a logged-in session from `tronsave_login`, providing clear when-to-use and next-step guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint. Description adds that it is 'Read-only', requires a session, and describes session types. 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?

Concise yet informative. Front-loaded with core purpose, then session requirement, usage context, and sibling reference. Could be slightly more streamlined but no unnecessary 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?

Fully covers what the tool does, prerequisites, parameters, behavioral traits, and relationship to siblings. Output schema exists, so return values are not needed in description.

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 `page` and `pageSize` including defaults and ranges. Description adds no additional parameter semantics 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?

Clear verb 'List', resource 'paginated order history', specific scope 'internal account linked to the API key', and ordering 'newest first'. Distinguishes from siblings like `tronsave_internal_order_details` for a single 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 ('when the user asks about past purchases, fulfillment, payouts, or delegates') and mentions prerequisite (logged-in MCP session via `tronsave_login`). Does not explicitly state when not to use, but implies 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 declare readOnlyHint, openWorldHint, and idempotentHint. The description adds that the tool does NOT create orders or change on-chain state, works without mcp-session-id, and that it is GraphQL market data. This enriches understanding beyond 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 concise, front-loaded with the main verb and resource, and every sentence serves a purpose. It includes necessary caveats and usage notes without excessive length.

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

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

Given the presence of an output schema, the description covers the tool's purpose, required parameters, optional suggestData, session behavior, and distinction from the actual extension endpoint. It is complete for a list/discovery 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%, so baseline is 3. The description adds value by explaining suggestData as a scenario for extend-and-buy planning and warns that partial objects are invalid. This contextualizes the parameters slightly beyond the schema definitions.

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 lists extendable delegate candidates for a receiver and resourceType. It distinguishes itself from the actual extension endpoint (POST /v2/get-extendable-delegates) and implies it is for discovery only, which differentiates it from sibling tools like 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?

The description explicitly notes it is read-only and for discovery, and instructs to use the authenticated REST endpoint for actual extension. It also mentions it works without a session and that auth can be forwarded when present, providing clear 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?

Beyond annotations (readOnlyHint, openWorldHint, idempotentHint), description adds important freshness detail: buckets shift every ~3 seconds and should be re-read before acting. This provides valuable behavioral context.

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

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

Four sentences, each serving a distinct purpose: purpose, optional parameters, no-login/idempotent note, freshness warning, and usage pairing. Efficient 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 the presence of an output schema (not shown but existing), the description covers purpose, usage context, freshness, and alternative tools without needing to explain return values. Complete for decision-making.

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 descriptions for all parameters. The description summarizes optional scoping (address, minDelegateAmount, durationSec) but adds no new semantic information beyond the schema's own parameter 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 reads market depth buckets for ENERGY or BANDWIDTH and returns price buckets with min, max, value. It distinguishes itself from siblings like tronsave_get_order (single order) and tronsave_estimate_buy_resource (quote 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 to estimate market ranges before create/update decisions, and pairs with alternatives tronsave_estimate_buy_resource and tronsave_get_order. Also notes no login required and idempotent/read-only nature.

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 behavioral context: status mapping to GraphQL isFulfilled, authentication needs for onlyMyOrder, and paging behavior, providing 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?

The description is a single, dense paragraph that efficiently covers return type, status mapping, auth, paging, and cross-tool guidance. It is front-loaded and to the point, though slightly more structure (e.g., bullet points) could improve readability.

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 complexity (5 parameters, paging, auth, output structure), the description is complete: it covers return shape, all filter options, paging behavior, authentication requirements, and cross-reference to tronsave_get_order for mutation context. No 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%, so baseline is 3. The description reinforces parameter meanings already in the schema (e.g., status mapping, onlyMyOrder requirement) but does not add new semantic information. The note about tronsave_get_order is 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 the tool queries order lists with paging and specifies the return structure. It distinguishes itself from sibling tools by mentioning tronsave_get_order for full snapshots before mutation, making its purpose unmistakable.

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

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

The description provides clear guidance on when to use this tool (listing orders with paging) and when to use tronsave_get_order (for a full snapshot before mutation). It explains status filtering and the authentication requirement for onlyMyOrder, though it lacks explicit 'when not to use' statements.

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 (creates a new session), conditional behavior (walletAddress only for signature mode), and security warnings (client-side signing). This adds value beyond annotations, which already indicate mutation and non-idempotency.

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

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

The description is well-structured with clear sections for modes and side effects, and it is front-loaded with the purpose. A few extra details could be streamlined, but overall it is concise and each sentence serves a purpose.

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

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

Given two parameters, an output schema hinted in the description, and no nested objects, the description comprehensively covers both authentication modes, return values, prerequisites, and security. It leaves no significant gaps for a login 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 description adds critical meaning beyond the schema: explains the signature format (signature_timestamp), mentions the helper tool, clarifies the exclusivity of parameters, and specifies the apiKey raw format. With 100% schema coverage, the description still provides substantial additional guidance.

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 with TronSave and creates a server session. It uses specific verbs and resources, and there is no other login tool among siblings, so it is well-distinguished.

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 two modes (wallet signature and API key) and guides when to use each, including referencing a helper tool. It lacks explicit when-not-to-use but provides clear context for correct usage.

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=false, destructiveHint=false, idempotentHint=false. Description adds context: says it persists settings, is not idempotent (calling twice may reset fields), requires signature session and mcp-session-id, and lists failure modes. This adds moderate value 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 multiple sentences but every sentence adds value: purpose, side effects, idempotency caution, prerequisites, usage context, and failure conditions. Could be slightly more compact, but 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 complexity (3 nested parameters, no param descriptions in description, but schema covers them), the description covers purpose, side effects, prerequisites, when to use, and failure modes. It mentions return value type. Missing parameter clarifications, but schema descriptions partially compensate. Overall fairly complete.

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

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

Schema description coverage is 0%, meaning the description does not explain parameters. The description adds no meaning beyond the input schema; it does not mention any parameter names or describe their purpose. Schema itself has descriptions for nested fields, but the tool description should compensate for low coverage, which it fails to do.

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 the tool creates the initial auto-sell configuration for the authenticated user, uses specific verb 'Create' and resource 'auto-sell configuration'. It explicitly distinguishes from sibling tools by naming tronsave_update_auto_sell_setting and tronsave_get_user_auto_setting.

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?

Description explicitly states 'Use for FIRST-TIME setup only' and tells when not to use it: for subsequent edits use tronsave_update_auto_sell_setting and always read current state first with tronsave_get_user_auto_setting. Provides clear context and 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?

The description elaborates on side effects (future requests rejected, possible delay due to cached sessions), idempotence (already hinted by annotation but explained), and that it is destructive (consistent with annotation). This adds value 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 (a few sentences) and front-loaded with the main action. Every sentence adds value 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 zero parameters, annotations present, and an output schema (not shown but exists), the description covers side effects, idempotence, and next steps comprehensively for a revocation tool.

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

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

The input schema has no parameters (0 params, 100% coverage), so the description's job is minimal. It does add context by mentioning required session details, which is helpful.

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 ('Revoke the caller's current internal API key') and distinguishes it from siblings like `tronsave_generate_api_key`. The verb 'revoke' and resource 'API key' are specific 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 specifies when to use (to revoke current key) and provides explicit guidance on next steps ('Call tronsave_generate_api_key afterwards'). It also notes 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?

Beyond annotations (destructiveHint=true, readOnlyHint=false, idempotentHint=false), the description discloses side effects: 'broadcasts a market/delegation transaction and may consume balances/resources; not idempotent — each call re-executes'. Also states return value: 'Returns the updated order payload after sell.'

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 focused paragraph, front-loaded with core action and return value. Follows with side effects, prerequisites, and usage caveats. No wasted words; every sentence adds necessary context.

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 complex tool (3 params, nested object, output schema), the description covers side effects, idempotency, authentication requirements, and when to call predecessor tools. Given annotations and output schema, nothing critical is missing.

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

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

Schema coverage is 100%, baseline 3. Description adds value by qualifying orderId as 'eligible for seller-side manual execution' and warning that signedTx 'Must come from client-side signing; never fabricate'. PaymentAddress is clarified as 'Optional payout/payment address override when settlement flow requires it.'

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 the action: 'Manually execute seller-side fulfillment of an existing order with a wallet signedTx'. It distinguishes from siblings like cancel/create/update orders by specifying 'manual sell' and directing use only when explicit manual sell is intended.

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 only when explicit manual sell is intended') and provides prerequisite steps ('call tronsave_get_order first to verify order state before signing'). Also details backend requirements (signature session, mcp-session-id) and limitations (GraphQL rejects api-key-only sessions).

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 write (readOnlyHint=false), non-idempotent, non-destructive. The description adds: 'Side effect: overwrites stored automation settings for the current user; not idempotent across different field sets.' and clarifies that it returns the updated payload. This goes beyond annotations with specific behavioral context.

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

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

The description is extremely concise with three focused sentences. First sentence states action and return, second warns of side effect and non-idempotency, third provides usage guidance and failure conditions. No redundant 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 complex schema with nested objects and an output schema (not shown), the description covers all necessary contextual aspects: purpose, return, side effect, prerequisites, failure modes, and explicit guidance on when to use this tool versus siblings. It provides complete guidance for an agent to use the tool correctly.

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

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

Schema description coverage is 0%, but the input schema itself has detailed descriptions for every nested field. The tool description only adds 'partial fields', which hints at optionality. This is useful but minimal; the description does not elaborate on parameter constraints or relationships beyond what the schema provides.

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

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

The description clearly states the verb 'Update', the resource 'existing auto-sell configuration', and the nature 'partial fields'. It explicitly distinguishes from sibling tools by specifying when to use tronsave_get_user_auto_setting and tronsave_register_auto_sell.

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

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

The description explicitly says 'Use for INCREMENTAL changes after registration' and warns against using for first-time setup (use tronsave_register_auto_sell). It also lists prerequisites (signature session, mcp-session-id) and failure conditions (invalid field combinations, unauthorized sessions, policy constraints).

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 beyond annotations by detailing side effects ('overwrites live order parameters; not idempotent — each call with a different newPrice produces a new state') and conditions for failure. The annotations (idempotentHint=false, destructiveHint=false) are consistent and elaborated upon.

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 (3-4 sentences), front-loads the primary action, and each sentence adds unique value: purpose, parameters, side effects, usage guidelines, and prerequisites.

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 presence of an output schema and annotations, the description provides comprehensive context: success behavior, failure conditions, authentication requirements, and preferred use case. No gaps remain for agent guidance.

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 minor context (e.g., order must be open, parameters are optional replacements) but mostly restates schema descriptions without significant new semantic information.

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 ('Update'), the resource ('open order'), the identifier ('orderId'), and the partial fields ('receiver', 'newPrice'). It distinguishes the tool from siblings by noting the preference over cancel+recreate.

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 guidelines are provided: when to use ('prefer this over cancel+recreate when only price/receiver should change'), prerequisites ('requires a signature session and mcp-session-id'), and when to avoid ('fails for already-fulfilled, already-cancelled, or non-editable orders'). Also suggests verifying state with 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.