Tronsave MCP Testnet

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

Describes side effects (marks order non-matchable, refunds balance), confirms idempotency, and lists failure scenarios. Adds rich context beyond annotations (readOnlyHint, destructiveHint, idempotentHint) 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 front-loaded with core action, followed by side effects, idempotency, failure conditions, and usage tips. Every sentence is purposeful, no fluff, and appropriately sized.

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 guidelines, behavioral traits, parameter details, and error cases. With an output schema present, the description need not explain return values, and it fully equips an agent to decide and invoke the tool correctly.

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

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

The description for orderId adds requirements (must be active, owned/authorized) and expected failure cases, supplementing the schema's type and minLength. With 100% schema coverage, the description still adds valuable 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 'Cancel an open order by orderId' with specific verb and resource. It distinguishes itself from sibling tools like tronsave_update_order and suggests tronsave_get_order for state verification.

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 when to use (cancel open order), what to verify first (use tronsave_get_order), and when to prefer alternatives (use tronsave_update_order for price/receiver changes). Also mentions required session and failure conditions.

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

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

Annotations indicate non-read-only and non-idempotent. The description confirms the side effect (creates a live order), requires a signature session, and warns about staleness. It adds context 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 moderately long but well-structured, starting with purpose, then key inputs, side effect, and important usage notes. It could be slightly more concise, but all information is relevant 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?

Given the complexity (8 parameters, nested objects, two payment methods), the description covers the workflow, prerequisites, and freshness requirement. It references the estimate tool for parameter derivation. While output is not described, an output schema exists, so this is acceptable.

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

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

Schema coverage is 100%, but the description adds value by linking orderUnitPrice and paymentPaymentAmount to the estimate tool, explaining the consistency needed with estimate parameters, and clarifying payment method semantics. This goes 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 explicitly states it creates a new buy order on the TronSave market. It lists key inputs and the side effect of creating a matchable order. The verb 'create' aligns with the tool name, and the resource 'buy order' is clearly defined. While sibling tools exist, the purpose is 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 provides clear guidance on deriving parameters from tronsave_estimate_buy_resource to avoid reverts, and explains the two payment methods and their requirements. It also warns about freshness. However, it does not explicitly state when to use this tool versus alternatives like tronsave_cancel_order or tronsave_update_order.

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

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

Details permanent deletion, stopping future executions, irreversibility, idempotence, and required session/auth, adding significant 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?

Two efficient sentences front-load action and effect, with 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 prerequisites, side effects, idempotency, and alternatives, fully leveraging schema and annotations for a complete tool understanding.

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 reinforces the 'id' parameter with context (MObjectId, rule to delete), adding modest value beyond the schema.

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

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

The description specifies the verb 'delete' and resource 'auto-buy rule by id', clearly distinguishing from sibling tools like '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 to list rules first with a sibling tool and recommends disabling/updating 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, idempotentHint, openWorldHint. Description adds no session required, backend rate limits, and data freshness (changes every TRON block ~3 seconds), providing 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?

Length is appropriate; front-loaded with purpose, then guidelines, then freshness warning, then sibling differentiation. Every sentence serves a purpose, though slightly verbose.

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

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

Given 7 optional parameters, rich annotations, and output schema, description covers the tool's role, freshness, sibling alternatives, and key output fields. Does not detail output schema but that is acceptable since schema exists.

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

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

Schema coverage is 100% with each parameter described. Description adds context about receiver address and output fields (unitPrice, paymentAmount, availability) but does not deepen parameter semantics beyond schema. Baseline 3.

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

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

Description clearly states it quotes price and availability for buying ENERGY or BANDWIDTH for a receiver address. Distinguishes from siblings like tronsave_create_order (uses quotes), tronsave_list_order_books (order-book depth), and tronsave_get_min_price (minimum price only).

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

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

Explicitly advises to re-run immediately before tronsave_create_order, not to reuse a quote more than a few seconds old, and contrasts with sibling tools. States it is read-only and safe for repeated calls.

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?

Describes side effect of issuing secret material, non-idempotent behavior, key rotation implications, prerequisites (signature session, mcp-session-id), and security warnings (never log raw keys, unauthorized rejection). Adds significant 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?

Multiple sentences but each adds value; front-loaded with primary action. Could be slightly shorter, but 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?

Fully covers purpose, usage, side effects, security, and integration with other tools. No output schema needed as description explains return value. Complete for a parameterless tool with good annotations.

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 input schema, so description need not add parameter details. Baseline 4 applies as there is nothing to explain.

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 generates a new internal API key credential for the current user, specifying the output format and usage context. Distinguishes itself from sibling tools like tronsave_revoke_api_key by describing its purpose.

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

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

Provides guidance on storing the key securely, passing it to tronsave_login, and notes that it rotates old keys. Lacks explicit when-to-use vs alternatives, but gives actionable 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 declare readOnlyHint, idempotentHint, and openWorldHint. Description adds authentication details (session ID, no API key arguments), session type explanation, and operational constraints (TRX only, min 10 TRX). 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, each essential. Front-loaded with main action, then authentication, usage trigger, and constraints. No filler or repetition.

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

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

Given one parameter, rich annotations, and output schema present, the description covers necessary context: authentication flow, trigger conditions, constraints. No gaps for a read operation with a simple input.

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

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

Schema description coverage is 100% and already specifies amountTrx with minimum 10. Description adds no further meaning beyond restating the minimum. Baseline 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 the tool fetches a deposit address for the TronSave internal account, with specific constraints (TRX only, min 10 TRX), distinguishing it from siblings like tronsave_get_internal_account.

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 trigger ('if user asks for deposit address or needs to top up') and requires a logged-in session from tronsave_login. Does not mention when not to use or alternatives, but the tool is unique among siblings.

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 the tool as read-only, idempotent, and open-world. The description adds important context: it requires an active session, explains the difference between signature and api-key sessions, states 'Read-only; does not submit orders or change chain state,' and notes that the balance is live and can change within seconds after deposits or orders. This provides behavioral insight beyond what annotations offer.

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: it starts with the main purpose, then details prerequisites, authentication, what the tool returns, usage guidance, and behavioral notes. Each sentence adds value. It is slightly long but not verbose; every piece of information is useful for correct invocation.

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

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

Given the tool has no parameters and an output schema exists (signaled in context), the description covers all necessary aspects: purpose, prerequisites, authentication method, typical use cases, and safety (read-only). It also addresses state freshness. 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?

The input schema has zero parameters, so the baseline is 4. The description correctly doesn't mention parameters because there are none. It does mention the requirement of a session but that is not a parameter; it's a condition for use, which 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 states a specific verb ('Retrieve'), a clear resource ('TronSave internal account profile'), and lists exactly what fields are returned (represent address, deposit address, balance in SUN). It also distinguishes from siblings by noting 'This is the api-key internal account, not the on-chain wallet.' This differentiates it from other tools like tronsave_get_deposit_address or on-chain wallet lookups.

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 needs their linked address, deposit address, or internal balance.' It also provides context: requires a logged-in session from tronsave_login and instructions for including the mcp-session-id header. While it doesn't list specific alternatives to avoid, it clearly sets the scope and prerequisites.

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 context: no login required, optional session auth, that data changes roughly every 3 seconds, and the return structure (`{ minPrice }`). This goes beyond the annotations and provides actionable behavioral 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?

The description is a single paragraph but packs essential information efficiently: purpose, return value, parameters, authentication, freshness, and companion tools. It is front-loaded with the core action. Slightly more structure (e.g., bullet points) could improve scannability, but it is concise and clear.

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

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

Given the tool has 4 parameters, an output schema, and many siblings, the description covers all necessary aspects: purpose, return format, parameters, authentication requirements, data freshness warning, and related tools. No gaps are evident for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so baseline is 3. The description mentions the parameters (`resourceType`, `buyAmount`, `durationSec`, `address`) but does not add meaning beyond what is already in the schema. No additional elaboration on parameter values or usage is provided.

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

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

The description clearly states the tool's purpose: 'Quote the minimum unit price for a buy.' It specifies the action (quote/estimate) and resource (minimum unit price). It also distinguishes from siblings by recommending pairing with `tronsave_estimate_buy_resource` for full buy quotes and `tronsave_list_order_books` for depth buckets.

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 usage context: 'No login required' indicates when authentication is unnecessary, and it emphasizes data freshness ('re-fetch right before placing an order and do not reuse a stale value'). It suggests companion tools but does not explicitly state when not to use this tool, though 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?

Annotations already indicate read-only and idempotent behavior; the description adds that a signature session and mcp-session-id are required, and warns about rapid state changes, providing extra 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?

Concise and front-loaded: first sentence states purpose, then usage guidance, then freshness note, and finally requirements. No wasted words.

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

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

For a simple one-parameter tool with an output schema, the description covers purpose, usage, behavioral notes, and prerequisites comprehensively.

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

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

Schema coverage is 100% with a clear description for the 'id' parameter; the description reinforces its use but does not add new semantic information 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 reads one order by id and returns its full snapshot for specific order types, distinguishing it from sibling tools by naming them explicitly.

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 to use this tool as the source of truth before update, sell, or cancel actions, and warns about state freshness to avoid stale data.

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 provide readOnlyHint, openWorldHint, idempotentHint. The description adds behavioral context beyond annotations by explaining the return format and the flow of signing and submitting to `tronsave_login`, plus noting the tool is optional.

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

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

The description is two sentences, front-loaded with the main purpose, and every sentence provides essential information without redundancy.

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

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

Given no parameters, existing annotations, and output schema (present), the description fully explains the return values and usage flow, making it complete for a helper 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 is empty (no parameters), so schema coverage is 100%. Description adds no parameter info, but baseline is 4 for zero-parameter 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 the tool issues a wallet-signable timestamp message for signature login. It specifies the return format (`{ message, timestamp }`) and distinguishes it from siblings by referencing `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 explicitly says when to use the tool (for signature login) and notes that clients may also sign their own timestamp payload directly as an alternative, providing clear 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?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. Description adds context beyond annotations by specifying it's 'read-only and idempotent' and mentioning authentication requirements (signature session, 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?

Three sentences: purpose, return value with usage tip, and additional requirements. No waste, 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 the tool has zero parameters and an output schema (not shown but present), the description fully covers purpose, return object, usage guidance, authentication, and idempotency. Complete for the tool's 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 the input schema, so description doesn't need to explain them. Baseline 4 as schema coverage is 100%. Description adds value by explaining the return object and usage context.

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

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

Clearly states it reads the current user's auto-sell configuration (autoSettings) and returns the full object. Distinguishes from sibling tools by recommending use before update/register tools to avoid field overwrites.

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 calling this before tronsave_register_auto_sell or tronsave_update_auto_sell_setting to prevent unintended field overwrites. Also notes the need for a signature session and mcp-session-id, providing clear when-to-use and prerequisites.

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

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

Description reinforces annotations (read-only, idempotent) and adds context: nullability of info and internalAccount, return structure. 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 concise sentences: purpose, return shape, prerequisites, and usage guidance. No redundancy or unnecessary 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?

With no parameters and rich annotations, the description covers all necessary context: auth requirements, return structure, null states, and sibling tool differentiation.

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 (schema coverage 100%), but description adds value by explaining return object fields, their types, and null conditions, exceeding baseline 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?

Clearly states it reads authenticated user's profile and internal account, with explicit return fields. Distinguishes from sibling tools by naming alternatives for specific 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 notes prerequisites (signature session, mcp-session-id) and provides alternatives: tronsave_get_user_auto_setting and tronsave_get_user_permissions for 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 provide readOnlyHint, idempotentHint, and openWorldHint. The description adds beyond: authentication requirement ('signature session and mcp-session-id') and confirms read-only and idempotent nature. No contradictions.

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

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

Two sentences: first states purpose and return, second gives usage guidance and prerequisites. No unnecessary words, well front-loaded.

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

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

Given the tool is simple (no parameters, output schema exists), the description covers purpose, return format, usage context, and prerequisites. Complete for an AI agent.

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

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

There are no parameters in the input schema (schema coverage 100%). The description adds value by specifying the return structure 'Returns { permitOperations: string[] }', clarifying what the tool outputs.

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 enabled permission operations...', with a specific verb and resource. It distinguishes from sibling tools by focusing on read-only permission checking, unlike mutation tools like tronsave_create_order.

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

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

The description instructs to 'use it before mutating auto-sell or auto-buy rules to confirm the action is allowed', providing explicit context for when to use. It does not list alternatives but implicitly contrasts with mutation siblings.

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-readOnly, non-idempotent, open world. Description adds specifics: spends internal TRX, creates order, session authentication details, and that internal tools don't accept API keys. 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 paragraph with multiple sentences, but most sentences add unique value. Slightly repetitive on session handling, 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?

Covers purpose, usage, authorization, side effects, and return format (orderId). Missing details on error handling or session expiration, but adequate for typical use with annotations and output schema hinted.

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. Description adds value by explaining that extendData rows should be passed unchanged from tronsave_internal_extend_delegates, which aids correct usage 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 it submits an extension request for delegated resources, using specific verbs ('Submit') and resource ('extension request'). It distinguishes from sibling tools like tronsave_internal_extend_delegates (step 1) and others by explicitly positioning itself as step 2.

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 step context ('Use as STEP 2 after tronsave_internal_extend_delegates'), details session requirements (tronsave_login), and notes side effects (spends TRX, not idempotent). This gives clear when-to-use and prerequisites.

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: requires logged-in session, explains session types, freshness warning, and instruction to pass extendData unchanged. 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?

Front-loaded main purpose, then provides necessary details. A bit lengthy 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?

Covers session, workflow, and freshness. Does not differentiate from sibling tronsave_list_extendable_delegates or explain return details beyond what output schema likely provides.

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 does not add extra meaning to parameters beyond the schema's 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 states it returns extendable delegations and extendData payload, and positions it as STEP 1 in a workflow. However, it does not distinguish from sibling tool 'tronsave_list_extendable_delegates' which may serve a similar purpose.

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

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

Explicitly says when to use (before tronsave_internal_create_extend_request) and that it's read-only. Does not provide when-not-to-use or alternatives, 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 declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable context: auth mechanism (session-based, not API key via arguments), internal vs. api-key session behavior, and freshness behavior (changes every 3 seconds). 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 well-structured with multiple sentences, each adding essential info. It is front-loaded with the main purpose. While not extremely concise, it avoids fluff and every sentence earns its place. Could be slightly shorter, but 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 that an output schema exists (though not shown), the description covers authentication, usage context, parameter defaults, freshness, and read-only nature. It is complete for a read-only market book tool with good annotations.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context by noting that address and resourceType are optional with a default for resourceType, and explains minDelegateAmount meaning. This extra information justifies a 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 returns market depth/price tiers for ENERGY or BANDWIDTH, specifies the REST endpoint, and distinguishes itself from siblings like tronsave_internal_order_create by indicating usage before that tool. The verb (Return) and resource (market depth/price tiers) are specific.

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 requires a logged-in MCP session from tronsave_login, explains how to include the session ID, and advises to use before order_create or order_estimate when live prices are needed. Also notes the freshness caveat to re-read every 3 seconds.

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 effect: 'SPENDS internal TRX balance and creates a live order; not idempotent — each call places a new order.' This adds detail beyond the annotations (idempotentHint false) and explains the impact and non-idempotency clearly.

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 front-loads purpose, then prerequisites, side effects, distinctions, and guidance. Every sentence adds value, though it could be slightly more structured (e.g., bullet points). Length is appropriate 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?

Covers all required context: session requirement, side effects, non-idempotency, sibling tool distinction, pricing guidance from estimate, and return value ({ orderId }). Output schema exists but description still mentions the return shape, which is helpful.

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 explaining how to use unitPrice (derive from estimate), that options control fill behavior, and that durationSec defaults to 3 days. This exceeds mere repetition of schema.

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

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

The description clearly states the action: 'Place a new buy order for ENERGY or BANDWIDTH on TronSave, paid from the internal account balance.' It distinguishes from sibling tool tronsave_create_order by specifying this is the api-key/internal path versus the signature-session market path.

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

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

Explicitly requires a logged-in MCP session from tronsave_login and provides the mcp-session-id header. It contrasts with the signature-session alternative (tronsave_create_order). Also advises to derive unitPrice from the latest tronsave_internal_order_estimate and warns about stale quotes.

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 authentication requirements (needs mcp-session-id from tronsave_login, no API keys in arguments), differentiates session types, and adds freshness note about order state changes. Annotations already declare readOnlyHint, idempotentHint, openWorldHint; description adds beyond 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 and well-structured: purpose, authentication, usage context, read-only comment, freshness note. Every sentence adds value with no redundancy.

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

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

Given only one parameter, output schema present, and rich annotations, the description covers all essential aspects: purpose, authentication, usage, read-only nature, and data freshness. 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 description coverage is 100% and adequately describes the orderId parameter. The tool description does not add extra semantics for the parameter; 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 it fetches full details for one internal-account order by order ID, using a specific verb and resource. It distinguishes from siblings by noting use cases like monitoring fulfillment after tronsave_internal_order_create or querying status by order ID.

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

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

Explicitly tells when to use the tool (monitoring fulfillment, specific order status). Mentions read-only nature and the need for a logged-in session, but does not explicitly state when not to use. Still provides clear context.

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

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

Annotations already provide readOnlyHint, idempotentHint, openWorldHint. The description adds valuable operational context: session-based auth (no API keys), freshness note (data changes every 3 seconds, re-estimate before create). 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 of 5 sentences, front-loaded with purpose and prerequisites. It is relatively concise but could be more structured (e.g., bullet points). No wasted sentences.

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 (1 required), nested objects, output schema exists, the description covers purpose, prerequisites, usage, authentication, freshness, and links to next tool. It is complete for the complexity level.

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 description does not need to add much. It does not elaborate on parameter meaning beyond what the schema provides. The freshness note refers to output fields, not inputs. 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 estimates TRX cost and availability for a buy order before submission, with a specific verb and resource. It distinguishes itself from siblings like tronsave_internal_order_create by positioning as a pre-order quote 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?

The description explicitly says 'Use when the user wants a quote or price check' and directs to feed results into tronsave_internal_order_create. Prerequisites (logged-in session, session ID header) are provided. Lacks explicit when-not-to-use, 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?

Adds significant behavioral context beyond annotations: requires a logged-in MCP session from 'tronsave_login', includes 'mcp-session-id', explains internal tool auth model (no API key arguments, signature vs api-key sessions). 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?

Concise paragraph with logical flow: main function, prerequisite, auth explanation, usage hints, read-only note, pairing note. No redundant 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?

Covers all essential aspects: purpose, usage context, authentication requirements, pagination behavior. Output schema exists so return values are not needed. Complete for tool complexity.

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

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

Schema coverage is 100% so baseline is 3. Description adds helpful usage hints: page is 0-based with default 0, pageSize typical range 1-100, and omit for first page. 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?

Description clearly states verb 'list', resource 'order history for the internal account', and ordering 'newest first'. Distinguishes from sibling 'tronsave_internal_order_details' by noting it is for a single order's full snapshot.

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

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

Explicitly says to use when user asks about past purchases, fulfillment, payouts, or delegates. Mentions pairing with another tool for single order. Does not explicitly state when not to use, but context implies it is for paginated history only.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds significant behavioral context: it confirms the tool is read-only and does not change state, explains session handling, and clarifies it is GraphQL market data for discovery only. 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 with four sentences, each providing essential information. It is front-loaded with the core purpose, then covers optional inputs, behavioral traits, and a critical note about the actual submission endpoint. No extraneous 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 has 4 parameters (with nested objects), an output schema, and many sibling tools, the description is comprehensive. It covers purpose, parameter context, read-only nature, session handling, and a pointer to the correct endpoint for submission. It does not need to explain the output schema since it exists.

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 the schema already documents all parameters. The description provides some additional context (e.g., that receiver and resourceType are primary filters, and suggestData fields must be supplied together), but it largely reiterates the schema descriptions. This adds marginal value beyond the schema.

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

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

The description clearly states that the tool lists extendable delegate candidates for a given receiver and resourceType (ENERGY or BANDWIDTH). It uses specific verbs ('List extendable delegate candidates') and identifies the resource. It distinguishes itself from siblings by noting it is read-only and part of GraphQL market data discovery, not 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?

The description explicitly states when to use this tool: for discovery and planning. It warns against using it for actual order submission, directing to a different endpoint. It also explains that it works without a session and how auth is forwarded when present, and clarifies that suggestData is optional for scoring.

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

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

Annotations already mark readOnlyHint, openWorldHint, idempotentHint. The description adds valuable freshness info: 'buckets can shift roughly every 3 seconds; re-read immediately before acting on a price'. 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 two sentences plus a freshness note and usage pairing, all front-loaded. Every sentence adds value without verbosity.

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 doesn't need to detail return values. It covers purpose, usage, freshness, and pairing, making it complete for a read-only market depth 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%, and the description adds meaning by explaining the output structure ('Returns price buckets { min, max, value }') and how parameters scope the result ('optionally scoped by viewer address, minimum delegate amount, and duration').

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 'Read market depth buckets for ENERGY or BANDWIDTH' with a specific verb and resource. It distinguishes from sibling tools by explicitly mentioning pairing with 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?

It clearly states when to use ('estimate market ranges before create/update decisions'), notes no login required, and provides explicit alternatives (pair with tronsave_estimate_buy_resource for quotes, tronsave_get_order for a concrete order).

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

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

Annotations already declare 'readOnlyHint', 'openWorldHint', and 'idempotentHint'. The description adds valuable behavioral details: paging behavior, status-to-GraphQL mapping, and the authentication requirement for filtering by user. 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 efficient and well-structured, front-loading the core action. Every sentence adds value—no filler. It includes the return type, parameter behavior, and a usage recommendation in a compact form.

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 (5 parameters, paging, conditional auth, inline output schema), the description is fully complete. It covers all essential aspects: return shape, paging, filter mappings, and preconditions. The existing output schema is well-described inline.

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%, providing a baseline of 3. The description adds significant meaning: explains paging mechanics, the status mapping (ACTIVE/COMPLETED to UNFULFILLED/FULFILLED), the purpose of 'isOnlyMyOrder' and its authentication prerequisite, and the optional nature of filters.

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: 'Query the order list with paging.' It lists the return fields, distinguishes itself from the sibling 'tronsave_get_order' (which provides a full snapshot for a single order), and specifies filtering capabilities.

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 when to use this tool (listing orders with paging) and mentions the alternative 'tronsave_get_order' for a one-order snapshot. It also notes that 'onlyMyOrder' requires signature login and an 'mcp-session-id', 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=false, openWorldHint=true), the description discloses the side effect of creating a new server session, the return value structure, and client-side signing requirements. It explains the signature format and warns against sending private keys, providing comprehensive 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 well-structured and informative, but it is slightly longer than necessary. However, all information is relevant and no sentences are wasted, earning a score of 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 the tool's complexity and the presence of an output schema, the description fully covers return values, both authentication modes, side effects, and usage instructions. It leaves no gaps for an AI agent to misunderstand.

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 crucial meaning: it explains the exact format for 'signature' (<signature>_<timestamp>), that 'apiKey' is raw, and that exactly one must be provided. This goes well beyond the schema's minimal 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's purpose: 'Authenticate with TronSave and create a server session.' It uses a specific verb ('Authenticate') and resource ('TronSave'), and is distinct from sibling tools which handle orders, accounts, etc.

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

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

The description explicitly details two login modes (wallet signature for platform tools, API key for internal tools) and provides guidance on when to use each. It instructs the user to pass the returned sessionId as a header on subsequent requests, leaving no ambiguity about post-login procedure.

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 (idempotentHint: false) and not read-only (readOnlyHint: false). The description adds valuable context: 'not idempotent — calling twice may reset fields', 'Side effect: persists automation settings that affect future delegation/sell behavior', and failure modes ('Fails for invalid config combinations, unauthorized sessions, or backend policy restrictions'). This goes beyond annotations, so a score of 4 is appropriate.

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

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

The description is two sentences with no wasted words. It front-loads the purpose, then covers side effects, usage guidance, and failure conditions in a logical order. 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?

Despite the tool's complexity (3 parameters with nested objects), the description covers the return value, side effects, failure conditions, and usage boundaries. The output schema is mentioned, so return values are addressed. The description is complete for an agent to use this tool correctly alongside siblings.

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 effectively high (each property in the input schema has explicit descriptions), so the baseline is 3. The description does not add additional meaning or guidance beyond what the schema already provides. It briefly notes that it returns a payload but does not elaborate on parameter relationships or constraints.

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 the initial auto-sell configuration for the authenticated user.' It uses a specific verb ('Create') and resource ('auto-sell configuration'), and distinguishes 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?

The description provides explicit when-to-use and when-not-to-use guidance: '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.' It also mentions prerequisites: 'Requires a signature session and mcp-session-id.'

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

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

Goes beyond annotations by explaining the side effect (in-flight sessions may continue until TTL expiry, best-effort immediate) and reaffirms idempotency. 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, efficient and front-loaded with the main purpose. Every sentence adds value, though could be slightly tighter.

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, prerequisites, and follow-up action. For a zero-parameter tool with rich annotations, the description is complete and self-sufficient.

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

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

Input schema has 0 parameters (100% coverage), so no parameter documentation needed. Baseline score of 4 applies; description adds no extra param info but doesn't need to.

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: revoke the caller's current internal API key. It uses a specific verb and resource, and distinguishes itself from sibling tronsave_generate_api_key which creates keys.

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

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

Explicitly mentions requiring a signature session and mcp-session-id, and advises calling tronsave_generate_api_key afterwards for a replacement. Could be more explicit about when not to use, but provides clear 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 indicate destructiveHint=true and idempotentHint=false. The description adds critical behavioral context: 'broadcasts a market/delegation transaction and may consume balances/resources; not idempotent — each call re-executes'. It also discloses backend requirements (signature session and mcp-session-id) and authentication nuances. This enriches the agent's understanding beyond annotations.

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

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

Every sentence adds value. The first sentence states the core action. Subsequent sentences cover side effects, idempotency, auth constraints, and usage guidance. No redundancy. The description is front-loaded with the most critical information and efficiently expands into specifics.

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

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

Given the tool's complexity (3 parameters, nested input objects, side effects, output schema), the description fully covers what the agent needs: purpose, side effects, prerequisites, authentication, and usage conditions. It references the output schema implicitly and sets expectations for the result. No gaps remain.

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

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

Schema coverage is 100% with descriptions for all parameters. The description adds meaning: for 'signedTx', it states 'Must come from client-side signing; never fabricate'. For 'orderId', it clarifies 'Should be an order eligible for seller-side manual execution'. For 'paymentAddress', it says 'Optional payout/payment address override when settlement flow requires it'. This provides practical guidance beyond 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 the action: 'Manually execute seller-side fulfillment of an existing order with a wallet signedTx'. It specifies the verb (execute), resource (order fulfillment), and scope (manual seller-side). It distinguishes this tool from siblings like tronsave_create_order (creates orders) and tronsave_update_order (modifies order settings) by focusing on manual execution of an existing 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 explicitly states when to use: 'Use only when explicit manual sell is intended'. It provides a precondition: 'call tronsave_get_order first to verify order state before signing'. It also warns against automatic usage, implying this tool is for manual intervention only. This gives clear guidance with a concrete alternative action.

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 effect (overwrites stored automation settings) and non-idempotency across different field sets beyond annotations. Also mentions required session and session-id. No contradiction with annotations.

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

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

Concise, front-loaded purpose, no extraneous words. Well-structured with one clear sentence each for purpose, side-effect, usage guidance, and failure conditions.

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, prerequisites, failure modes, return value, and sibling differentiation. Missing only minor details like authentication requirements (implied by session-id) and idempotency nuances, but overall adequate for a complex tool with many siblings and a large 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?

With 0% schema description coverage, the description does not explain the three top-level parameters (poolSetting, addOnFeature, paymentConfig) or their fields. The phrase 'partial fields' minimally implies optionality but lacks semantic depth for a complex nested 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 updates an existing auto-sell configuration with partial fields, distinguishing it from `tronsave_register_auto_sell` for first-time setup. The verb 'Update' and resource 'auto-sell configuration' are specific.

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 to use for incremental changes after registration, advises reading baseline via `tronsave_get_user_auto_setting` to avoid resets, and notes failure conditions (invalid fields, unauthorized sessions, policy constraints). Clear when-to-use and when-not-to-use.

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

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

Annotations provide readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=true. Description adds side effect detail ('overwrites live order parameters; not idempotent — each call with a different newPrice produces a new state'), enhancing beyond annotations. No contradiction.

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

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

The description is a single paragraph with front-loaded core purpose, followed by side effects, auth context, usage guidance, and precautions. Every sentence is informative and non-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?

Given the tool's complexity (mutation with side effects, auth needs, failure conditions), the description covers all essential aspects: purpose, side effects, idempotency, authentication, preconditions, failure scenarios, and sibling differentiation. Output schema exists so return value is not needed.

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 three parameters. Description adds unit context (SUN for newPrice, TRON address for receiver) and conditions (order must be open/editable). While schema already covers basics, the additional context justifies a score above baseline 3.

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

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

The description clearly states 'Update an open order by orderId with partial fields (receiver, newPrice). Returns the updated order payload.' It also distinguishes from sibling tools by recommending this over cancel+recreate when only price/receiver change.

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 this over cancel+recreate, instructs to verify state with tronsave_get_order first, and notes failure conditions (fulfilled, cancelled, non-editable). Also mentions backend authentication requirements (signature session, mcp-session-id) and gate type.

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