Tronsave MCP Testnet

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

No annotations exist. Description only states the cancel action and requirement, without disclosing side effects (e.g., refunds, status changes), reversibility, or error scenarios. Does not compensate for missing annotations.

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

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

Single sentence, front-loaded with the main verb and resource. No extraneous information. Very 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?

Sufficient for a simple cancel operation with one required parameter. However, lacks any mention of output or confirmation, and no annotations provide extra context. Adequate but not thorough.

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

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

Input schema has 100% coverage with a description for orderId. The description adds no new meaning beyond 'by orderId'. Baseline score of 3 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 the action (cancel) and resource (order) with specific identifier (orderId). Differentiates well from sibling tools like 'update_order' or '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?

Mentions prerequisites (valid signature session and mcp-session-id) but provides no guidance on when to use this tool vs alternatives or conditions where cancellation is allowed. Lacks exclusions or 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?

No annotations present, so description must cover behaviors. Describes prerequisites and conditional requirements but lacks side effects, rate limits, or failure behavior.

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

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

Two sentences, front-loaded with action and key differentiator (payment methods), then conditional 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 9 parameters with conditional logic, description covers purpose, prerequisites, and parameter relationships. Output schema exists but not needed in description.

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

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

Schema coverage is 100%, baseline 3. Description adds meaning by linking parameters to tronsave_estimate_buy_resource, explaining unit conversion (SUN to TRX), and clarifying conditional requirements.

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 an order' with specific details on payment methods and references to estimation tool. Distinguishes from sibling tools like tronsave_cancel_order and tronsave_update_order.

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

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

States requirement for signature session and mcp-session-id, and conditional fields per payment method. Could explicitly mention when not to use or list alternatives, but context implies proper 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?

The description mentions permanent deletion and authentication requirements, which are important behavioral traits. However, it does not disclose any side effects or cascade behaviors, and there are no annotations to supplement. Moderate transparency.

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

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

The description is two concise sentences, front-loading the primary action and then specifying requirements. 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 the tool's simplicity and the presence of an output schema, the description covers the essentials: what it does, the required parameter, and authentication. It omits error handling or irreversibility emphasis, but overall complete enough.

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 baseline is 3. The description adds minimal value beyond the schema by restating the parameter's role and type (MObjectId), but does not provide new semantic context.

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

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

The description clearly states the action (delete), the resource (auto-buy setting), and the identifier (id). It differentiates from sibling tools by specifying 'auto-buy' vs 'auto-sell' or other resources.

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

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

The description provides a prerequisite ('requires a valid signature session and mcp-session-id') but does not indicate when to use this tool versus alternatives like updating or registering a setting. No explicit 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?

No annotations provided, so description carries full burden. Mentions it's an estimation and returns pricing data, implying non-destructive. Could explicitly state read-only nature but does not contradict annotations.

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

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

Two sentences, front-loaded with purpose, each sentence adds value without redundancy. Efficiently communicates core 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 purpose and output fields well but misses parameter explanations and does not mention authentication, rate limits, or other constraints. Adequate for a simple estimation tool but not comprehensive.

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

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

Schema description coverage is only 17%, and the description does not explain input parameters (e.g., receiver, unitPrice, durationSec). It only describes output fields, failing to compensate for low schema coverage.

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

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

The description clearly states the tool estimates buy-resource pricing, returns specific pricing fields, and directs use before order creation tools. It effectively distinguishes from sibling order tools.

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

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

Explicitly says to use before any tronsave_order_create* tool, and guides how to apply the output (choose unitPrice and deposit hints). Provides clear context for when to invoke.

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

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

With no annotations, description warns to store securely and states it returns raw key, but lacks details on regeneration or invalidation of previous keys.

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 concise sentences, structured with no waste, front-loaded with purpose.

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

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

Given an output schema exists, description adequately covers return value (raw key) and security note, though could mention one-time nature.

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 description correctly adds no param info. Baseline 4 for zero parameters.

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

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

The description clearly states the specific verb 'Generate' and resource 'internal API key for the current user', and distinguishes from the sibling tool tronsave_revoke_api_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 tells when to use the generated key (in tronsave_login with apiKey) and mentions it is for internal-tool authentication, though could add more about 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?

Discloses read-only nature, session requirement, and constraints. No annotations provided, so description carries full burden; lacks details on output format but output schema exists.

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

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

Concise and well-structured: purpose first, then guidelines, constraints in bullet points. 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 prerequisites, triggers, and constraints. Output schema exists, so return values need not be described. Missing minor details like error conditions, but sufficient for a simple 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%, baseline 3. Adds value by specifying 'TRX only' constraint not in schema, reinforcing minimum amount from 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 'fetches' and the specific resource 'deposit address for the TronSave internal account', distinguishing it from sibling tools that handle other operations.

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

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

Explicitly states prerequisites (logged-in MCP session from tronsave_login), triggers (user asks for deposit address or top-up), and constraints (TRX only, min 10 TRX, read-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?

No annotations provided, so description carries full burden. It declares 'read-only' and describes the return field, but lacks explicit statements about side-effects (none expected) or auth requirements beyond optional session. Adequate but not exhaustive.

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, concise at two sentences. However, it could be split for readability. 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 no annotations but presence of output schema, description sufficiently covers the tool's behavior. It identifies the GraphQL field and constraints, making it complete for a price query 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%, but description adds context: explains default values, unit semantics (SUN), and requirement that durationSec must match real orders. Provides more meaning than raw 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 is a read-only market quote returning minPrice for given parameters. It distinguishes itself from siblings like tronsave_estimate_buy_resource and tronsave_list_order_books, specifying its unique role.

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

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

Explicit guidance on when to use: for read-only price queries, optionally scoped by address. Recommends pairing with other tools for full buy quotes and order depth, and notes no login required but optional auth forwarding.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return type ('compact order information') and supported types, which adds some value. However, it omits details like whether the operation is read-only, idempotent, requires authentication, or what happens on missing ID. Given the simplicity of a get operation, the transparency is adequate but not exhaustive.

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 concise sentences: first states the core action, second specifies return content and applicable order types. No superfluous words, front-loaded with the essential purpose.

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

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

Given that an output schema exists, the description need not explain return values. It covers the primary purpose, applicable order types, and the identifier. It lacks only minor context like error handling or prerequisites, which makes it very complete for a simple query 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 the schema already defines the 'id' parameter with the same description ('Order id (`MObjectId`).'). The description repeats this information without adding new meaning. Per the rule (coverage >80% baseline 3), the score is 3.

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

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

The description clearly states the action ('Get details'), the resource ('single order'), and the scope ('NORMAL, FAST, and EXTEND order types'), distinguishing it from sibling tools like 'tronsave_list_orders' or 'tronsave_cancel_order'. The verb+resource combination is precise.

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

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

No guidance on when to use this tool versus alternatives. For example, it doesn't mention that for listing multiple orders one should use 'tronsave_list_orders', or that for order creation one should use 'tronsave_create_order_onchain'. The description only states what the tool does, not when to use it.

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

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

No annotations provided; description carries full burden. Only states it's a get operation without disclosing potential side effects, rate limits, or nonce expiration behavior.

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

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

Two sentences, first states purpose, second gives actionable instructions. No wasted words, 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?

For a 0-parameter tool with an output schema, the description covers the entire usage context: what it does, what to do with the result, and which sibling to use next.

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 so no parameter info needed. Description adds value by explaining the purpose and usage 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?

Clearly states the verb 'Get', the resource 'nonce message', and the purpose 'wallet-based authentication'. Distinguishes from sibling by linking to the next step in 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?

Provides explicit instructions: sign client-side and submit in tronsave_login. Lacks explicit when-not-to-use, but the context of authentication flow 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?

No annotations provided; description only states it gets configuration, omitting any behavioral details (e.g., read-only nature, rate limits, required permissions).

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

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

Two efficient sentences with no fluff. Provides essential information in minimal space.

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 what the tool does and a prerequisite. Output schema exists, so return values are not needed. Minor gap: no explicit hint that it's safe/read-only.

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, so baseline 4 applies. Description adds no param info, which is acceptable as none exist.

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

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

Clearly states verb ('Get'), resource ('auto-sell configuration'), and scope ('current authenticated user'). Distinguishes from sibling tools like 'tronsave_register_auto_sell' and 'tronsave_update_auto_sell_setting' as a read operation.

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?

Prerequisite mentioned ('valid signature session and mcp-session-id') but no guidance on when to use this tool vs alternatives, e.g., when to read vs update.

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

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

No annotations are provided, so the description carries the burden. It discloses authentication requirements (signature session, mcp-session-id) and a security warning (no private keys to server). It does not explicitly state read-only nature, but it's implied. Good disclosure for a read operation.

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

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

Two sentences: first states purpose, second provides prerequisites and security warning. No fluff, every sentence earns its place. Well-fronted 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?

For a tool with zero parameters, clear description, and an output schema (not shown but exists), the description is complete. It covers purpose, prerequisites, and security – all needed 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?

Input schema has zero parameters and 100% coverage, so baseline is 4. The description adds value by stating the requirement for an `mcp-session-id` header, which is not a parameter but crucial context. This extra clarity elevates the score.

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

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

Description clearly states the tool retrieves the authenticated user's profile and account settings. It specifies the resource ('user info') and the condition (authenticated). Among sibling tools focused on orders, keys, deposits, etc., this is the only user info tool, so no sibling differentiation needed.

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

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

Description implicitly says when to use: after `tronsave_login` and with a valid `mcp-session-id` header. It also warns against sending private keys. However, it does not explicitly state when not to use or list alternatives, though no alternatives exist for this operation.

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

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

No annotations provided, so description carries full burden. 'Get' implies read-only; mentions authentication requirements. No side effects disclosed, but minimal for a read operation.

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

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

Two sentences, no redundancy. First sentence states purpose and details, second states requirements. Every word necessary.

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, no annotations, and presence of output schema, description adequately covers purpose, requirements, and return semantics.

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% coverage). Description adds value by specifying what is retrieved (permission list and the specific field `autoSettings.permitOperations`).

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

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

Clear verb+resource: 'Get the current authenticated user's enabled permission list' with specific field name. Distinguishes from many sibling tools that deal with orders, settings, etc.

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

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

States prerequisites: 'Requires a valid signature session and `mcp-session-id`.' Does not explicitly exclude alternative tools, 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?

No annotations are provided, so the description carries full burden. It does not disclose whether the operation is read-only, idempotent, or has any side effects, permissions, or rate limits. This is a significant gap for a tool that likely involves fetching data.

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, no fluff, and front-loaded with the core action. However, it could be improved by structuring parameter explanations more clearly.

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 including a complex nested object, and no annotations, the description is incomplete. It lacks behavioral details and parameter semantics, leaving an agent underinformed despite an output schema being present.

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 mentions 'receiver address', which corresponds to the 'receiver' parameter, but does not explain 'requester', 'suggestData' (a complex nested object), or 'resourceType' (which has an enum). With 0% schema description coverage, the description fails to add meaning beyond the raw 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 (get) and resource (extendable delegate candidates) and specifies the context (for a receiver address). However, it does not distinguish from the sibling 'tronsave_internal_list_extendable_delegates', which likely serves 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?

The description provides a usage hint ('Useful when selecting delegates that can be extended for resource operations'), implying when to use it, but no explicit guidance on when not to use it or 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?

With no annotations, the description carries full burden. It only mentions returns but does not disclose if the operation is read-only, side effects, permissions needed, or rate limits. For a market data tool, this is insufficient.

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

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

Single sentence with key information: purpose, resource types, return format, and optional filters. It is efficient but could be structured for better scannability.

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 4 parameters, no annotations, and an output schema, the description is partially complete. It covers main function and filters but omits the address parameter and does not elaborate on filter behavior or output schema structure.

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

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

Schema description coverage is low (25%), but the description adds context for resourceType (ENERGY/BANDWIDTH) and names optional amount and duration filters (mapping to minDelegateAmount and durationSec). However, it does not explain the address parameter or the precise effect of the 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 gets market order book data for ENERGY or BANDWIDTH and specifies return format (price buckets). It implicitly differentiates from sibling tools like tronsave_list_orders by focusing on order books vs. orders.

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

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

No guidance on when to use this tool over alternatives or conditions for optional filters. The description does not mention when to apply amount/duration filters or any 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?

No annotations provided. The description does not disclose if this is a read operation, authentication requirements, rate limits, or data freshness. It implies listing but omits behavioral traits like side effects or scope.

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

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

Single sentence of 16 words is concise but over-truncated. Front-loaded with main action, but lacks structured breakdown or examples. Sacrifices completeness for brevity.

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

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

Given 10 parameters, no annotations, and an output schema, the description is too sparse. Does not cover full filter set, pagination mechanics, or response structure. Incomplete for a complex list 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?

Schema has 10 parameters with 0% description coverage. Description only mentions four filters (resourceType, isOwner, isMatching, sort options) but ignores others like limit, offset, fromId, receivers, isFulfilled, myAddress. Does not add meaning beyond what the schema minimally 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 'Get order history with pagination and common filters', identifying the resource (order history) and key features (pagination, filters). It distinguishes from siblings like tronsave_get_order (single order) and tronsave_create_order (creation). However, it could be more specific about listing vs history.

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

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

No guidance on when to use this tool versus alternatives like tronsave_get_order (for a single order) or tronsave_cancel_order. No context about prerequisites, owner scope, or intended use cases.

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

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

With no annotations provided, the description covers authentication modes, return value (sessionId), and required input format. It does not mention session expiration or error handling, but overall provides good 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?

Single dense paragraph with clear structure: purpose, modes, procedure. 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?

Covers prerequisites, modes, output usage, and required format. Lacks error handling details but is complete for authentication setup. Output schema exists to clarify return structure.

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, but the description adds value by explaining the relationship between apiKey and signature (mutually exclusive modes) and specifying the exact concatenation format for the signature parameter.

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 creates an authenticated server session and returns a sessionId, distinguishing two authentication modes (wallet signature and apiKey). This differentiates it from sibling tools like tronsave_get_sign_message or order-related tools.

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

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

Explicitly describes when to use wallet login (platform tools) vs apiKey login (internal tools), and provides step-by-step instructions for wallet login including prerequisite call, message signing, and required signature format.

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

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

No annotations are provided, so the description must bear all behavioral disclosure. It only states 'Register' without explaining side effects, idempotency, permissions, or what happens if settings already exist. The output schema exists but is not described, leaving agents uninformed about return behavior.

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

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

The description is a single sentence plus a brief note on related tools. It is concise and front-loads the key purpose. However, it could be slightly more structured by separating the usage guidelines into a bullet or separate sentence for 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?

The description covers purpose and usage alternatives, but lacks details on return value, error handling, prerequisites, and behavioral nuances like idempotency. Given the tool's complexity (3 top-level parameters with nested objects) and absence of annotations, the description is incomplete for fully informed 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?

Despite 0% schema description coverage (context signals), the description groups parameters into high-level categories (paymentConfig, poolSetting, addOnFeature) and hints at suboptions (e.g., energy/bandwidth limits, vote, stake, suggestSell). However, it lacks detailed semantics for individual fields, which the schema does provide but is not reflected in the coverage metric. The description adds some meaning but insufficient 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 registers auto-sell settings for the current user, lists the optional parameter groups (paymentConfig, poolSetting, addOnFeature), and distinguishes from siblings by mentioning alternative tools for checking and updating settings.

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 checking current settings with tronsave_user_auto_setting_get before registration, and notes that later changes should use tronsave_update_auto_sell_setting. This provides clear usage guidance and distinguishes when to use this tool vs 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?

No annotations exist; description discloses manual fulfillment and requirement for signed delegate transaction but does not detail side effects, idempotency, or reversibility.

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

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

Two sentences efficiently convey purpose and prerequisite, though could be slightly more streamlined.

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 output schema exists, description covers key behaviors; could mention success/failure indication or permission requirements.

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?

Adds context beyond schema: orderId from listing, signedTx as delegate, and optional paymentAddress purpose.

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 manually fulfills a sell order using orderId and signedTx, distinguishing it from siblings like cancel or create orders.

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

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

Explicitly instructs to call tronsave_order_detail first, providing a prerequisite step for correct usage.

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

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

With no annotations, the description carries full burden. It indicates mutation ('Update') and partial updates ('partial fields'), and advises to read current values first. However, it does not disclose what happens to unspecified fields (assumed unchanged), required permissions, or side effects. Adequate but not comprehensive.

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 (two sentences) and front-loaded with the main purpose. No unnecessary words. However, it could be slightly more informative about the partial update behavior.

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 of the input schema (3 nested objects, many fields), the description is short. It references registration and the get tool for context, but does not explain the output schema or explicitly state that all fields are optional and unchanged fields remain as-is. Partially complete.

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

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

Schema description coverage is 0%, so the description must compensate. It only mentions that the tool supports the same optional inputs as registration and lists parameter names (`paymentConfig`, `poolSetting`, `addOnFeature`), but does not add meaning beyond the schema property names. No details on field types or behaviors are 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 'Update the current user's auto-sell configuration with partial fields', indicating a specific action (update) and resource (auto-sell configuration). It distinguishes from sibling tools like `tronsave_register_auto_sell` (registration) and `tronsave_user_auto_setting_get` (read).

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 advises to read current values with `tronsave_user_auto_setting_get` before submitting partial updates, providing a clear when-to-use guidance. It also mentions that the tool supports the same inputs as registration, linking to a sibling tool. However, it does not explicitly state when not to use this tool.

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

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

With no annotations, the description carries full burden. It indicates mutation ('update') and partial updates, but does not disclose side effects, authorization needs, or merge behavior. The existence of an output schema is not leveraged.

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 concise sentences front-load the main purpose and key features. No unnecessary words; every part 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?

The description covers the essentials: action, target, and partial update capability. Given the presence of an output schema, return values are not needed. However, it could mention that orderId is required and that updates are partial.

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 echoes the schema fields (receiver, newPrice) without adding new meaning beyond what is already in the input schema descriptions.

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

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

The description clearly states the action (update) and resource (existing order by orderId), and explicitly mentions partial updates on fields like receiver and newPrice, distinguishing it from sibling tools for creation, cancellation, or listing.

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

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

The description implies when to use (to update an order), but provides no explicit guidance on when not to use or which alternative sibling tool to choose. No exclusions or context are given.

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