TronSave MCP Server

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

Annotations already indicate destructive and idempotent hints. The description adds critical behavioral context: marks order non-matchable, refunds locked balance, idempotent behavior on already-cancelled orders, failure conditions, and auth requirements (signature session, mcp-session-id). 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 compact and front-loaded with the primary action. Every sentence adds value—purpose, side effects, idempotency, failure cases, auth, and related tool guidance. 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?

Given the tool's simplicity (single parameter, clear operation), the description covers all important aspects: action, side effects, idempotency, failure modes, auth, and cross-references to sibling tools for state checking and updates. It is fully adequate.

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 parameter description. The description's first sentence mentions orderId but does not add significant new meaning beyond the schema. Baseline 3 is appropriate as the schema handles the parameter semantics well.

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 verb 'Cancel' and the resource 'an open order by orderId'. It distinguishes from sibling tool tronsave_update_order by noting when to prefer that alternative. This clearly identifies the tool's specific function.

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 on when to use (cancel open orders) and when not to (fails for fulfilled orders or unauthorized callers). It also suggests verifying state with tronsave_get_order first and recommends tronsave_update_order for price/receiver changes, offering clear 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 readOnlyHint=false, which matches the mutation behavior. The description adds important behavioral context: side effects (creates a live matchable order), required session, and the risk of stale estimates causing reverts or wrong prices. 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 well-structured and front-loaded: it starts with the main purpose, then lists key inputs, explains side effects, and provides usage guidance. While it is somewhat lengthy, each sentence adds value. It could be slightly more concise but is still 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 complexity (8 parameters, nested objects, multiple payment methods), the description covers preconditions, side effects, and critical constraints. It references the estimate tool for proper parameter derivation. The existence of an output schema reduces the need to explain return values. Overall, it is 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 coverage is 100%, so baseline is 3. The description adds significant value by explaining that orderUnitPrice is in SUN (not TRX), describing payment method semantics, and emphasizing the relationship between parameters and the estimate tool. This goes 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's purpose: 'Create a new buy order on the TronSave market.' It specifies the verb (create), resource (buy order), and key inputs. This distinguishes it from sibling tools like tronsave_cancel_order or tronsave_estimate_buy_resource.

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 on when to use each payment method, the need for a signature session and mcp-session-id, and the critical requirement to derive prices from tronsave_estimate_buy_resource. It also warns about freshness. However, it does not explicitly state when not 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?

Beyond annotations (destructiveHint, idempotentHint), description explains side effects (stops future executions, irreversible) and idempotency (success on non-existent id). Also notes authentication requirement.

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 plus key details, front-loaded with primary action. 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?

Given a simple single-parameter tool with output schema and clear annotations, the description covers purpose, side effects, idempotency, prerequisites, and usage guidance completely.

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 description for 'id', and the tool description echoes the same info without adding new meaning beyond reinforcing the id type.

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 'Delete Auto Buy Setting' with specific verb and resource, and distinguishes from sibling tools like tronsave_get_user_auto_setting and tronsave_cancel_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 (after listing current rules via tronsave_get_user_auto_setting) and when to prefer alternatives (disabling/updating for reversibility). Also mentions required signature session.

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 beyond: 'no session is required', 'backend rate limits apply', and data freshness of approximately 3 seconds. 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?

At about 100 words, it is concise. All sentences add value: purpose, freshness warning, sibling differentiation. Slight redundancy with annotations is acceptable. Front-loaded with main action.

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 7 parameters (no required), many siblings, and an output schema, the description covers purpose, usage context, data freshness, rate limits, and parameter-output linkages. No gaps remain for an agent to understand correct invocation.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning by linking output fields to `tronsave_create_order` inputs and providing default values for `durationSec`, `resourceType`, and `buyResourceAmount`. This contextualizes parameters 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 verb 'Quote', the resource 'ENERGY or BANDWIDTH', and the receiver address. It distinguishes the tool from siblings by naming `tronsave_list_order_books` and `tronsave_get_min_price` as alternatives for different needs.

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 usage guidance: use before `tronsave_create_order`, do not reuse estimates older than a few seconds, re-run immediately before ordering. Alternatives are named for depth and minimum price queries.

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 context beyond annotations: 'Side effect: issues secret material; not idempotent — each call mints a fresh key', rotation behavior, security warnings (never log raw keys). No contradiction with annotations (destructiveHint=true, idempotentHint=false).

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 of 4-5 sentences, front-loaded with purpose, then provides usage, behavioral notes, and security warnings. 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?

Given the complexity (generating secrets, side effects, security), the description covers output ('Returns `data` containing the issued key'), prerequisites, safety warnings, and rotation advice. Output schema exists and description complements it.

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

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

No parameters exist, so schema coverage is 100% by default. Baseline for 0 params is 4; the description adds no parameter-level info but the tool has none, so no deduction.

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 'Generate a new internal API key credential for the current user', specifying the verb 'generate' and resource 'API key credential'. It distinguishes from siblings like `tronsave_revoke_api_key` (revoke) and `tronsave_login` (login) by focusing on key generation.

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: store key securely, pass to `tronsave_login` for access, treat old keys as rotated. Also mentions prerequisites (signature session, `mcp-session-id`) and implicitly when to use (when a key is needed) versus not (e.g., revocation).

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. The description adds crucial context: session requirements, auth mode resolution, and constraints (TRX only, min 10 TRX, read-only). 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?

Description is front-loaded with purpose, then session requirements, then constraints. Slightly verbose with full auth mode explanation, but all information is relevant 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?

For a simple single-parameter tool with output schema (implied), the description covers purpose, preconditions, constraints, and safety profile completely. No missing critical context given existing 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 description coverage is 100% and the parameter (amountTrx) is well-documented with type, minimum, and description. The tool description repeats the min deposit (10 TRX) but adds no new semantic nuance 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 'Fetches the specific deposit address for the TronSave internal account,' with a specific verb and resource. It distinguishes itself from sibling tools (none others fetch deposit addresses) and adds constraints (TRX only, min 10 TRX).

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 the prerequisite of a logged-in session via tronsave_login, provides the required session header format, and explains when to trigger ('if the user asks for a deposit address or needs to top up'). Also clarifies auth modes.

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 that it is read-only, does not submit orders or change chain state, and provides freshness information about balance reflecting live state. 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 paragraph but well-structured: main purpose first, then session requirement, then additional notes. Each sentence adds value, though slightly verbose in the session explanation.

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 and an existing output schema, the description covers all necessary context: what is retrieved, how to use it (session), read-only nature, freshness, and distinction from on-chain wallet. 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 tool has no parameters, so the schema coverage is 100%. The description adds context about session dependency, but no parameter semantics are needed. Baseline for 0 parameters 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 retrieves the TronSave internal account profile for the current session, listing specific fields (represent address, deposit address, balance). It distinguishes itself from the on-chain wallet and sibling tools.

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

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

The description specifies that a logged-in session from tronsave_login is required and includes how to provide the session ID. It advises use when the user needs internal account details, but does not explicitly exclude scenarios where alternatives should be used.

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

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

Annotations already declare readOnly, openWorld, and idempotent hints. Description adds valuable context: no login needed, optional session forwarding, and the fact that minPrice 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?

Two sentences, front-loaded with the core purpose, no redundant words. Every 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?

With output schema described, all 4 parameters documented, and annotations present, the description covers behavior, freshness, authentication, and integration points with sibling tools. 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 coverage is 100%, so baseline is 3. Description adds context about optional address scoping and default values, and clarifies that durationSec must match real order duration. Adds 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?

Description clearly states it quotes the minimum unit price for a buy, with a specific verb and resource. It distinguishes from siblings by naming 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 explicit guidance: use before placing an order, warns against reusing stale values (freshness note), and mentions pairing with other tools for full quotes. Also states no login required.

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 authentication requirement (signature session, mcp-session-id) and a FRESHNESS warning about rapid state changes, which are behavioral traits not covered by annotations. 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: first sentence states purpose, second provides usage guidelines with sibling references, third gives behavioral context, and final sentence covers requirements. No redundant words, front-loaded with key info.

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

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

For a simple read tool with one parameter and an output schema, the description covers purpose, usage guidelines, behavioral context, and prerequisites. 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 description coverage is 100%, with the only parameter 'id' well-described in the schema. The description merely mentions 'by id' and does not add significant new meaning beyond the schema. Baseline score of 3 is appropriate as schema does the heavy lifting.

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

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

The description clearly states 'Read one order by id and return its full snapshot for NORMAL, FAST, or EXTEND order types,' specifying the verb, resource, and scope. It distinguishes from siblings like tronsave_list_orders by focusing on 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 instructs to use before tronsave_update_order, tronsave_sell_order_manual, or tronsave_cancel_order to avoid stale state, and advises to re-read immediately before each mutation. Also mentions prerequisites: signature session and mcp-session-id. Provides clear when-to-use and rationale.

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. Description adds context: exactly how the message should be signed client-side and the expected submission format. No contradictions, but some behavioral details (e.g., side effects) are implied by 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 clear, well-structured sentences. Front-loaded with main purpose, then details. 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 no parameters and an output schema (mentioned but not shown), the description fully explains the tool's purpose, usage, and return format. Complete for its complexity.

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

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

No parameters in schema (100% schema coverage). Baseline is 4. Description adds value by explaining output structure and usage context, which is sufficient for a parameterless tool.

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 it issues a wallet-signable timestamp message helper for signature login. Specifies return format ({ message, timestamp }) and distinguishes itself from sibling `tronsave_login` by explaining the 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?

Explicitly states when to use it ('helper for signature login') and notes that clients may bypass it by signing their own timestamp payload, providing clear guidance on 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, openWorldHint, and idempotentHint. The description adds valuable behavioral context (calling before mutations to avoid field overwrites) beyond annotations, though it also repeats 'read-only and idempotent'.

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, each essential: purpose, usage guidance, and requirements. No filler or redundancy beyond necessary emphasis.

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

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

The description explains the tool's return value, prerequisites, and its role relative to sibling tools. Since an output schema exists, return details are covered. No gaps identified.

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 correctly has no parameter details. Per guidelines, 0 parameters 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 it reads the user's auto-sell configuration and returns the full autoSettings object. It explicitly names sibling tools (tronsave_register_auto_sell and tronsave_update_auto_sell_setting) to differentiate its role as a pre-read step.

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 calling this tool before register_auto_sell or update_auto_sell_setting to avoid overwriting unintended fields, and states prerequisites (signature session, mcp-session-id). This provides 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 already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds value by detailing the return shape, including nullable fields (info, internalAccount), and confirming read-only behavior. While annotations cover safety, the description adds 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: three sentences including return shape, prerequisites, and sibling differentiators. It is front-loaded with purpose and return type, then adds context. Every sentence earns its place with 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 zero parameters, rich annotations, and an output schema (not shown but mentioned as present), the description fully covers purpose, return shape (including nullable fields), prerequisites, and alternative tools. It is complete for a read-only info endpoint.

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

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

There are zero parameters, so the description does not need to add parameter details. The input schema is empty and coverage is 100%. The description does not mention parameters, which is appropriate. Baseline 4 for zero-param 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 reads the authenticated user's profile and internal account, specifies the returned fields, and distinguishes from sibling tools like tronsave_get_user_auto_setting and tronsave_get_user_permissions. The verb 'Read' and resource 'profile and internal account' 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 explicitly states prerequisites: requires signature session from tronsave_login and mcp-session-id. It also provides when-not-to-use guidance by naming alternative tools for specific purposes (auto-sell config, permission flags). This covers both when and when-not to invoke 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 declare readOnlyHint, openWorldHint, and idempotentHint as true. The description reinforces these with 'Read-only and idempotent.' and adds new behavioral context: the exact return format (`{ permitOperations: string[] }`) and required authentication setup. This goes beyond the structured 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 concise sentences: first states purpose, second gives return type and usage recommendation, third covers prerequisites and traits. 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 no parameters, annotations covering safety, and the description providing purpose, return format, usage context, and prerequisites, the description is fully complete. An agent has all needed information to decide 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?

The input schema has zero parameters, so schema coverage is 100% and no parameter documentation is needed. The description adds value by detailing the return structure, which compensates for the lack of parameter information. Baseline 4 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 verb 'Read', specifies the resource 'enabled permission operations (autoSettings.permitOperations)', and scopes to 'authenticated user'. It distinguishes from sibling tools by explicitly labeling itself as read-only and idempotent, which contrasts with the many mutation tools in the sibling list.

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

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

The description explicitly advises to use this tool 'before mutating auto-sell or auto-buy rules to confirm the action is allowed'. It also lists prerequisites ('requires a signature session and mcp-session-id'). While it doesn't specify when not to use, the guidance is clear and actionable.

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 key behavioral traits beyond annotations: 'Side effect: SPENDS internal TRX and creates an extension order; not idempotent.' Annotations already indicate idempotentHint=false and readOnlyHint=false, but the description adds spending context and the nature of the side effect. 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 slightly lengthy but front-loaded with the core action. Each sentence provides unique value, covering purpose, prerequisites, side effects, and step usage. Could be slightly more concise, but no information is redundant.

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

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

The description is complete given the output schema (returns { orderId }). It covers authentication, expected input (extendData from previous step), side effects, and typical workflow. No missing aspects for an 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?

Schema coverage is 100%, and the description adds contextual meaning: extendData must be 'Rows copied from extendData returned by tronsave_internal_extend_delegates', receiver is a TRON base58 address, and resourceType defaults ENERGY. This aids correct parameter invocation.

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 title 'Submit Delegation Extension' and description clearly specify the action: submitting an extension request for delegated resources on TronSave. It distinguishes from sibling tools like tronsave_internal_extend_delegates (STEP 1) and tronsave_create_order by explicitly stating its role as STEP 2 and that it spends internal TRX.

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 usage guidance: 'Use as STEP 2 after tronsave_internal_extend_delegates — pass its extendData rows unchanged.' It also details authentication requirements (logged-in MCP session, include mcp-session-id) and clarifies that internal tools never accept 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?

While annotations already declare readOnly, openWorld, and idempotent hints, the description adds essential context about session requirements, freshness sensitivity, and the extendData return payload.

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 purpose upfront, but slightly verbose with repeated session and internal tool notes. Could be tightened without losing clarity.

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?

Provides flow context, return data description, and freshness warning. Output schema exists (not shown) so return behavior is covered. Lacks only minor details like error conditions.

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 has 100% coverage with good descriptions; the description does not add significant meaning beyond the schema, 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?

Clearly states it returns extendable delegations and an extendData payload for the extension flow, distinguishing it from sibling tools like 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?

Explicitly identifies this as STEP 1 before tronsave_internal_create_extend_request, provides session setup requirements, and states it is read-only and does not submit.

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 read-only, open-world, idempotent. Description adds critical freshness behavior: data changes every ~3 seconds (TRON block) and advises re-reading before orders. Also explains internal tool authentication flow beyond annotations. 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?

Description is a single coherent paragraph, front-loads core purpose. Every sentence adds value, but could be slightly restructured for readability. No wasted words, but not extremely 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 that an output schema exists (not shown but indicated), the description need not explain return values. It covers purpose, usage prerequisites, freshness constraints, and tool relationships. Fully sufficient for an agent to use this tool correctly.

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

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

Input schema has 100% description coverage for all 4 parameters. The description only reiterates the default for resourceType ('ENERGY when omitted') which is already in the schema. No additional meaning beyond schema, so 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?

Clearly states the tool returns market depth/price tiers for ENERGY or BANDWIDTH. Distinguishes from siblings by positioning it as a prerequisite for tronsave_internal_order_create and tronsave_internal_order_estimate.

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 says when to use (before creating/estimating orders needing live prices) and provides detailed prerequisites: requires logged-in MCP session from tronsave_login, describes session types and authentication method. Effectively guides the agent on proper invocation 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 show it is not read-only, not idempotent, and not destructive. The description adds critical context beyond annotations: it states the side effect 'SPENDS internal TRX balance and creates a live order; not idempotent — each call places a new order.' It also clarifies the session handling and that internal tools never accept API keys. 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 relatively long but every sentence adds value. It is front-loaded with the main action and covers prerequisites, behavioral notes, and alternatives. While efficient, it could be slightly more concise without losing information.

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

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

Given the complex context (7 parameters, 2 required, 100% schema coverage, output schema present, two distinct paths), the description is comprehensive. It covers the action, session requirement, behavioral effects, pricing guidance, and return value `{ orderId }`. No significant 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%, so baseline is 3. The description adds extra meaning: it explains how to derive `unitPrice` from the `tronsave_internal_order_estimate` tool and mentions default values (e.g., 'Default MEDIUM when omitted' for unitPrice, 'Default ENERGY when omitted' for resourceType, 'Default 259200 (3 days) when omitted' for durationSec). This goes 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 verb 'Place a new buy order for ENERGY or BANDWIDTH on TronSave, paid from the internal account balance.' It specifies the resource type and distinguishes from the sibling tool `tronsave_create_order` for the signature-session market path, 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 tells the agent when to use this tool vs the alternative: 'This is the api-key/internal path; for the signature-session market path use `tronsave_create_order`.' It also explains the prerequisite of a logged-in session via `tronsave_login` and how to include the session ID, and provides guidance on deriving `unitPrice` from the latest 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?

Annotations already provide readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavioral context: requirements for session ID, explanation of session vs API key usage, and a freshness warning about rapid state changes. 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 concise with three sentences plus a freshness note, front-loading the primary purpose. Every 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?

Given the presence of an output schema, the description covers all needed aspects: purpose, usage context, prerequisites, and freshness. It is fully adequate for a read-only fetch 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 an example hint about the source of the orderId, improving usability without repeating schema details.

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

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

The description clearly states 'Fetch full details for one internal-account order by order ID.' It specifies the verb, resource, and scope, distinguishing it from sibling tools like tronsave_get_order and tronsave_internal_order_book.

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 scenarios: 'Use when monitoring fulfillment after tronsave_internal_order_create, or when the user asks for status on a specific order id.' It also mentions the prerequisite of a logged-in MCP session. It does not explicitly state 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?

Annotations already mark readOnlyHint=true and idempotentHint=true. The description adds freshness info (live data changes every 3 seconds) and confirms read-only behavior, providing extra 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?

Front-loaded with purpose, every sentence adds value: estimate purpose, login requirement, session type clarification, usage guidance, read-only note, and freshness detail. 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?

Given 7 parameters, nested objects, and an output schema, the description covers prerequisites, usage flow, behavioral nuances, and data freshness. Complete guidance for correct invocation.

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

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

Schema coverage is 100% with parameter descriptions. The description adds critical context: session ID inclusion (implicit parameter), and freshness constraints that inform parameter usage. This goes 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 estimates TRX cost and availability for a buy order before submission. It uses a specific verb ('estimate') and resource ('TRX cost'), and distinguishes it from the sibling `tronsave_internal_order_create`.

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 wants a quote or price check'), prerequisites (logged-in MCP session via `tronsave_login`), and how to feed results into the next tool. Explains session types.

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 critical behavioral details: requires a logged-in MCP session from `tronsave_login`, explains the `mcp-session-id` header requirement, clarifies that internal tools never accept API keys via arguments, and describes the two session types. 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 a single paragraph of 5 sentences, front-loaded with the main purpose. Each sentence adds value, though slightly verbose. Could be more structured (e.g., bullet points) but is concise enough.

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 essential aspects: purpose, authentication, pagination, usage context, and relationship to sibling tool. Output schema exists, so return values are not needed. Complete for a paginated list tool with authentication.

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 both parameters (page, pageSize). The tool description does not add extra parameter semantics beyond what the schema already provides. Baseline 3 due to full 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?

Describes exactly what the tool does: 'List paginated order history for the internal account linked to the API key, newest first.' Clearly specifies the verb (list), resource (order history), and pagination ordering. Distinguishes from sibling `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: 'Use when the user asks about past purchases, fulfillment, payouts, or delegates on their internal account.' Also notes it is read-only. Could be improved by explicitly stating 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?

Description confirms read-only and idempotent behavior, matching annotations. It adds context: GraphQL market data, session behavior, and that suggestData is for hypothetical scoring only. No contradictions and provides rich 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 somewhat long but every sentence serves a purpose. It front-loads the key action and then layers details logically. Minor redundancy could be trimmed, but overall efficient for the 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 moderate complexity (4 params, nested object, output schema exists), the description covers all aspects: purpose, parameters, behavior, session handling, and relationship to 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 100% schema coverage, the description still adds significant value: receiver typo? Actually explains address format and filter; requester clarifies when to use; suggestData details nested fields and warns against partial objects; resourceType clarifies use cases. All parameters are thoroughly explained 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 verb 'list', the resource 'extendable delegate candidates', and the key parameters (receiver, resourceType). It distinguishes itself from sibling tools by noting it is GraphQL market data for discovery only, not for order creation, and references the 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?

It explicitly states when to use ('Read-only; does NOT create orders or change on-chain state'), notes that it works without mcp-session-id and explains auth forwarding. It guides toward the REST endpoint for actual extensions, providing clear 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, openWorldHint, and idempotentHint. The description adds that no login is required and the data freshness interval (~3 seconds), providing useful context beyond annotations without contradicting them.

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 no wasted words. It front-loads the core function, then adds optional scoping, safety notes, freshness detail, and usage guidance in a logical order.

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

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

For a read-only market depth tool with 4 parameters, output schema present, and annotations covering safety, the description fully explains behavior, freshness, prerequisites (none), and sibling relationships. 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%, so the schema already documents all parameters. The description adds value by explaining the response shape (price buckets { min, max, value }), which is not in the input schema, and reiterates optional filtering roles.

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, specifies the return format (price buckets with min, max, value), and distinguishes itself from siblings like 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 says when to use it (estimate market ranges before create/update decisions), when not to use alternatives, and pairs with specific tools. Also includes a freshness note advising re-read before acting on a 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?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds behavioral context such as the requirement of signature login for isOnlyMyOrder and the status mapping, but does not contradict annotations. Slightly more detail could describe pagination behavior, but overall adequate.

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, front-loading the primary action and return format. It is slightly verbose but every sentence adds value. Minor redundancy could be trimmed, but it remains 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, full schema coverage, and an output schema, the description covers paging, filtering, auth, and status mapping. No gaps remain for the 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 coverage is 100% with descriptions, but the description adds meaningful context: explains the status enum mapping, clarifies that isOnlyMyOrder requires mcp-session-id and a signature session, and provides hints on limit usage. This goes beyond the schema's literal 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 'Query the order list with paging' and lists the return fields. It distinguishes this listing tool from sibling tools like tronsave_get_order (single order) and tronsave_create_order (mutation), making its 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?

Provides explicit guidance: paging with offset/limit, status mapping (ACTIVE/COMPLETED to GraphQL isFulfilled), and when to use isOnlyMyOrder with session requirements. Also recommends using tronsave_get_order before mutating. This helps the agent decide 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?

The description discloses side effects (creates a server session), emphasizes client-side wallet signing, and warns against sending private keys. Annotations indicate readOnlyHint=false and idempotentHint=false, which the description supports with 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 paragraph that efficiently conveys purpose, return value, usage modes, and side effects without unnecessary words, achieving high conciseness and clear structure.

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?

All relevant aspects are covered: authentication methods, session handling, return object details, and required follow-up action. The description is fully complete given the tool's complexity and available structured fields.

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?

Although schema coverage is 100%, the description adds significant value by explaining the signature format (signature_timestamp), mentioning the helper tool tronsave_get_sign_message, and clarifying that apiKey is raw, 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 tool authenticates with TronSave and creates a server session. It distinguishes itself from sibling tools, as it is the only login tool among order, account, and API key management tools.

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

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

The description explicitly describes two login modes (wallet signature and API key), specifies when to use each (platform tools vs internal tools), and provides instructions on passing sessionId in subsequent requests, offering comprehensive 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?

Discloses side effects: 'persists automation settings that affect future delegation/sell behavior; not idempotent — calling twice may reset fields.' Annotations indicate `readOnlyHint: false`, `idempotentHint: false`, and description adds contextual details like requiring a signature session. 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 well-structured sentences. First sentence states core purpose and return value. Second covers side effects, idempotency, requirements, and alternatives. Every sentence adds unique 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?

Despite the tool's complexity (3 nested object parameters), description covers purpose, side effects, non-idempotency, prerequisites, and failure conditions. Output schema exists (though not shown) and return type is mentioned ('Returns the persisted autoSettings payload'). One minor gap: no explicit mention of output schema details, 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?

Input schema has extensive descriptions for nested properties (e.g., `poolSetting`, `addOnFeature`). Schema coverage appears high (despite context stating 0%, likely a data issue). The description does not add additional meaning beyond the schema for parameters, 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?

Description clearly states 'Create the initial auto-sell configuration for the authenticated user.' It specifies the verb ('create') and resource ('initial auto-sell configuration'), distinguishing it from sibling tools like '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?

Explicitly advises 'Use for FIRST-TIME setup only; for subsequent edits use `tronsave_update_auto_sell_setting`, and always read the current state with `tronsave_get_user_auto_setting` first to avoid overwriting unknown fields.' This provides 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 only indicate idempotent and destructive. Description adds crucial context: in-flight sessions may continue until TTL, key is best-effort immediate, and requires a signature session. This fully discloses behavior 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?

Four sentences, each adding value: purpose, side effect, idempotency, follow-up action. No fluff, well-structured and front-loaded.

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

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

The description fully explains behavior, side effects, prerequisites, and post-action guidance. Given no parameters and an output schema exists, it is complete for selection and 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?

With 0 parameters, the schema already covers all. However, the description adds that the tool requires a signature session and mcp-session-id (implicit context), providing meaning beyond the empty 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 'Revoke the caller's current internal API key', which is a specific verb-resource pair. It is distinct from sibling tools like tronsave_generate_api_key, which creates a key.

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 (revoke current key) and recommends calling tronsave_generate_api_key afterwards for replacement. Also notes that effect is best-effort immediate, not instantaneous, guiding appropriate 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?

Beyond annotations (destructiveHint=true, idempotentHint=false), the description adds key behaviors: 'broadcasts a market/delegation transaction', 'may consume balances/resources', and explicitly states 'not idempotent — each call re-executes'. No contradiction with annotations. This provides actionable insight.

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 front-loaded purpose. Slightly verbose on auth details, but each sentence earns its place. Structure is logical: purpose, side effects/auth, usage guidance.

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 (nested params, output schema exists), the description covers purpose, usage, side effects, auth, and relation to sibling tools. No missing critical information for agent 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%, so baseline is 3. The description adds value: for orderId it notes eligibility criteria, for signedTx it warns against fabrication and explains origin, and for paymentAddress it clarifies optional use. Meaningfully supplements 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 specifies the action ('manually execute seller-side fulfillment'), the resource ('existing order'), and the required input ('wallet signedTx'). It distinguishes from siblings by stating 'Use only when explicit manual sell is intended' and recommends calling tronsave_get_order first, making the purpose clear.

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

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

Provides explicit guidance on when to use ('explicit manual sell intended') and prerequisites ('call tronsave_get_order first to verify order state before signing'). It also details authentication requirements (signature session, mcp-session-id) and warns about API-key-only sessions. Does not exhaustively list when not to use alternatives, but context is strong.

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

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

Description adds important side-effect details ('overwrites stored automation settings for the current user; not idempotent across different field sets') that go beyond annotations (readOnlyHint false, destructiveHint false, idempotentHint false). 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, each dense with information. Front-loaded with purpose, followed by side effects and usage guidance. No redundant 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 purpose, usage, side effects, prerequisites, alternatives, failure conditions, and notes output schema existence. Complete for a complex tool with nested parameters.

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?

Despite 0% schema coverage, the description provides minimal guidance on parameters. It mentions 'partial fields' but does not explain the complex nested structure or the role of each property. The schema itself has descriptions, but the description should add 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 uses a specific verb ('Update') and resource ('auto-sell configuration') and distinguishes from sibling tools like 'tronsave_register_auto_sell' 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?

Explicitly states when to use ('incremental changes after registration'), when not to use ('use tronsave_register_auto_sell only for first-time setup'), and prerequisites ('requires a signature session and mcp-session-id'). Also lists 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, backend auth requirements (signature session, mcp-session-id), and GraphQL helper rejection of api-key-only sessions. This goes well 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?

Concise and well-structured: main action first, then side effects, usage guidance, and failure conditions. Every 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?

Covers all essential aspects: action, parameters, side effects, auth, failure cases, alternatives, and return value. Output schema complements absence of explicit return 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?

Description adds meaning beyond schema by specifying that orderId is required and order must be open/editable. Schema already provides good descriptions with 100% 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 it updates an open order by orderId with partial fields (receiver, newPrice) and returns the updated payload. It distinguishes from sibling tools like tronsave_create_order and tronsave_cancel_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 recommends using this over cancel+recreate when only price/receiver needs to change. Also notes it fails for already-fulfilled/cancelled/non-editable orders and advises 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.