JetForge

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered; the description nonetheless reinforces it with "Sends nothing." It adds genuine behavioral detail the annotations cannot convey: the quote includes a 1% fee, price impact and minimum output, and partialFill/solCharged describe the curve-completion edge case. It stops short of describing the full response shape or staleness/liveness of the on-chain 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?

Three short sentences, front-loaded with what the tool produces and immediately followed by the non-mutating guarantee. Every clause adds information; there is no restatement of the name or title.

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 output schema, the description carries the burden of explaining returns, and it covers the key fields (fee, price impact, minimum output, partialFill, solCharged). It does not enumerate the remaining response fields or note whether the curve price is stale, but it is sufficient for an agent to call the tool correctly.

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

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

Schema description coverage is 100%, including the lamport/token-unit distinction for amount and the default 300 bps for slippageBps, so the schema already carries parameter meaning. The description adds only trade-direction framing (buy vs sell) and nothing about slippage or mint semantics beyond that, matching the baseline-3 expectation when the schema does the heavy lifting.

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

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

States a specific verb and resource: pricing a buy or sell against the token's live on-chain bonding curve, with the 1% fee, price impact and minimum output called out. An agent can tell this computes a quote rather than executing anything. It does not name prepare_trade as the sibling it contrasts with, so sibling differentiation is left implicit.

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?

"Sends nothing" implies this is the pre-trade, quote-only step, which is useful usage context, and the partialFill note explains how to read the result. However, there is no explicit when-to-use vs prepare_trade guidance or stated prerequisite, so the agent must infer the relationship between pricing and preparing a trade.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that both native SOL and SPL tokens are returned for arbitrary wallets, but says nothing about pagination, token-limit behavior, or failure modes for invalid addresses.

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 zero filler, naming the resource and scope immediately.

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 two-parameter read tool with full schema coverage, annotations covering safety, and no output schema, this is nearly complete. A brief note on what the balance response looks like or on the mints filter would close the remaining 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 description coverage is 100%, so both parameters are documented in the schema itself. The description adds no meaning beyond that — notably it never mentions the optional mints filter, which is the one parameter whose behavior (narrowing results) could use extra framing.

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 (get) and precise resources (SOL balance plus SPL token balances) scoped to 'any Solana wallet', which an agent can distinguish from sibling tools like get_quote or prepare_trade. It does not explicitly name siblings, 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 read-only framing ('get ... balances') implies this is the lookup to call when wallet holdings are needed, but there is no explicit when-to-use, when-not-to-use, or pointer to an alternative tool. Usage must be inferred from the sibling names.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral context: the returned fields (live price, reserves, graduation progress on a 0-100 scale) and the active-only filter. It omits any note on result volume or pagination behavior, which keeps it below a 5.

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

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

Two sentences, no filler, and the positive scope is front-loaded before the exclusion. Every clause carries information an agent needs to decide whether to call the 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?

With no output schema, the description usefully compensates by naming the returned fields and the graduation-progress scale. For a simple two-param read tool this is close to complete; the only gap is the absence of any hint about result-set size or how pagination/limit interacts with sorting.

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 'sort' (with its enum and default) and 'limit' (1-200, default 50) are fully documented in the schema. The description adds nothing about either parameter, so the baseline 3 applies; there is no compensating detail such as what 'graduating' sorting actually prioritizes.

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?

Specific verb (List) plus a precisely scoped resource: active JetForge tokens still on their bonding curve. It also states the inverse scope — graduated tokens trade on Raydium and are not listed — so an agent knows exactly what this tool will and won't surface, and it is unmistakable against siblings like get_quote or prepare_trade.

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 exclusion clause ('graduated tokens ... are not listed') gives a clear condition for when this tool is the wrong choice, which is real usage guidance. However, it never names an alternative tool or says when to prefer it over browsing via another path, so it stops short of explicit routing.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds important behavioral detail beyond that: the output is an unsigned base64 legacy-format transaction, no funds move, execution requires signing and broadcasting before lastValidBlockHeight, and private keys must never be sent. This is exactly the kind of operational context an agent needs before invoking a transaction-preparation 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 three tight sentences and front-loads the core action, then the non-execution caveat, then the follow-up signing and broadcast requirement. Every sentence contributes useful information with no filler.

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, so the description must explain the return value, and it does: an unsigned base64 legacy-format transaction plus the lastValidBlockHeight broadcast deadline. Together with the security warning and the read-only annotations, an agent has enough context to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents mint, side, amount, slippageBps, and walletPublicKey including enum and amount-unit details. The description does not add parameter-specific syntax or format guidance 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 and resource: 'Build an UNSIGNED buy or sell transaction (base64, legacy format) for the given wallet.' It also explicitly sets scope by saying the tool does not execute the trade or move funds, which distinguishes it from any execution or broadcast path and from the sibling tools get_quote, get_wallet, and list_markets.

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

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

It clearly says what to do next (sign with the wallet and broadcast before lastValidBlockHeight) and warns never to send a private key, giving practical usage context. It does not explicitly mention when to use this versus calling get_quote first, or any exclusions, so it falls short of a full when/when-not/alternatives statement.

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