wallet

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

The readOnlyHint annotation already communicates that the operation is safe. The description adds only static content descriptors (balances, muse keys, budget) rather than behavioral details such as side effects, authentication requirements, rate limits, or how the information is returned. It does not contradict the annotation.

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 extremely brief, a single noun phrase with a colon-separated list. Every word contributes to defining the resource, there is no filler. It is arguably under-specified, but from a pure conciseness standpoint it is efficient.

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

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

For a tool with one required parameter, no output schema, and no parameter documentation, the description is too thin. It tells the agent what an account is in the abstract but not how to call the tool meaningfully, what the response shape is, or what scenarios call for it. The readOnlyHint covers safety but not operational completeness.

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

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

Schema description coverage is 0%, and the description does not mention the address parameter at all. An agent gets no guidance on what address means, its expected format, or how it relates to the account contents, leaving the schema's bare string type as the only information.

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 identifies the resource as a MetaMuse account and enumerates its contents: balances, registered muse keys, and budget left. It is clear enough to infer the tool retrieves an account summary, though it lacks an explicit verb like 'get' or 'fetch'. It does not explicitly distinguish itself from sibling tools like metamuse_assets, but the listed fields give it a distinct identity.

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 such as metamuse_assets or metamuse_summary. There are no exclusions, prerequisites, or context cues about the appropriate invocation scenario.

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

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

The readOnlyHint annotation already indicates a safe read operation, so the description's burden is lower, but it adds no behavioral context beyond that. It mentions 'live Chainlink price' but does not disclose what the tool actually does when invoked (e.g., returns a list, fetches current data, or any constraints). No side effects or limits are described.

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, compact sentence with no filler. It is appropriately short and has no unnecessary words, achieving high conciseness and straightforward structure.

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 an output schema, the description must convey the return value, but it does not explicitly state what the tool returns. The phrase 'what a muse may buy' implies a list of tradable assets, but it is not explicit about the output format (e.g., array of tokens with prices). An agent cannot be certain whether it returns a single item or a list, making the description incomplete for a zero-param tool.

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

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

The tool has zero parameters, and the schema is empty (100% coverage). Per the baseline for 0-param tools, a score of 4 is appropriate. The description adds nothing about parameters because none exist, and no additional meaning 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?

The description is a noun phrase ('Robinhood Stock Tokens with a live Chainlink price') rather than an action statement. It does not state what the tool does (e.g., 'returns a list of...'), leaving the agent to infer the operation. It does identify a resource (tradable stocks) but lacks a clear verb or explicit purpose.

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

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

No guidance is provided on when to use this tool versus its siblings like metamuse_price or metamuse_quote. There is no mention of alternatives, conditions, or exclusions, so an agent has no help in selecting 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?

readOnlyHint=true already declares the tool safe, and the description adds meaningful context: it pulls from two distinct sources (Robinhood bid/ask versus Chainlink on-chain). However, it does not disclose behavior for unknown symbols or data freshness, leaving some behavioral gaps beyond the annotation.

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 14-word sentence, front-loaded with the two price sources and scoped by 'for one ticker'. Every word earns its place; there is no fluff or redundancy.

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

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

For a one-parameter, read-only price tool, the description covers what data is returned (Robinhood bid/ask and Chainlink on-chain price) and what identifies it (ticker). It does not detail output structure or error handling, but with no output schema and a simple read operation, the gaps are minor.

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

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

Schema description coverage is 0%, so the description must carry the meaning of 'symbol'. The phrase 'for one ticker' directly equates the parameter to a ticker, adequately conveying semantics for this single string param, though the expected format (e.g., 'AAPL' vs 'aapl') is not stated.

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 specifies the resource (price for one ticker) and the two data sources (Robinhood bid/ask, Chainlink on-chain), making it clear what the tool reports. It lacks an explicit verb like 'get' or 'fetch', and does not explicitly differentiate from the sibling metamuse_quote, so it loses a point.

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. Given the sibling metamuse_quote likely overlaps in price data, the absence of any distinction or when-to-use note leaves the agent to guess which tool fits.

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

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

The phrase 'would return right now' implies a simulated quote rather than an actual execution, which adds context beyond the readOnlyHint annotation. However, no other behavioral details such as error handling or rate limits are disclosed.

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 with no wasted words. However, its brevity under-specifies the tool's behavior and parameters, making it minimally adequate in structure.

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 far from complete. It lacks parameter explanations, return value details, and any caveats, which is especially problematic given the tool has four parameters and no output 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?

With 0% schema description coverage, the description must explain the parameters, but it does not mention tokenIn, tokenOut, amountIn, or slippageBps. No meaning is added beyond the bare schema property names.

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

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

The description clearly states the tool provides a quote for a trade between USDG and a stock, using a specific verb ('return') and resource. It is distinguishable from siblings like metamuse_price by mentioning the trade context, though it does not explicitly name alternatives.

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 on when to use this tool versus siblings like metamuse_price or metamuse_assets. There are no exclusions or conditions provided, leaving the agent to infer usage context.

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

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

The readOnlyHint annotation already covers safety, and the description adds minimal behavioral context: results are the latest settlements and can be limited to one address. It does not disclose ordering, pagination, or how n affects results, but the annotation lowers the burden.

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 extremely short and front-loaded; every phrase earns its place. It is appropriately terse for a simple listing tool, though it sacrifices needed detail for brevity.

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

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

With no output schema and no description of the return value, the agent is left guessing what a receipt actually contains. The n parameter is also undocumented, so an agent cannot confidently choose a meaningful value beyond relying on defaults.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It explains that address is optional and filters to one address, but n is entirely unexplained, leaving its meaning and range ambiguous despite the schema limits.

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 resource: latest settlements (receipts), and adds an optional address filter. It lacks an explicit verb and does not differentiate itself from siblings, but the core purpose is immediately understandable.

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 rh777_tx, rh777_summary, or the metamuse_* siblings. The optional address filter is mentioned, but no contexts, exclusions, or alternatives 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?

The readOnlyHint annotation covers the safety profile, and the description adds that this is an aggregate view of totals and health. However, it does not disclose whether totals cover a specific period, what 'health' includes, or any freshness/caching behavior, leaving some uncertainty.

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 that states the essential function without filler. It is 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?

With no output schema, the description is the only guide to what the agent will receive. 'Totals and health' is somewhat vague, and specifying the exact metrics or return shape would make the tool easier to invoke and interpret. Still, for a simple no-parameter summary, it is minimally adequate.

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

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

The tool has zero parameters, so there is no parameter meaning for the description to add. The empty schema is fully self-explanatory; the baseline of 4 applies.

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

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

The description states the tool reports totals and health of the rh777 payment rail, identifying a specific resource and scope. It does not explicitly contrast with siblings, but the aggregate focus differentiates it from transaction-level tools like rh777_tx and rh777_receipts.

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 on when to use this tool versus siblings such as metamuse_account, rh777_receipts, or rh777_tx. The description does not mention alternatives, exclusions, or context for when a summary 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?

The readOnlyHint annotation already signals a read-only operation, lowering the bar. The description adds a small amount of behavioral context by mentioning 'the chain's record' and 'attestation check,' but it is still too vague to convey meaningful details such as what is verified, what is returned, or whether external dependencies exist. No contradiction with annotations is present.

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 short, but brevity here is under-specification rather than effective concision. The single sentence does not earn its place because it fails to define the operation clearly.

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

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

Although the input schema is small, the description omits essential context: what the result looks like, what the hash means, and how this tool relates to similar siblings. The combination of vague prose and an undocumented parameter leaves the tool under-specified 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?

There is one required parameter, 'hash', with zero schema description coverage. The description never explains what the hash refers to — transaction hash, attestation hash, or record ID — so the agent cannot confidently infer how to populate the parameter.

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

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

The description gestures at a purpose — settlement, the chain's record, and an attestation check — but uses no verb and never states a concrete action such as fetch, validate, or return. It is vaguely informative but does not clearly distinguish this tool from siblings like rh777_receipts or rh777_summary.

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 required 'hash' parameter implies a lookup-by-hash operation, but the description does not state conditions, exclusions, or how this differs from the other rh777 and metamuse tools.

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