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

There are no annotations, so the description carries the disclosure burden. It conveys a read-only lookup and previews the response categories, but it does not disclose potential errors, authentication needs, or other behavioral traits. For a simple read operation, this is adequate 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 a single efficient sentence that front-loads the operation and adds a scoped list of returned details. There is no filler, no repetition of schema content, and every word contributes 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 tool with one well-documented parameter and no output schema, the description covers the main purpose and key return fields enough to select and invoke the tool correctly. It is not exhaustive about response structure or edge cases, but the low complexity makes it minimally 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?

The input schema already describes accountId as a Stellar account ID (G... address) with 100% coverage. The description adds no additional parameter-level meaning beyond the schema, so the baseline score 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 ('Get') and resource ('Stellar account details') and names concrete returned content ('balances, thresholds, and signers'). Within the sibling tool set, the 'account' resource is unique, so the purpose is clearly differentiated from tools like getTransactions or getEffects.

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 'when to use' or 'when not to use' guidance is provided, and no alternatives are mentioned. The usage context is implied by the tool's clear purpose, but the description does not actively guide selection beyond that.

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. 'Get' clearly signals a read-only operation, and the listed result fields communicate what the caller can expect. However, it does not disclose error behavior, authentication requirements, or response formatting.

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 with no filler, front-loaded with the action and resource. It is concise, scannable, and 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?

For a simple read-only tool with two parameters and full schema coverage, the description and schema together provide enough context to select and invoke the tool correctly. An explicit output schema or error details would make it 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 both assetCode and assetIssuer are already documented at the schema level. The description adds no deeper parameter semantics; its mention of supply, accounts, and flags describes output content rather than input behavior.

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 and resource: 'Get metadata for a Stellar asset' and lists the content categories (supply, accounts, flags). This makes the tool's purpose immediately distinguishable from the sibling account/transaction/orderbook 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 gives clear context for when to use the tool: when asset metadata such as supply, accounts, and flags is needed. It does not explicitly name alternatives or exclusions, so it stops short of a 5, but the resource-focused scope leaves little ambiguity.

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 'Get', which weakly implies a read-only operation, but does not mention filtering behavior, default limit, pagination, whether the account is a required implicit context, or what the response contains. This is a minimal behavioral description with significant gaps.

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 fluff, making it easy to quickly parse. It is appropriately concise for a simple tool, though the vague 'for a Stellar account' phrasing slightly reduces precision.

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 three optional parameters and no output schema or annotations, the description is too thin to be complete. The most important missing piece is how the target Stellar account is identified, since no account parameter exists in the schema. The description also fails to mention expected result structure or any default behaviors.

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 without additional parameter details. The description adds no parameter-specific meaning, and it even introduces a 'Stellar account' concept not present in the schema, which could confuse an agent about how to specify the account. Still, the schema itself documents all parameters clearly.

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: 'Get claimable balances' for a Stellar account. This clearly distinguishes it from sibling tools like getAccount, getTransactions, and getPayments, which target different Stellar resources. The slight ambiguity about how the account is selected prevents a higher score.

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 indication of when to use this tool versus alternatives such as getAccount or getPayments. There is no mention of scenarios, exclusions, or conditions that would guide an agent toward or away from this tool. The context signals show many sibling tools, but the description offers no differentiation guidance.

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

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

No annotations are provided, so the description carries the full burden. 'Get' implies read-only, but the description does not disclose pagination, sorting, the meaning of 'recent', or the return structure. It adds little beyond what the tool name already implies.

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. It is concise and clear, though it misses the opportunity to add routing or behavioral context in the same space.

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

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

With a simple read tool, two documented parameters, and no output schema, the description is minimally viable: it tells the agent what to get and for whom. However, the absence of annotations and output schema means an agent must rely on domain knowledge for return format and selection context, leaving clear 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%, with both accountId and limit having clear descriptions including format and range. The description itself does not add parameter semantics beyond the schema, which matches the baseline for high 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 ('Get'), resource ('recent effects'), and scope ('for a Stellar account'). It is clear and distinct from the tool name, but it does not explicitly differentiate from sibling tools like getOperations or getTransactions, so it stops short of a 5.

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 on when to use this tool versus alternatives. It only says 'Get recent effects for a Stellar account' with no context about when effects are preferable to operations, transactions, or payments, and no exclusions or alternative references 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 carries the full burden of behavioral disclosure. It only says 'Get details' and does not disclose side effects, authentication requirements, rate limits, error behavior, or what fields are included in the returned details. The read-only nature is inferable from the verb but not explicitly stated.

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 with no filler, redundancies, or repeated schema content. It front-loads the action and resource while keeping the whole definition minimal and easy to scan.

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 read tool, the description and schema together make the basic invocation clear. However, because there is no output schema and no annotations, the description leaves unspecified what 'details' contains and what the response looks like, which is a meaningful gap for an agent deciding how to use the result.

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 schema already explains that 'sequence' is the ledger sequence number and that it defaults to latest. The description adds the context of targeting a specific ledger but does not add meaning beyond what the schema already 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 states a clear verb and resource: 'Get details of a specific Stellar ledger by sequence number.' It is not a tautology and the target resource is unambiguous. However, 'details' is somewhat vague and the description does not explicitly differentiate this tool from siblings like getAccount or getTransactions.

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 on when to use this tool versus alternatives, and no exclusions or fallback tools are mentioned. The only implicit usage signal is that the caller wants a specific ledger by sequence number, but no context is provided about choosing getLedger over the sibling 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?

There are no annotations, so the description carries the full burden for behavioral disclosure, but it only says 'Get Stellar liquidity pools.' It does not mention auth requirements, rate limits, pagination behavior, or what the response contains beyond the schema.

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 words. It could add context, but as a minimal statement it is concise and immediately readable.

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

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

With no annotations and no output schema, the description leaves the return structure, pagination behavior, and the meaning of the account filter to the schema alone. An agent can identify the resource but gets little context about what a successful call provides or how the response is shaped.

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% for both limit and account, so the schema already explains the parameter semantics. The description adds no extra parameter detail but does not need to 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 clear verb and resource ('Get Stellar liquidity pools'), so an agent can tell what object the tool operates on. However, it does not distinguish this from sibling getters like getOrderbook or getOffers, so it stops short of full differentiation.

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 use this tool versus sibling tools such as getOrderbook, getOffers, or getTradeAggregations. There are no exclusions, prerequisites, or alternative routing cues.

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 at all, the description must carry the behavioral burden. It discloses the payment/cost behavior ('free — no payment required') and the read-only nature implied by 'Get', but it does not clarify what the returned status contains or any rate limits/error 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?

A single compact sentence with no filler; the parenthetical payment clarification is short and materially useful. Everything in the description 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 parameterless status check, invocation is simple, but there is no output schema and the description does not explain what 'network status' includes (e.g., latest ledger, connectivity, health). An agent can call the tool without ambiguity, but it cannot predict or interpret the response with confidence.

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 properties, so there are no parameters for the description to explain and schema coverage is trivially complete. This matches the 0-parameter baseline, and no additional parameter detail is needed.

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?

Names a specific resource ('Stellar network status') and a clear read verb ('Get'), which sets it apart from sibling tools that target accounts, ledgers, trades, and so on. The phrase 'network status' is still a bit underspecified—it does not define what facets are reported—so it stops short of a 5.

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 checking Stellar network status and adds the cost-relevant hint that it is free, but it never says when to prefer it over siblings or mentions any exclusion conditions. Context is present, but explicit selection guidance is absent.

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?

There are no annotations, so the description carries the transparency burden. It adds behavioral context by restricting results to 'open' offers rather than all offer history, but it does not describe pagination, ordering, error conditions, or explicitly confirm that the operation has no side effects beyond the verb 'Get'.

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. It names the operation and the scope in eight words, so 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?

For a simple read tool with one required parameter and full schema coverage, the description gives enough information for an agent to select and invoke it. An output schema or a note about response shape would improve completeness, but the core resource and scope are clear.

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?

Both parameters are already fully described in the input schema, with 100% schema description coverage. The description does not need to add parameter details; it simply aligns with the accountId parameter by mentioning 'a Stellar account'.

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 the specific verb 'Get' and names the resource 'open DEX offers' scoped to a Stellar account. It clearly communicates what is returned and is enough to distinguish it from sibling tools like getOrderbook or getTransactions.

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 when-to-use or when-not-to-use guidance is given, and no alternative tool is named. The phrase 'for a Stellar account' implies this is the account-level offers tool, but an agent is left to infer the exact fit from the 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get recent operations,' which implies a read operation but doesn't mention ordering (e.g., newest first), pagination, potential empty results, or any side effects. The description adds little beyond what the tool name already implies.

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, concise sentence that immediately states the action and target. There is zero wasted text, and the essential 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 low-complexity tool with only two parameters, no output schema, and no nested objects, the description is mostly sufficient. It could mention that returned operations are ordered by recency, or clarify 'operations' in the Stellar sense, but these are minor omissions that don't prevent 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 100%: both accountId and limit are described in the schema, including the default and range for limit. The description adds no extra meaning beyond the schema, so the baseline 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 ('Get'), a clear resource ('operations'), and a scope ('recent... for a Stellar account'). It clearly states what the tool does. It doesn't explicitly contrast with sibling tools like getTransactions or getPayments, but 'operations' is a distinct Stellar resource, so the purpose is sufficiently 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?

There is no guidance about when to use this tool versus its siblings. It doesn't mention that operations are distinct from transactions, payments, effects, or offers, nor does it specify any conditions that would make this tool the right choice. The context is implied but no alternatives 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 provided, the description carries the full behavioral disclosure burden. It does convey that this is a read operation ('Get') and mentions derived outputs (spread, midprice), which is helpful. However, it does not describe response shape beyond those values, level depth, pagination, or error 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 one tight sentence that front-loads the action and resource, then appends the distinguishing computed values. Every word adds value and there is no repetition of schema-only 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?

For a simple read-only tool with fully described parameters, the description is largely sufficient: it names the orderbook resource and the important computed fields. There is no output schema, so mentioning spread and midprice is valuable, though it could be stronger by explicitly noting bids/asks or routing to sibling 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?

The input schema already documents all three parameters, including formats for sellingAsset and buyingAsset and the range/default for limit. The description adds no parameter-specific detail, so the baseline score 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 ('Get') and names a concrete resource ('Stellar DEX orderbook') plus the key computed outputs ('spread and midprice'). It is clearly distinguishable from sibling tools like getOffers or getPrice, since it identifies the orderbook and its derived metrics.

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 that this tool should be used when an orderbook for a Stellar asset pair is needed, but it does not explicitly state when to prefer it over alternatives such as getOffers or getPrice. There are no exclusions or alternative routing hints.

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 present, the description must disclose behavioral context on its own, but it only states 'Get recent payments'. It does not describe ordering, pagination, cursor handling, response shape, or whether the result includes both sent and received payments.

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-loded sentence with no filler words. It conveys the action and target resource clearly while remaining appropriately brief for a simple read endpoint.

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?

Without annotations or an output schema, the definition lacks important context such as pagination behavior, response contents, and relationship to transactions/operations/effects. An agent would need to inspect the API docs to call this tool correctly in non-triival cases.

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, documenting accountId and limit with default/bounds. The description adds only the word 'recent,' which suggests recency ordering but does not explain how that interacts with limit or how to page further back.

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 ('Get') and resource ('recent payments for a Stellar account'), so the core purpose is immediately understandable. However, it does not distinguish payments from sibling tools like getTransactions or getOperations, which likely overlap in a Stellar API context.

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 getPayments over related endpoints such as getTransactions, getOperations, or getEffects. The description only implies 'use this for recent payments' without exclusions or mention of pagination/alternatives.

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

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

With no annotations, the description carries the full burden, and it only reveals that the price comes from 'SDEX orderbook or recent trades'. It does not clarify whether the orderbook or trades take precedence, whether the returned price is a midpoint, best bid/ask, last trade, or how stale the data might be. This ambiguity materially affects how an agent should interpret and use the price.

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, information-dense sentence with no filler. The core purpose is front-loaded, and the data-source qualifier adds useful scope without extra length.

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?

There is no output schema, no annotations, and no guidance on return value shape, freshness, or source precedence. While the two parameters are well documented, an agent calling this tool cannot confidently predict what the price value represents or how to compare it with related tools like getVWAP. The description is sufficient for tool selection but incomplete for reliable invocation and result interpretation.

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 both parameters fully with concise formats and examples ('XLM' or 'CODE:ISSUER'), so the description adds no extra parameter semantics beyond labeling them as an asset pair. With 100% schema description coverage, 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 operation ('Get the current price'), a clear resource ('Stellar asset pair'), and a data source ('SDEX orderbook or recent trades'). It does not explicitly differentiate from siblings like getPriceHistory or getVWAP, but the emphasis on 'current' establishes a spot-price purpose that is reasonably distinguishable.

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

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

The description implies when to use this tool — when a current price for an asset pair is needed — but it does not explicitly state when not to use it or mention alternatives such as getPriceHistory, getVWAP, or getOrderbook. The 'current price' phrasing provides context, but the guidance is 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.

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 usefully reveals that the OHLC candles are derived from SDEX trade aggregations, but it does not explain aggregation specifics, empty-result behavior, or response expectations beyond the 'OHLC' term.

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 with no filler; it front-loads the verb and object, and it adds the valuable SDEX context without repeating schema details. 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?

For a four-parameter read tool with fully described schema parameters, this is a functional description. However, with no output schema and no annotations, it still leaves the agent without clear expectations for the output shape, candle ordering, or edge cases like sparse/no trade data.

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 already have meaningful descriptions. The tool description adds no parameter-level nuance 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 verb ('Get') and a concrete resource ('OHLC price history for a Stellar asset pair'), and it identifies the data source ('SDEX trade aggregations'). The 'OHLC history' wording helps distinguish this from sibling tools like getPrice and getTradeAggregations, even though no sibling is explicitly named.

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 explicit guidance on when to use this tool versus getPrice, getVWAP, or getTradeAggregations. The phrase 'OHLC price history' implies a charting/historical use case, but an agent is left to infer the right choice among several closely related price and trade 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. It does disclose the configuration prerequisite and the conditional balance-fetching behavior when acountId is provided. But it does not explain what happens if SOROBAN_RPC_URL is absent, error behavior, or that it is a read-only network call, though 'Get' implies a read.

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. It front-loads the core purpose and immediately provides the essential prerequisite. Every sentence carries useful information and the structure is optimal for quick scanning.

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 low-complexity tool with two params and no output schema, the description is mostly complete: it names the return fields (symbol, name, decimals), explains the optional balance behavior, and states the runtime requirement. It omits minor details like error cases or balance units, but these are not critical for an agent to call it correctly.

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

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

The input schema already describes both parameters precisely, including formats and optionality, so schema coverage is effectively 100%. The description adds limited semantic value beyond that, merely restating the balance behavior already noted in acountId's description. 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 states a specific verb ('Get'), a clear resource ('SEP-41 Soroban token metadata'), and lists the exact fields (symbol, name, decimals). It also clearly distinguishes itself from sibling tools like getAccount or getAssetInfo by its explicit focus on Soroban tokens, so an agent can identify it unambiguously.

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 when SEP-41 Soroban token metadata or a balance is needed, and it gives a clear prerequisite ('Requires SOROBAN_RPC_URL to be configured'). However, it does not explicitly mention when not to use this tool or name alternatives such as getAssetInfo for non-Soroban assets, leaving usage guidance 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 provided, the description carries the full behavioral burden, but it only states what data are returned. It does not disclose response shape, ordering, pagination, resolution handling quirks, or Stellar-specific behaviors; 'Get' hints at a read operation but little else.

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 focused sentence with no redundancy. The two most important qualifiers, 'OHLC' and 'Stellar DEX asset pair', appear front-loaded, making the tool's purpose immediately visible.

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 output schema, the description does state the core output concept ('OHLC trade aggregation data') and the schema covers all invocation parameters. It is short of richer return-shape or timing details, but the plain read mission plus complete parameter schema is enough to call it correctly.

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

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

Schema description coverage is 100%, and the schema already documents each parameter, including asset formats, default/maximum limit, and the resolution enum. The description adds no parameter-level meaning beyond the OHLC/candle framing already present in 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 ('Get') and a specific resource ('OHLC trade aggregation data for a Stellar DEX asset pair'), making the tool's output unmistakable. The OHLC qualifier also separates it from sibling price tools like getPrice/getVWAP without needing an explicit comparison.

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 siblings such as getPriceHistory, getVWAP, or getPrice. An agent must infer selection from the tool name and context rather than from explicit usage instructions.

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. 'Get' implies a read-only operation, but it does not disclose ordering, pagination, error behavior, or potential rate limits. The behavior is straightforward but not fully transparent regarding expected output or edge cases.

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 is clear and front-loaded, with no extraneous content. It is appropriately sized for the tool's simplicity.

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 two-parameter getter with a complete schema, the description is mostly sufficient. However, it lacks guidance on distinguishing this tool from overlapping siblings and does not mention return format or ordering, leaving some ambiguity for correct invocation in a broader context.

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%: both accountId and limit are described in the schema. The description adds no additional parameter semantics beyond what the schema already states, 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 tool as retrieving recent transactions for a Stellar account, with a specific verb and resource. It distinguishes from most siblings by naming 'transactions', but does not explicitly contrast with getPayments or getOperations, which could overlap.

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 on when to use this tool versus alternatives like getPayments or getOperations. No context about use cases, prerequisites, or conditions is provided, leaving the agent to infer from the name alone.

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 behavioral transparency burden. It usefully discloses the data source ('from SDEX trade aggregations') and implies a read-only operation through 'Get'. However, it does not explain output behavior, how limit/resolution affect results, or any edge cases.

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 conveys the core purpose without filler or redundant repetition of the schema. Every word contributes to understanding.

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 parameters well, and the description gives the essential purpose. However, with no output schema and no annotation, the return shape is undocumented, and it is unclear whether the tool returns a single VWAP value or a series. This is a notable gap for a tool with multiple aggregation parameters.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds no additional parameter semantics beyond what is already present in the input 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 identifies the operation: 'Get volume-weighted average price for a Stellar asset pair from SDEX trade aggregations'. It names a specific verb, resource, and data source, and the VWAP concept distinguishes it from siblings like getPrice and getTradeAggregations.

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

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

The description implies when to use the tool — when a volume-weighted average price is needed — but it does not explicitly state alternatives or provide exclusion criteria. It does not point to sibling tools like getPrice or getTradeAggregations for other price-related needs.

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