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

With no annotations, the description carries the full burden and does disclose an on-chain state change ('Create') and the return artifact ('transaction hash'). It omits behavioral side conditions such as fee requirements or the need for the account to already exist, so transparency is adequate but not rich.

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?

One sentence, front-loaded action, resource, and output with no filler. Every word 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?

The tool is simple, schema-covered, and the description supplies the output contract (transaction hash), so an agent has the essentials to call it. It could add prerequisites or a note that this submits an on-chain transaction, but these are not required for basic 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?

The input schema already documents all four parameters and the optional limit default, so the baseline is 3. The description adds only the conceptual 'non-native' framing and does not provide extra parameter semantics beyond the schema.

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

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

States a concrete action—'Create a trustline for a non-native Stellar asset'—and closes with the return value. The resource is specific enough to separate it from payment, liquidity, and Soroban siblings.

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 'non-native Stellar asset' qualifier gives a clear condition for when this tool applies and implicitly rules out native-asset cases. It does not explicitly name sibling alternatives or list exclusion cases, so it falls just short of full routing 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 carries the behavioral disclosure burden. It discloses the transformation (decode), the accepted encoding (base64), and the output content (operations and parameters in JSON). It does not mention malformed-input behavior or any validation limits, but for a pure decode operation the core behavior is adequately transparent.

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?

One concise, front-loaded sentence stating the action, input, and output with no filler. Every phrase 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?

For a one-parameter pure transform with no output schema, the description is nearly complete: it names the required input and the return shape. It could add error/edge-case behavior or an example output, but nothing essential for a straightforward decode call 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% and the single parameter xdr is already described as 'Base64 encoded transaction XDR' in the schema. The tool description repeats the same notion without adding format details, defaults, or examples, so it meets the baseline but adds no extra semantic value.

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

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

The description starts with a specific verb ('Decode'), identifies the exact resource ('base64 encoded Stellar transaction XDR'), and states the intended output ('readable JSON format showing operations and parameters'). This clearly separates it from reverse/helper tools such as stellar_xdr_encode and stellar_xdr_guess.

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 input condition is clear – use it when you have a base64 transaction XDR and want JSON – but there is no explicit guidance on where it fits among the related stellar_xdr_* tools (e.g., when to use stellar_xdr_guess instead for unknown XDR, or stellar_xdr_encode for the reverse direction). Usage is therefore implied rather than stated.

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 of behavioral disclosure. It only restates the basic mutation ('deposit') without explaining side effects, signing requirements, slippage protection, pool creation implications, or the nature of the returned transaction/XDR.

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, front-loaded sentence with no filler or redundant wording. It sacrifices depth for brevity, but as far as structure and conciseness, it is 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?

This is a complex operation with 7 required parameters, no annotations, and no output schema. The one-sentence description is not enough for an agent to know prerequisites, how the AMM deposit operation behaves, what the min/max price bounds mean in practice, or what the tool returns.

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

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

Schema description coverage is 100%, so the input schema already documents each parameter. The description adds no parameter-level meaning, such as how minPrice/maxPrice relate to slippage limits or how maxAmountA/maxAmountB constrain the deposit, so a baseline score of 3 is appropriate.

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

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

The description clearly identifies the action ('Deposit liquidity') and the resource ('classic Stellar AMM liquidity pool'). This immediately distinguishes it from the sibling stellar_withdraw_liquidity and other Stellar tools, so an agent can infer its basic 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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention that it is for providing AMM liquidity, when withdrawal would be appropriate, or any conditions such as pool existence or trustline requirements.

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 behavioral burden. It discloses the operation's effect (crediting 10,000 testnet XLM), the network (testnet), and the mechanism (Friendbot), which is sufficient for such a simple tool. It does not mention Friendbot rate limits or behavior for already-funded accounts, but these are not critical for correct invocation.

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?

One sentence with no fluff; the key information—action, network, amount, and mechanism—is presented directly. High information density with zero wasted words.

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

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

For a tool with a single parameter and no output schema, the description plus schema is fully sufficient: an agent knows what to pass, why, and what will happen. There are no hidden complex behaviors or sibling ambiguities.

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 fully documents the one parameter and its format, and schema coverage is 100%. The description adds no additional parameter detail, but none is needed for a single publicKey argument.

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 names a specific action ('Fund'), a specific resource ('Stellar testnet account'), an exact amount (10,000 testnet XLM), and the mechanism (Friendbot). It is unmistakably distinct from all sibling tools, none of which mention funding, Friendbot, or testnet XLM.

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 clearly situates the tool for testnet account funding via Friendbot, so an agent knows the network context. It does not explicitly name alternatives or state when not to use it, but the context is sufficiently clear among the large sibling set.

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, so the description carries the behavioral disclosure burden. 'Fetch' clearly signals a read-only operation, and listing the returned account fields gives useful context about the response content. However, it does not disclose behavior for nonexistent accounts, error responses, or any rate/auth constraints, so the transparency is partial.

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 one compact, front-loaded sentence with no filler words. It states the action, resource, and key output contents efficiently, earning its place entirely.

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

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

For a simple one-parameter read tool, the description is mostly sufficient: it names the key return fields and clearly indicates a non-mutating operation. Since there is no output schema, the field list partially compensates, but it still omits edge-case behavior such as what happens when the account does not exist.

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 covers 100% of the single parameter, publicKey, with its own description, so the baseline is 3. The tool description adds no additional semantic detail about the parameter beyond what the schema already states.

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 ('Fetch') and identifies the resource ('account details') plus concrete elements: balances, signers, flags, and calculated minimum balance. It is clearly distinct from sibling tools like stellar_get_account_history, which focuses on historical data, while this tool returns the account state snapshot.

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

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

The description implies a clear use case—fetch current account state—but provides no explicit guidance about when to choose this tool over siblings or when not to use it. It does not mention alternatives such as stellar_get_account_history for historical queries, so the usage context is mostly inferred.

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 behavioral disclosure burden. It explicitly states 'Fetch' and 'paginated', making read-only behavior and pagination clear. However, it does not describe return shape, ordering, cursor edge cases, or how includeOperations affects the response.

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, front-loaded sentence with no filler. Every word contributes to identifying the action and resource, making it highly scannable for an agent.

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 definition is usable for a straightforward read-only history call, especially since parameters are fully documented. However, with no output schema and no annotations, the description alone does not specify response shape, pagination traversal details, or the effect of includeOperations, leaving moderate gaps.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the input schema. The description's mention of pagination lightly reinforces limit and cursor semantics but adds no new parameter meaning beyond the schema.

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

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

The description uses a specific verb ('Fetch') and a clear resource ('paginated transaction history for a Stellar account'). This differentiates it from sibling tools like stellar_get_account (account state) and stellar_get_transaction_meta (individual transaction metadata).

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 use when an agent needs a Stellar account's transaction history, but it gives no explicit guidance about when to prefer this tool over siblings or when not to use it. Usage context is present only by inference from the name and purpose.

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 of behavioral disclosure. It does state that the tool performs a network fetch and parsing, which is useful. However, it does not mention potential failure modes, the expected domain-to-URL convention, or whether the output is raw TOML or a structured summary. No contradiction 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?

The description is a single focused sentence with no filler. It front-loads the action and immediately explains the purpose, making it easy for an agent to grasp quickly.

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 one-parameter tool with full schema coverage, the description is nearly complete. It conveys the action and the purpose. It could additionally mention the output shape or the standard .well-known/stellar.toml resolution, but the tool is simple enough that an agent can invoke it correctly with the current 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 description coverage is 100%, and the single parameter 'anchorDomain' already has a clear description with an example. The tool description adds no new parameter-level semantics, but the schema alone is sufficient, so a baseline score of 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Fetch and parse the stellar.toml file'. It also states the outcome ('discover SEP support'), which clearly distinguishes this tool from the many Stellar sibling tools focused on transactions, XDR, or specific SEP endpoints.

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 phrase 'to discover SEP support' implies when the tool is useful, but the description does not explicitly say when to use it over alternatives, such as the SEP-specific tools, nor does it state any prerequisites or exclusions. Usage context is present but left to inference.

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, and it does state the basic read behavior and return of a recommended fee. However, it does not disclose what fee statistics are included, the format of the response, or any caveats about reliability or network conditions.

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?

One dense sentence with no filler. The verb, resource, and output are all front-loaded, and every phrase adds meaning.

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 zero-parameter read-only tool, the description is mostly complete: it names the action, the data source, and the return value. It falls slightly short only because there is no output schema and the exact structure of the fee statistics is not described.

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

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

The tool has zero parameters, so the 100% schema coverage is vacuous and there is nothing for the description to add. Baseline for a zero-parameter tool is 4.

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

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

The description uses a specific verb 'Fetch' with a clear resource ('current fee statistics') and states the output ('recommended fee for reliable inclusion'). This clearly distinguishes it from the sibling tools, none of which target fee statistics.

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 is given about when to use this tool versus alternatives. There is no mention of using it before submitting a payment or fee-bump transaction, nor any exclusions. The usage context is only implied by the phrase 'for reliable inclusion.'

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 behavioral disclosure burden. It notably reveals that responses are bounded, include truncation metadata, and may be cached on disk with a TTL. These are meaningful behavioral traits beyond the basic fetch semantics. It could further disclose failure behavior or caching invalidation details, but the provided information is already substantial.

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 filler. The primary purpose and source are front-loaded, followed by the fallback, bound behavior, and caching. Every clause adds value and the length is appropriate for the tool's complexity.

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

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

The description covers the source strategy, fallback behavior, output bounding, truncation metadata, and disk caching. Since there is no output schema, a bit more detail about the response shape or error conditions would improve completeness, but the current description gives an agent enough context to understand the tool's behavior and side effects.

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 both parameters are already documented in the input schema. The description does not add new parameter-level detail beyond reinforcing the truncation concept mentioned in maxXdrCharsPerField. This matches the baseline expectation for high 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 states a specific verb ('Fetch'), a clear resource ('closed ledger header metadata'), and names the primary source (Horizon) with a fallback (Soroban RPC getLedgers). It is clearly distinct from sibling tools like stellar_get_transaction_meta and stellar_get_account, which target different data. The inclusion of the fallback path adds precision without ambiguity.

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

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

The description explains the operational path (Horizon primary, RPC fallback) but does not state when a caller should choose this tool over alternatives. There is no mention of when not to use it, nor any comparison with sibling tools such as stellar_get_transaction_meta. Usage context is only implied by the tool's name and resource type.

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 available, the description carries the behavioral disclosure burden. It indicates the quote is 'indicative,' which usefully communicates that this is a non-binding quote request rather than an executed transaction. However, it does not clarify side effects, prerequisites, expiration, or that this is an off-chain anchor interaction.

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 with no filler. It front-loads the primary action and outcome, making it easy for an agent to parse quickly.

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

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

The description is adequate for a simple quote-request tool with fully documented parameters, but it lacks context about SEP-38's role, whether the quote is off-chain, or what kind of response details to expect. The absence of an output schema increases the burden on the description to explain the return value, and 'rate metadata' is only a partial explanation.

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 parameter semantics are already fully documented in the schema. The tool description itself adds no additional parameter meaning, which is acceptable given the complete 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 states a specific verb and resource: request a SEP-38 indicative quote and return associated rate metadata. This clearly identifies the tool's function and distinguishes it from sibling tools that handle other SEP protocols or Stellar 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?

No explicit guidance is provided about when to use this tool versus alternatives, such as SEP-6, SEP-24, or SEP-31 tools. The only signal is the SEP-38 name itself, which implies but does not state the intended 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?

With no annotations, the description carries the full burden and discloses important behaviors: the primary/fallback fetch path, bounded payloads with truncation metadata, and operation_index behavior conditioned on non-truncation. It does not cover error handling or permission requirements, but the core behavioral traits are transparent enough for an agent to anticipate tool 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 dense sentences convey the tool's purpose, source routing, fallback, truncation behavior, and optional parameter semantics. There is no filler, and the most important information is front-loaded in the first sentence.

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, source behavior, fallback, truncation, and optional operation slicing, which is reasonably complete for a read-only fetch tool with three well-documented parameters. It lacks an explicit output shape, but the XDR payload nature is implied and there is no output schema requiring reconciliation.

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%, establishing a baseline of 3. The description adds meaning beyond the schema by explaining that maxXdrCharsPerField bounds payloads with truncation metadata and that operationIndex slices the decoded TransactionMeta only when not truncated. This provides useful parameter behavior not present in the schema alone.

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

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

The description names a specific verb ('Fetch'), a clear resource ('transaction result / fee metadata XDR'), and a concrete source ('Horizon primary with Soroban RPC getTransaction fallback'). This clearly differentiates it from sibling tools like stellar_get_ledger_meta by focusing on transaction metadata rather than ledger metadata.

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 gives clear usage context: it fetches transaction result/fee metadata, uses Horizon first and falls back to RPC, and optionally slices decoded TransactionMeta by operation index. It does not explicitly name sibling alternatives or exclusion criteria, but the scope is sufficiently clear for selection among the listed 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the tool performs a 'challenge signing flow' but does not explain how the challenge is obtained, what key material is used for signing, whether network calls to the anchor are made, or whether any state changes or security-sensitive actions occur. The description is high-level and omits important operational details.

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 clear sentence with no filler. It front-loads the core action and output, and every word contributes to understanding what the tool does.

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 having only two parameters and full schema coverage, the tool performs a multi-step authentication flow and has no output schema or annotations. The description does not explain prerequisites, failure modes, required credentials, or the nature of the 'flow,' leaving the agent under-informed about how to invoke it correctly in real contexts.

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

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

Schema description coverage is 100%, so the schema already fully documents both parameters. The description adds no additional meaning about 'anchorDomain' or 'publicKey' beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description states a specific action ('Perform SEP-10 challenge signing flow') and a distinct output ('return JWT token'). This clearly identifies the tool as the Stellar SEP-10 authentication flow and distinguishes it from every sibling tool, none of which perform SEP-10 auth or return a JWT.

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 gives no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It does not mention that this tool is for anchor authentication via SEP-10, when it should be preferred over other SEP tools, or what conditions must hold before calling 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, the description must carry the full behavioral burden, but it only restates the HTTP method semantics (GET/PUT) and the destination. It does not disclose side effects of PUT (create vs. update), authentication/token failure behavior, or what the response contains.

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?

One front-loaded sentence with no filler; the operation, resource, and protocol all appear in the first line. It is appropriately sized for a simple HTTP-wrapper tool.

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 schema covers parameter semantics and method constraints, but there is no output schema and no description of the response shape for GET or PUT. For a protocol-specific SEP-12 tool, some guidance on what the caller receives or how the KYC server is reached would round it out.

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

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

Schema description coverage is 100%, so the schema already documents token, method, kycFields, and anchorDomain. The tool description adds no parameter-level meaning beyond what the schema provides, giving the baseline score of 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 names a specific resource (customer KYC data) and the allowed operations (GET or PUT), and pins them to a concrete destination (Anchor's SEP-12 KYC_SERVER). This differentiates it from sibling SEP-6/SEP-24/SEP-31 tools without needing to inspect schemas.

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 context is clear: use this tool whenever a SEP-12 KYC customer endpoint needs to be read or updated. It does not explicitly name alternatives or exclusions, but the protocol and resource are specific enough to guide selection.

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 behavioral burden. It does disclose the main outcome—returning an interactive URL for the user—but it does not mention network interaction with the anchor, required authentication expectation beyond the schema, possible failures, or that no funds move until the user completes the interactive flow.

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 short sentences with no filler. It front-loads the primary action and immediately states the return value, making it easy to scan and understand.

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 four-parameter tool, the description covers the core call and return value, but it lacks usage guidance and behavioral context around prerequisites or side effects. Since there is no output schema and no annotations, a bit more context about the expected flow would make it more self-sufficient.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds no additional parameter-level meaning beyond labeling the operation as interactive, which is an acceptable baseline but not an improvement.

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 and resource: 'Initiate a SEP-24 interactive deposit or withdrawal' and clearly states the key return value, the interactive URL. This distinguishes it from sibling SEP-6, SEP-10, SEP-12, and SEP-38 tools without requiring schema inspection.

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 gives no explicit guidance about when to use this tool versus siblings like stellar_sep6_transfer, or when a non-interactive flow would be more appropriate. Usage context is only implicit through the phrase 'SEP-24 interactive', which is not enough for an agent deciding between protocols.

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 of disclosing behavior, but it only says the tool 'initiates' a payment. It does not disclose that this is a financial/state-changing operation, what side effects occur, what authentication or prerequisite setup is required, or whether any response or asynchronous status is returned.

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 with no filler or repetition. It is efficient, though it errs on the side of under-specification rather than being a model of rich, structured tool documentation.

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 this is a complex SEP-31 payment operation with eight parameters, seven required, a nested fields object, no output schema, and no annotations, the one-line description is not nearly complete enough. An agent is left without critical context about the SEP-31 flow, required SEP-10/SEP-12 prerequisites, expected response behavior, or how this differs from the many related Stellar and SEP tools.

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 input schema already documents all eight parameters and their meanings. The description adds no additional parameter context, such as how senderId/receiverId relate to SEP-12 or how fields carries routing details, keeping this at the baseline for fully covered schemas.

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

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

The description states a specific action ('Initiate...') and resource ('SEP-31 cross-border remittance payment'), making the tool's basic purpose clear. However, it does not explicitly differentiate this from overlapping siblings like stellar_submit_payment or the other SEP flows, so it stops short of full sibling distinction.

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 gives no guidance on when to use this tool versus alternatives such as stellar_submit_payment, stellar_sep6_transfer, or stellar_sep24_interactive. There are no preconditions, exclusions, or routing cues beyond the protocol name itself, so an agent must infer applicability from the tool name.

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 present, so the description carries the full behavioral disclosure burden. 'Initiate' signals an action, but the description does not disclose that this contacts an external anchor, requires a SEP-10 JWT, may be asynchronous, or has side effects on anchor-managed accounts. This is a meaningful gap for a financial transfer 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 focused sentence with no filler. 'Initiate', 'SEP-6', 'programmatic', and 'deposit or withdrawal' all carry relevant information, and the key operation type is 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?

SEP-6 is a complex external-anchor flow with prerequisites (SEP-10 authentication), routing details, and likely asynchronous follow-up, yet the description is only one sentence. It does not mention return behavior, next steps, or when to prefer SEP-6 over the many sibling SEP tools, and there is no output schema to compensate.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters including the type enum and token/auth details. The description adds essentially no parameter-level meaning, but because the schema covers parameters thoroughly, the baseline score of 3 is appropriate.

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

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

The description names a specific verb ('Initiate'), a specific protocol resource ('SEP-6'), and the exact operation scope ('deposit or withdrawal'). 'Programmatic' usefully hints at a non-interactive flow, distinguishing it from siblings like stellar_sep24_interactive without requiring schema inspection.

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 is provided about when to choose SEP-6 versus sibling flows such as SEP-24 interactive, SEP-31 remittance, or SEP-12 onboarding. There are no prerequisites, exclusions, or alternative conditions mentioned, so the agent must infer usage context from the tool name and sibling list.

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?

Without annotations, the description carries the transparency burden. It usefully discloses that the output is unsigned XDR by default and subject to policy, but it does not clarify that no on-chain modification happens until the XDR is signed/submitted, nor what the policy fallback actually returns.

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 short sentences front-load the purpose and then add the key return-mode nuance. There is no filler or redundant restatement of the tool name.

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 core operation and output mode, which is substantial for a builder-style tool, but with no output schema, no annotations, and seven parameters (including a nested signer object) it leaves policy semantics, required sourceAccount context, and post-XDR steps unstated.

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

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

With only 29% schema description coverage, the description's examples partially compensate by grouping signer and threshold/weight parameters. However, homeDomain is never mentioned and 'flags' is referenced without a corresponding schema field, leaving the parameter model incomplete.

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+resource ('Modify account options') and gives concrete examples (adding a signer, setting weights/thresholds). It is distinguishable from sibling payment/trustline tools, though it never names a sibling and mentions 'updating flags' even though no flag parameter appears in the schema.

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 purpose and the unsigned-XDR return imply this is for building a SetOptions operation rather than submitting or decoding, but no explicit when-to-use or alternative-routing guidance is given. The policy qualifier hints at conditional behavior without explaining the condition.

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 of behavioral disclosure. It mentions the two-step action (upload and deploy) and the return values, but it does not disclose that deployment is an on-chain write operation that likely requires fees, funded accounts, or other prerequisites. The description could more transparently note the mutating and potentially irreversible nature of the 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 sentence that front-loads the main action and immediately states key return values. There is no filler or repeated schema information, making it maximally concise and scannable.

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 gives a solid high-level overview and names the return values, which is helpful given there is no output schema. However, for a nontrivial deployment operation, it omits important context such as account prerequisites, fee implications, network requirements, and the effect of the optional salt. The description is adequate but not fully complete for an agent deciding how to invoke this correctly.

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

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

Schema coverage is 100%, so all three parameters are already described in the input schema, including the random salt behavior. The description itself adds no parameter-specific guidance beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states a specific verb and resource: 'Upload WASM and deploy a Soroban smart contract instance.' It also lists the key return values, making it easy to distinguish from sibling tools like stellar_soroban_invoke or stellar_soroban_simulate. No ambiguity about what this tool does.

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 does not explicitly state when to use this tool versus alternatives or when not to use it. However, the combination of the tool name and the action described makes its usage context reasonably clear compared to sibling tools, so the usage guideline is implied rather than missing.

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 of behavioral disclosure. It only says 'Fetch historical events,' which implies a read operation, but it does not disclose return format, pagination behavior, ordering, or whether filters can be combined. The lack of an output schema makes this gap more significant.

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, front-loaded sentence with no filler or redundancy. However, it is so terse that it mostly restates the tool name and does not enrich the definition with behavioral or usage context that would make it more helpful.

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 four parameters, no annotations, and no output schema, a one-sentence description is not complete. It omits what the returned events look like, how pagination works, what the startLedger parameter implies for result ranges, and when to prefer this tool over other data-fetching siblings.

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

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

Schema description coverage is 100%, so all four parameters are already documented with descriptions. The tool description adds no parameter-level nuance beyond the general notion of events emitted by a Soroban smart contract, so it neither helps nor hurts beyond the schema 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 uses a specific verb ('Fetch') and a specific resource ('historical events emitted by a Soroban smart contract'), making the tool's core purpose immediately clear. This resource is distinct from the sibling tools that handle account history, transaction meta, ledger meta, or Soroban state/simulation 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 gives no guidance on when to use this tool versus alternatives such as stellar_soroban_read_state, stellar_get_ledger_meta, or stellar_get_transaction_meta. It also does not mention that startLedger is required or how this tool relates to other Soroban tools, so the agent must infer usage from the schema and tool name.

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 behavioral burden. It discloses that the tool simulates, extracts a footprint, and may submit depending on policy, which is meaningful. However, 'policy allows' is vague, and there is no mention of what happens if policy denies, side effects on network state, or whether any signing or fee handling is performed.

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 focused sentence that wastes no words. The core action (invoke) is front-loaded, and the simulation-to-submission pipeline is conveyed efficiently.

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?

This is a complex blockchain-mutating operation with no output schema and no annotations. The description explains the high-level flow but omits critical details: expected return value, failure modes, policy conditions, fee/signature requirements, and whether the call has on-chain effects. An agent cannot confidently predict the outcome from this description alone.

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 itself adds no parameter meaning beyond the schema, and although args have an enum in the schema, the description does not clarify how args map to contract invocation or how sourceAccount is used beyond simulation.

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 ('Invoke') and resource ('Soroban smart contract'), and describes the multi-step process of simulation, footprint extraction, and submission. It is specific enough to be distinguished from payment and account tools, though it does not explicitly name the closest sibling stellar_soroban_simulate.

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 this is for invoking a contract and submitting to the network, but it does not explicitly explain when to choose this over stellar_soroban_simulate. No guidance is given about prerequisites like funding, signatures, or policy conditions, so an agent must infer the intended use case.

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 disclosure burden. It communicates that this is a ledger read with no transaction simulation, which implies read-only behavior, but it does not mention error behavior, what happens when the key is absent, or whether any network state can change. The core behavior is clear but the transparency is incomplete.

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 front-loaded sentence with no filler. It states the action, resource, and key distinguishing negative in under 20 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?

The input schema is rich and the operation is simple, but there is no output schema and the description does not describe the return value or error cases. For an agent invoking a read tool, knowing what comes back (value shape, ScVal representation, absence handling) would make this more 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 the schema already documents contractId, keyType, keyValue, and durability. The description adds no parameter-level detail beyond the term 'contract data entry', which is acceptable given the schema's 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 states a precise action ('read the state'), a specific resource ('specific contract data entry'), and a direct-from-ledger method, which distinguishes it from transaction simulation. An agent can tell this apart from stellar_soroban_simulate and stellar_soroban_invoke without opening the schema.

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?

'Directly from the ledger without simulating a transaction' gives clear context for when to use this tool instead of simulation-based paths. It does not explicitly name sibling alternatives or state exclusions, but the intended use is strongly implied.

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 behavioral burden and does well by stating the key trait: this is a simulation only and does not submit a transaction. It also tells the agent what to expect from the call: footprint, events, and results.

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 no wasted words. Purpose, outputs, and the critical non-submission behavior are all front-loaded 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?

The description provides enough context for an agent to call the tool correctly: what it does, what it returns conceptually, and what it does not do. Since there is no output schema, a little more detail about result shape could help, but the core calling context is sound.

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

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

Schema description coverage is 100%, with each parameter already meaningfully described in the schema. The description adds no extra parameter-level context, but it does not need to because the schema covers it.

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

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

States a specific verb ('Simulate'), resource ('Soroban smart contract invocation'), and expected outputs ('footprint, events, and results'). The explicit 'Does NOT submit transaction' clearly differentiates it from sibling stellar_soroban_invoke.

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

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

Clearly conveys the tool is for dry-run simulation and explicitly says it does not submit the transaction. It does not name an alternative tool outright, but the non-submission caveat gives strong guidance on when this tool is appropriate.

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 must disclose side effects. It does state 'Submits to the network,' which makes the external network effect explicit and indicates fees will be sponsored. However, it does not describe consequences such as fee deduction, irreversibility, failure behavior, or whether the inner transaction is executed.

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 short sentences with no filler; the key action and network-submission effect are front-loaded. It is an efficient description, though 'Fee Bump Transaction' slightly echoes the tool name.

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 tool has no annotations and no output schema, so the description must carry more context. It omits practical details such as what is returned after submission, whether the sponsor account must be funded, and what errors or prerequisites apply beyond those in the parameter schema.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-level detail beyond the schema, but the schema already explains feeAccount and innerTxXdr clearly, including the signing requirement. maxFee is also documented.

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 and object: 'Sponsor the fees for an existing transaction using a Fee Bump Transaction.' This clearly identifies the action and resource, and distinguishes it from sibling payment/submission tools like stellar_submit_payment by emphasizing fee sponsorship rather than ordinary payment submission.

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

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

The description implies the use case: when you already have a signed inner transaction and want a sponsor to pay its fees. However, it does not explicitly state when not to use this tool, nor does it name alternatives or conditions that would select a different submit path.

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 full burden falls on the description. It discloses that the tool submits a transaction and returns a hash, but it does not mention that this is a state-changing, irreversible action that moves funds, may require signing or authorization, or can fail due to insufficient funds or invalid sequences. Key behavioral traits are missing.

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 tightly written sentence that front-loads the action and states the key return value. There is no redundancy or filler; every part is relevant.

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

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

Given 5 parameters, nested objects, no output schema, and no annotations, the description is too sparse to be complete. It does not explain whether the tool constructs or signs the transaction, what prerequisites exist (e.g., funded account, trustline), how errors are reported, or the format of the returned hash. An agent would have to make many assumptions.

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

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

Schema description coverage is 100%, and the parameters are individually documented (e.g., 'Destination account public key (G...)' and 'Asset descriptor: native or credit with code+issuer'). The description adds no supplementary parameter context, but the schema already carries this information, so a 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 names a specific verb and resource: 'Submit a Stellar payment transaction' and clearly states the primary output ('return the transaction hash'). It distinguishes itself from siblings like stellar_submit_fee_bump_transaction and stellar_create_trustline by focusing specifically on a payment transaction.

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?

There is no guidance about when to use this tool versus alternatives. The description does not mention conditions, exclusions, or related tools such as stellar_submit_fee_bump_transaction or stellar_get_transaction_meta. An agent is left to infer the usage context solely from the tool name and generic wording.

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 of behavioral disclosure. It only states that the tool withdraws liquidity; it does not mention transaction submission, side effects, permissions, reversibility, or what happens after the 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, clear sentence with no wasted words. It is appropriately sized for the purpose and front-loads the core action and object.

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 tool has 7 parameters, no annotations, and no output schema, but the description gives minimal operational context. It does not explain the transaction lifecycle, expected return behavior, or consequences of the withdrawal, leaving notable gaps for an agent.

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

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

Schema description coverage is 100%, and each parameter already has a meaningful description. The tool description adds only the pool context and does not provide additional parameter-level meaning beyond the schema.

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

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

The description uses a specific verb ('Withdraw') and resource ('liquidity from a classic Stellar AMM liquidity pool'). It clearly distinguishes this from the sibling 'stellar_deposit_liquidity' tool and other Stellar 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 gives clear context: use this tool when withdrawing liquidity from a classic Stellar AMM pool. It does not explicitly mention when not to use it or name alternatives, but the context is sufficiently 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 the full behavioral burden. It discloses the input format (JSON), output format (base64 XDR), and the schema relationship, which covers the core behavior of a stateless pure transformation. However, it does not disclose failure modes (invalid type name, JSON failing schema validation) or whether validation is enforced.

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 sentence front-loads the operation and output format, with the roundtrip context cleanly tucked into a parenthetical. Every word earns its place; no wasted text.

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 2-param tool with no output schema and no annotations, the description covers the operation, output format, and companion pipeline tools. Missing are explicit error semantics and a direct pointer that type must come from stellar_xdr_types (though the schema's type description covers this). The inverse tool is only implied as 'decode tools' rather than named.

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 50% (borderline), but the schema itself already provides solid descriptions for both parameters — json documents its string/object variants and JSON.stringify serialization, and type points to stellar_xdr_types with an example. The description adds little beyond echoing 'named type' and 'JSON', so it doesn't compensate for the coverage gap, yet the schema carries that weight adequately.

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?

States a specific verb ('Encode'), the exact transformation (JSON → base64 XDR), and the type-driven mechanism ('for a named type'). The roundtrip reference to decode tools distinguishes it from the sibling stellar_decode_xdr without requiring schema inspection.

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 roundtrip mention ('roundtrip with stellar_xdr_json_schema + decode tools') implies a pipeline workflow, but the description never explicitly says when to choose this tool over stellar_decode_xdr or whether the JSON must first be prepared via stellar_xdr_json_schema. No explicit conditions or exclusions are given.

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 must carry behavioral disclosure. It states the core transform (base64 in → successful types out) and a limitation (not streams), which is transparent. It does not specify the return format, whether all matching types are returned or just the first, or behavior on invalid base64.

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?

One sentence, 14 words, no fluff. The action, input, and core constraint are front-loaded and every clause 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?

For a one-parameter tool with no annotations and no output schema, the description gives the input format and the high-level return concept. Missing the exact return shape (e.g., array of type names) and error behavior, but the tool's simplicity makes this a minor gap.

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

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

Schema coverage is 100%, so the schema already documents the xdr parameter as a single base64 value without a data URL prefix. The description's 'single value only; not streams' reinforces the schema but adds no new semantic information beyond emphasizing the constraint.

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?

States a specific action: given base64 XDR, return which XDR types decode successfully. The 'single value only; not streams' clarifies scope, distinguishing it from any stream-oriented sibling. It also separates it from stellar_decode_xdr, which likely decodes to a known type.

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 clear input constraint ('single value only; not streams') but no explicit when-to-use versus alternatives. An agent can infer it is for unknown XDR types, but there is no mention of using stellar_decode_xdr when the type is already known. No exclusion of alternatives beyond streams.

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 behavior on its own. Saying it 'Returns Draft-7 JSON Schema' makes the read-only, retrieval nature apparent and identifies the output format. It does not discuss error handling for unknown type names, but that is a minor gap for this 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?

One sentence contains the core action, output format, and relationship to a sibling tool. Every word earns its place and the key information is 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 single-parameter, no-output-schema tool, the description is complete: it states what is returned, in what format, and how the result should be used. The parameter's valid values are covered by the schema's reference to stellar_xdr_types.

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

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

Schema description coverage is 100%, and the input schema already describes the single parameter as a Stellar XDR type name with an example. The description adds workflow context but no additional parameter-level meaning, so the baseline of 3 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 uses a specific verb ('Return') and names the exact resource: a Draft-7 JSON Schema for a Stellar XDR type. It also links to stellar_xdr_encode, which helps distinguish it from sibling tools like stellar_xdr_types and stellar_decode_xdr.

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 phrase 'use with stellar_xdr_encode' signals the intended context and workflow. It does not explicitly list exclusions or alternative tools, but for a simple schema-fetching utility this is clear enough.

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 the data source ('bundled XDR JSON engine') and the output nature (a list of type names), which is reasonable for a read-only listing tool. However, it does not explicitly confirm the read-only nature, mention output format details, or address edge cases like empty results or the effect of the prefix filter, leaving some behavioral surface unspecified.

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, front-loaded sentence with no redundant words. It states the action, the object, the purpose, and a useful contextual detail (the bundled engine) in a compact and scannable form.

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

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

For a simple tool with one optional, well-documented parameter and no output schema, the description is largely sufficient: it clearly indicates the tool returns a list of type names. It could be slightly more explicit about the output structure (e.g., an array of strings) and how this list relates to the sibling tool stellar_xdr_json_schema, but these are minor gaps given the low complexity.

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

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

Schema description coverage is 100% because the only parameter, 'prefix', is already documented with its meaning and case-insensitivity. The tool description adds no additional parameter semantics beyond what the schema provides, so the baseline of 3 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 uses a specific verb ('List') with a clear resource ('supported Stellar XDR type names') and an explicit purpose ('for encode/decode/schema'). This distinguishes it from sibling tools like stellar_xdr_encode/decode (which operate on data) and stellar_xdr_json_schema (which returns schemas), making the tool's role immediately identifiable.

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 phrase 'for encode/decode/schema' implies the tool is a registry for discovering valid type names before using related XDR operations. However, it does not explicitly state when to choose this tool over alternatives like stellar_xdr_json_schema, nor does it describe any exclusions or complementary use cases, so the guidance remains implicit rather than explicit.

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