TronSave MCP Server

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

No annotations are provided, so the description must disclose behavioral traits. It mentions required sessions but does not explain the outcome of cancellation (e.g., order status changes, refunds, reversibility), leaving significant gaps for a mutation tool.

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, front-loaded with the action, and contains no redundant or extraneous 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?

While the tool has few parameters and an output schema, the description lacks behavioral details about the cancellation's effects, which is important for an action with side effects. The session requirement is noted, but overall completeness is average.

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 100% coverage and already describes the `orderId` parameter sufficiently. The description does not add additional meaning beyond what is in the schema, so baseline 3 is appropriate.

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

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

The description clearly states the action ('Cancel an existing order') and the resource ('by orderId'), distinguishing it from sibling tools like tronsave_create_order_onchain or tronsave_list_orders.

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

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

The description specifies prerequisites ('Requires a valid signature session and mcp-session-id'), guiding when the tool is usable, though it does not explicitly mention alternatives or 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?

No annotations are provided, so the description must bear the full burden. It discloses authentication requirements (signature session) and conditional parameter requirements, but does not describe side effects, error handling, idempotency, or rate limits. 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 three sentences, each adding distinct information: the core action, parameter conditions, and prerequisites. No redundant or extraneous content. Could be slightly more structured with bullet points, but still concise 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 tool's complexity (9 parameters, 7 required, enums) and the presence of an output schema, the description covers key aspects: conditional parameter dependencies, alignment with estimate endpoints, and required session. It does not explain return values (handled by output schema) or ordering constraints, but is largely complete for selection and invocation.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining conditional requirements for paymentSignedTx and paymentPendingRequester, and by advising alignment of orderUnitPrice with estimate results. This goes beyond what the schema provides.

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

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

The description clearly states the action (create order) and the key parameter (paymentMethod) with its variants. It mentions prerequisites but does not explicitly distinguish from sibling tools like tronsave_update_order. Nevertheless, the verb and resource are specific and clear.

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

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

Provides guidance on when to include conditional parameters based on paymentMethod and lists required session context. However, it does not explicitly advise when to use this tool versus alternatives, though the create operation is logically distinct from update or list tools.

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

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

The description says 'permanently' indicating destructive behavior, and mentions required session. However, it lacks details on side effects, failure modes, or whether the action is reversible beyond stating permanence. No annotations are provided to supplement.

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 redundant words, front-loaded with action and resource. Every sentence is 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?

For a simple delete operation with one parameter and an output schema available, the description covers the action, identifier, and prerequisites. It could mention what the response looks like or confirm deletion, but the output schema likely covers that.

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

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

Schema coverage is 100% and the schema description already explains the id parameter. The tool description only reiterates the id format without adding new semantic information beyond what the schema provides.

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

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

The description clearly states the action (Delete), the resource (auto-buy setting), and the identifier (id). It distinguishes itself from sibling tools which cover other operations like create, estimate, get, 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 mentions prerequisites (valid signature session and mcp-session-id), but does not explicitly specify when to use this tool versus alternatives or when not 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?

With no annotations provided, the description must carry the full burden of behavioral disclosure. It states the tool estimates pricing and returns fields, but does not mention whether it is read-only, any side effects, authorization requirements, error handling, or preconditions. This is insufficient for a tool with no 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 two sentences, front-loaded with purpose and return fields, and ends with usage guidance. No wasted words, highly concise.

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

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

Given the complexity (6 parameters, many siblings, no annotations), the description explains the tool's role and connection to order creation but lacks details on parameter meanings, error behavior, and preconditions. With an output schema (not shown), return values are partially covered, but overall completeness is average.

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% (1 of 6 parameters have a description). The description does not explain individual parameter semantics beyond hinting at unitPrice selection. Given low coverage, the description should compensate but fails to provide details for the other 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 tool estimates buy-resource pricing before creating an order, mentions specific returned fields, and names sibling tools (tronsave_order_create*) that it precedes. This distinguishes it from siblings as an estimation tool.

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 using this tool before any tronsave_order_create* tool to choose order_unitPrice and deposit hints. It provides clear context but does not mention alternative estimation tools or 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 that the key is internal and used for authentication, and that the raw key is returned in `data` with a storage warning. No annotations provided, so the description carries the burden; could mention session requirements for this tool itself.

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 front-loaded with purpose, no fluff, each sentence adds necessary 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 no parameters and presence of an output schema, the description covers purpose, return value, and downstream usage. Could mention error cases but sufficient for a simple generation 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 has 0 parameters and 100% coverage, so the description adds value beyond the schema by explaining the return value and usage, earning above baseline.

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

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

The description clearly states 'Generate a new internal API key for the current user' with a specific verb and resource, distinguishing it from sibling tools like 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 the agent to use the key in `tronsave_login` with `apiKey`, and to store it securely. Lacks explicit exclusion scenarios but provides clear practical 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?

With no annotations provided, the description fully covers behavioral traits: it requires a session ID, notes that API keys are not accepted via arguments (server uses cached session key), declares the operation as read-only, and lists constraints (TRX only, min 10 TRX). This exceeds minimal disclosure.

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

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

The description is concise (4-5 sentences) and front-loaded with the purpose. Every sentence adds value: purpose, prerequisite, trigger condition, constraints, and read-only nature. No superfluous content.

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

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

For a tool with one parameter and an output schema, the description is complete. It covers purpose, usage scenario, auth requirements, constraints, and behavior (read-only). It also explains why API keys are not passed as arguments. Nothing essential is missing.

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

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

Schema coverage is 100% with a description for amountTrx. The description adds 'TRX only' and reaffirms the minimum, but these are already implied or stated in the schema. No additional parameter semantics beyond what the schema provides.

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

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

The description clearly states the tool fetches a deposit address for the TronSave internal account. It also specifies the use case (user asks for deposit address or needs to top up TRX balance), distinguishing it from sibling tools which cover orders, login, and 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?

The description explicitly tells when to trigger the tool ('if the user asks for a deposit address or needs to top up their TronSave TRX balance'). It also explains the prerequisite (logged-in MCP session from tronsave_login) and constraints (TRX only, minimum 10 TRX), providing clear guidance on 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?

No annotations provided, but the description fully covers behavior: read-only, does not change chain state, requires session, and does not accept API keys via arguments. Discloses the inner mechanism of forwarding cached API key.

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

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

Three sentences: first states purpose and output, second explains prerequisite and authentication, third gives use case and safety. Efficient and well-structured with no fluff.

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

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

Given no parameters and presence of output schema, the description is complete. It covers purpose, prerequisites, usage, behavioral traits, and hints at output fields (address, balances, deposit address).

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

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

Input schema has zero parameters, so schema coverage is 100% trivially. The description adds no parameter details beyond the schema, but mentions that API keys are not accepted via arguments, which is helpful negative info. Baseline of 4 is appropriate.

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

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

Description clearly states the verb 'Retrieve' and the resource 'internal account profile' with specific data types (wallet/represent address, balances, deposit address). It distinguishes itself from sibling tools by being read-only and session-dependent.

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 session via `tronsave_login` and instructs to include `mcp-session-id`. States when to use ('when the user needs their linked address or balance') and that it is read-only, implying not for order operations.

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 the burden. It states 'Read-only' and 'No login required', but does not detail error handling, rate limits, or behavior for invalid parameters. Still, it adequately discloses the core safety profile and auth requirements.

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. The first front-loads purpose and return format; the second provides auth and usage context. Every sentence is substantive with no 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 output schema exists and tool is simple, description covers input-output mapping, auth, and related tools. It does not explicitly mention defaults for omitted parameters, but schema includes defaults. Overall sufficient for a straightforward 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 baseline is 3. Description adds value by explaining the return unit (SUN per resource unit) and optional address scoping, and links parameters to usage context with related tools. This goes beyond mere repetition of 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 it returns a read-only market quote (minPrice) for given parameters, and explicitly distinguishes from sibling tools by mentioning `tronsave_estimate_buy_resource` and `tronsave_list_order_books`. The verb 'returns' and resource 'minimum price' 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?

Provides explicit guidance: 'No login required', 'optional session forwards auth like tronsave_list_order_books', and recommends using with other tools for full quotes or depth. Clearly indicates when and 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?

The description implies a read-only operation via the verb 'get' and mentions the return format. However, with no annotations provided, it does not disclose potential side effects, authentication requirements, rate limits, or error conditions beyond what is obvious.

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

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

The description is concise with two sentences, front-loading the core action and adding one additional detail about order types. Every sentence earns its place 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?

Given the presence of an output schema, the description does not need to explain return values. It covers the essential purpose and scope. Minor omission: it does not mention prerequisite authentication, but this is likely handled by server-level auth.

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 provides a description for the 'id' parameter. The tool description adds context about which order types are returned (NORMAL, FAST, EXTEND) but does not enhance parameter semantics beyond the schema. With 100% schema coverage, a score of 3 is appropriate.

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

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

The description clearly states the action (Get details), the resource (single order by id), and the return content (compact order information for specific order types). It effectively distinguishes from sibling tools like tronsave_list_orders (list vs single) and tronsave_update_order (update vs 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 implies usage for retrieving a single order but does not explicitly specify when to use this tool versus alternatives (e.g., tronsave_list_orders for multiple orders). No exclusions or context for when not to use are provided.

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 carry the burden. It explains the purpose and usage but does not cover response format or potential side effects, though the tool is simple and read-only in nature.

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 the action and follow-up steps, 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?

Given the tool's simplicity (no parameters, existing output schema), the description adequately covers what the tool does and how it fits in the authentication flow, meeting contextual 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?

The input schema has zero parameters, and schema coverage is trivial (100%). With no parameters, the description naturally adds no extra meaning; baseline 4 applies.

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

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

The description clearly states the tool retrieves a nonce message for wallet authentication, distinguishing it from the sibling tool `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?

It explicitly instructs to sign the message client-side and then call `tronsave_login`, providing clear context on workflow without excluding other uses.

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 required authentication and session context. It does not mention side effects (unlikely for a get) but provides sufficient behavioral context 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?

The description is a single concise sentence, front-loaded with the action and resource. No extraneous words; every part earns its place.

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

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

Given no parameters and an output schema present, the description is largely complete. It lacks mention of edge cases (e.g., not configured) but is adequate for a simple retrieval tool. Slight ambiguity exists between 'User Auto Setting' title and 'auto-sell' 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?

The input schema is empty (0 parameters), so baseline is 4. The description adds meaning by specifying that the tool retrieves the auto-sell configuration for the authenticated user, adding context beyond the empty schema.

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

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

The description clearly states the action ('Get'), the resource ('current authenticated user's auto-sell configuration'), and the specific field ('autoSettings'). It distinguishes itself from sibling tools that register, update, or delete 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 mentions prerequisites (valid signature session and mcp-session-id) but does not explicitly state when to use this tool versus alternatives. However, the context of read-only retrieval versus modify/delete siblings provides implicit 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?

With no annotations, the description carries the full burden. It discloses that wallet signing is client-side and warns against sending private keys. However, it does not describe error behaviors or rate limits, but for a read-only tool with no parameters, the coverage is adequate.

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

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

The description is three sentences, each adding value: action, prerequisites, and security note. It is front-loaded with the primary action. Slightly wordy on headers but still 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?

For a tool with no parameters and an existing output schema, the description covers everything needed: what it does, authentication requirements, and a security warning. It is fully complete for its complexity.

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

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

The input schema has zero parameters, and description coverage is 100% trivially. The baseline is 4, and the description adds no extra param info, 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 explicitly states the tool retrieves the current authenticated user's profile and account settings, providing a specific verb and resource. While it does not differentiate from sibling tools like tronsave_get_order, the context is clear enough.

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

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

The description specifies prerequisites: a valid signature session from tronsave_login and the mcp-session-id header. Although it does not explicitly say when not to use this tool or list alternatives, the guidance is sufficient for a simple get 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?

With no annotations provided, the description carries the full burden. It reveals the authentication requirement and the output field name, but does not disclose behavioral traits like idempotency or rate limits. For a simple get operation, this is acceptable but minimal.

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 unnecessary words. It front-loads the purpose and follows with the key prerequisite, making it efficient and easy to parse.

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 exists, the description adequately covers the purpose and precondition. It could explicitly state no side effects, but the output schema likely handles return values, making it sufficiently 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?

There are no parameters, and the schema coverage is trivially 100%. The description adds value by explaining what the tool returns (the permission list), which goes beyond the empty schema.

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

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

The description clearly states the verb 'Get' and the specific resource 'current authenticated user's enabled permission list', and distinguishes it from sibling tools like get_user_info or get_user_auto_setting by focusing on permissions.

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

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

It explicitly mentions the prerequisite of a valid signature session and mcp-session-id, providing clear context for when to use it. No explicit alternatives or when-not-to-use are given, but the precondition is sufficient for a simple 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 discloses that it 'may commit TRX' and is an internal tool using session-based auth. This adds behavioral context beyond the schema, though it could mention idempotency or error states.

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 concise paragraph with no wasted words. It is front-loaded with the core purpose and efficiently adds necessary context.

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

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

For a 3-parameter tool with an output schema, the description covers purpose, session requirement, step sequence, and potential TRX commit. It lacks detail on return values, but the output schema exists. Error handling could be better, but overall adequate.

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

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

The input schema has 100% description coverage, but the description adds value by stating that extendData should be passed unchanged from the previous tool's response, reinforcing the parameter's 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?

The description clearly states 'Submit an extension request for existing delegated resources on TronSave', with a specific verb and resource. It also distinguishes from sibling tools by stating 'Use as step 2 after internal.extend.delegates' and noting it is an internal tool.

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

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

The description explicitly requires a logged-in session from tronsave_login and positions the tool as step 2 after internal.extend.delegates. It does not provide when-not-to-use or alternatives, but the pipeline 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?

With no annotations provided, the description must disclose behavioral traits. It only states it is a read operation ('Get'), but lacks details on authentication requirements, rate limits, error handling, or what happens if the receiver address is invalid. The minimal disclosure 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?

The description is two sentences and 22 words, containing no fluff or repetition. Every word adds value, making it highly concise.

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

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

Given the tool's complex input schema (nested objects, enums) and the presence of a very similar sibling tool, the description is far too brief. It does not explain the meaning of parameters, the suggestData structure, or how this tool differs from its twin, leaving the agent with incomplete context for correct invocation.

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

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

Schema description coverage is 0%, meaning no parameter descriptions exist in the schema. The tool's description does not compensate: it fails to explain any of the four parameters (e.g., 'receiver', 'requester', 'suggestData', 'resourceType'), leaving the agent without guidance on how to set them, especially the complex nested 'suggestData' object.

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 'Get' and the resource 'extendable delegate candidates for a receiver address', providing a specific purpose. However, it does not distinguish this tool from the sibling 'tronsave_internal_list_extendable_delegates', which appears to have an identical name and likely similar function.

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

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

The description implies usage is for selecting delegates for resource operations, but it does not explicitly state when to use this tool versus other sibling tools, nor does it mention prerequisites or conditions for 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?

No annotations are provided, so the description must disclose all behavioral traits. It mentions the return structure and optional filters but omits critical details like read-only nature, authorization requirements, rate limits, or side effects. The description is insufficient for an agent to understand the tool's full 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 concise sentences: first states purpose and primary output, second adds optional filters. No extraneous information, front-loaded with core functionality.

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 (though not shown), the description covers the basics of what the tool returns and its filters. However, it lacks context on pagination, ordering, error handling, or typical usage scenarios, making it adequate 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?

Only 25% of schema properties have descriptions (resourceType with enum). The description adds that 'optional amount and duration filters' are supported, corresponding to minDelegateAmount and durationSec, but does not explicitly map to schema fields or explain address. This provides some added value beyond the schema but leaves ambiguity.

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

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

The description clearly states the tool retrieves market order book data for ENERGY or BANDWIDTH and specifies the return format (price buckets with min, max, value). This distinguishes it from sibling tools like tronsave_list_orders and tronsave_get_order, which deal with orders rather than order books.

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

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

The description implies the tool is for fetching order books, and sibling names hint at different operations, but no explicit guidance on when to use this vs. alternatives is provided. The agent must infer context from tool names.

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 for behavioral disclosure. It mentions pagination but does not specify read-only semantics, authentication needs, rate limits, or potential large result sets. Lacks critical safety context for a list endpoint.

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?

A single efficient sentence with no redundant words. However, it could be more structured or enumerated to improve scanability. Still, brevity is a strength.

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 an output schema, the description lacks completeness for a 10-parameter tool with no schema descriptions. Key filters and pagination mechanics are unexplained, leaving agents to infer or guess. Incomplete for effective use.

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 explain parameters. It names only 4 out of 10 parameters (resourceType, isOwner, isMatching, sort options) while omitting explanation for limit, offset, fromId, myAddress, receivers, isFulfilled, and the structure of sortFilterBy. Partial coverage fails to make the tool usable.

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 'Get order history' which is a specific verb and resource. Differentiates from sibling tools like tronsave_get_order (singular) by indicating list retrieval. Includes pagination and filter hints, making purpose unambiguous.

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

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

Implies usage for listing orders through its description, but provides no explicit guidance on when to use this tool versus alternatives (e.g., get_order for a single order, list_order_books for different data). No exclusion criteria or prerequisites mentioned.

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 details the prerequisite call, exact parameter format, and sessionId return. It does not mention rate limits or session expiry, but for a login tool this is adequate.

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

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

The description is a single paragraph of about 5 sentences, front-loaded with the main purpose. While clear, it could be slightly more condensed or structured, but it is not 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 the tool's simplicity and existence of an output schema, the description fully covers the authentication flow, prerequisites, and usage modes. No gaps remain for effective agent invocation.

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

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

Schema coverage is 100% so baseline is 3; the description adds value by explaining the exact format for signature (signature_timestamp) and that timestamp is the nonce, and that apiKey is for internal tools. This goes beyond the basic 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 it creates an authenticated server session and returns a sessionId. It distinguishes two login modes (wallet signature and apiKey), and is distinct from sibling tools which are all operational or management tools.

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

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

The description explicitly states when to use each mode: wallet signature for platform tools, apiKey for internal tools. It also provides a step-by-step protocol (call tronsave_get_sign_message first). However, it does not explicitly exclude incorrect usage scenarios or mention alternatives beyond the two modes.

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

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

No annotations are provided, so the description must fully disclose behavior. It only says 'Register auto-sell settings' without mentioning side effects, whether it overwrites existing settings, authentication requirements, or rate limits. This is insufficient for a mutation tool.

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 consists of two sentences, no wasted words. The first sentence states purpose and lists parameter groups; the second provides usage guidance. It is front-loaded and efficient.

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

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

Given the complexity (3 nested parameters, no schema descriptions, no annotations) and the existence of an output schema, the description covers purpose and usage but omits behavioral details like idempotency. It mentions checking current settings and using an update tool, which hints at behavior, but is not fully 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 lists the three optional parameter groups (paymentConfig, poolSetting, addOnFeature) with brief notes like 'energy/bandwidth limits and reclaim' and 'vote, stake, suggestSell'. This adds context but lacks detail on nested fields. It is adequate but not rich.

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 'Register auto-sell settings for the current user' which is a specific verb and resource. It distinguishes itself from sibling tools like tronsave_update_auto_sell_setting and tronsave_user_auto_setting_get by mentioning them.

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

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

Explicit guidance is given: 'Check current settings with tronsave_user_auto_setting_get; use tronsave_update_auto_sell_setting for later changes.' This clearly indicates when to use this tool (first-time registration) and when not to (for updates).

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 behavioral disclosure. It states the immediate effect, that existing sessions stop, and the need to regenerate and re-login. This fully discloses the tool's impact and required post-actions.

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 consists of two concise sentences, front-loading the core purpose. 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 zero parameters, no annotations, and the presence of an output schema, the description sufficiently covers the tool's behavior, consequences, and follow-up steps. It is complete for a revoke action.

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

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

The input schema has zero parameters, so schema coverage is 100%. Per guidelines, baseline is 4. The description does not need to add parameter meaning, and none is required.

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

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

The description uses a specific verb ('revoke') and resource ('current internal API key'), clearly stating the action and target. It distinguishes from sibling tools like tronsave_generate_api_key, which performs the opposite 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?

The description explains consequences (sessions stop working) and next steps (generate new key and login), providing clear usage context. It doesn't explicitly list alternatives or when not to use, but the consequences and required follow-up are evident.

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. Discloses that it requires a signed delegate transaction and manual action, but does not detail error handling, side effects, or security implications.

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 purpose, second gives actionable prerequisite. No superfluous 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?

Output schema exists, so return values are covered elsewhere. However, missing critical guidance on how to obtain signedTx (e.g., via tronsave_get_sign_message) and what exactly 'manual' entails, leaving gaps for a less experienced agent.

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

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

Schema description coverage is 100% (all params documented). Description adds context by restating the prerequisite for orderId and specifying 'signed delegate transaction' for signedTx, which is marginally more specific than 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?

Clearly states 'Manually fulfill a sell order' with specific resources (orderId, signedTx). Does not explicitly differentiate from sibling tools like tronsave_cancel_order or tronsave_create_order_onchain, but the action is unique.

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 a prerequisite (call tronsave_order_detail first) but offers no guidance on when to use this tool versus alternatives, nor what conditions warrant manual fulfillment.

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 the description carries the burden. It mentions partial fields and same inputs as registration, but lacks details on merge behavior, permissions, or idempotency.

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

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

Two sentences, front-loaded with action and scope, 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 3 complex nested parameters, no annotations, and an output schema, the description fails to explain behavior (merge/overwrite) or return values, leaving significant gaps.

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

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

Schema description coverage is 0%, and the description only names the top-level parameters without adding meaning beyond their names.

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 ('auto-sell configuration'), and distinguishes from the registration tool by specifying 'partial fields'.

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 read current values with a sibling tool before partial updates, implying when to use this tool and providing an alternative.

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 carry behavioral disclosure. It mentions 'update' implying a write operation, but does not specify side effects (e.g., whether the update is idempotent, what happens if orderId is invalid, or any authentication requirements). The description is too brief to fully disclose 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, well-structured sentence that front-loads the action and key details. Every word is necessary, and there is 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?

With an output schema present, the description does not need to explain return values. It adequately covers the core purpose and parameter roles for a simple mutation tool. However, it could provide more context on behavioral outcomes (e.g., success/error handling) to be fully 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 100%, so baseline is 3. The description adds value by naming specific parameters (receiver and newPrice) and clarifying they support partial updates, which groups them meaningfully beyond the schema's individual 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 it updates an existing order by orderId, and mentions partial updates on specific fields (receiver, newPrice). This distinguishes it from sibling tools like tronsave_cancel_order (cancel) and tronsave_create_order_onchain (create).

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

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

The description indicates the tool is for updating existing orders and supports partial updates, but does not provide explicit guidance on when not to use it or suggest alternative tools for other operations. It lacks exclusions or context about prerequisites.

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