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

The readOnlyHint annotation already establishes that this is a safe, non-mutating call, so the description's remaining burden is lighter. It adds the useful detail that several distinct billing facets are returned together, but says nothing about the response shape, per-facet permissions, or whether reserved funds and signed budget are account-scoped — real gaps for a data-retrieval 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?

A single compact sentence with the resource list front-loaded and no filler. It is appropriately sized, though as a bare fragment it could open with a slightly clearer framing of scope.

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 input parameters and no output schema, the description is the agent's only source of information about what is returned, and it lists the categories without describing fields, units, or shape. For a zero-argument read tool that is the whole contract, this is adequate but leaves the agent guessing about the payload.

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 takes zero parameters, so there is no parameter semantics for the description to explain and the baseline of 4 applies. The description correctly implies the call is context-free and needs no arguments.

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 ('Read') plus an enumerated set of resources (balance, reserved funds, signed budget, top-up status), which tells an agent exactly what data comes back. It falls short of a 5 because it never distinguishes itself from siblings like solidrpc_usage or solidrpc_top_up, which an agent could easily confuse with this billing read.

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

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

There is no when-to-use guidance, no exclusions, and no mention of the obvious alternatives (solidrpc_usage for consumption, solidrpc_top_up for adding funds). The agent must infer from the sibling names alone whether this is the right read for a given question.

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 declare readOnlyHint=false, so the agent already knows this is a mutation; the description adds genuinely new behavioral context by explaining idempotent retry semantics. However, it says nothing about whether the key secret is returned once, whether creation is reversible, or what happens on duplicate names, which matters for a create 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?

Two short sentences, front-loaded with the action and followed by the operational caveat; nothing is wasted. The terseness borders on under-specification, but as a structural matter it is clean 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 mutation tool with no output schema and 0% schema description coverage, yet the description does not explain what the returned key looks like, whether the secret is shown once, or what 'name' identifies. Given the complexity gaps in both schema and annotations, more prose was warranted.

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 load. It explains the intent of idempotencyKey (persist and reuse across retries), which meaningfully supplements the bare minLength constraint, but the required 'name' parameter is left completely unexplained, half the parameters undocumented.

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, 'Create an RPC key', which an agent can distinguish from siblings like solidrpc_revoke_key and solidrpc_keys by the verb alone. It stops short of naming an explicit alternative or clarifying how it relates to solidrpc_manage, so it stops at 4 rather than 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 only usage guidance is for retries: persist and reuse the idempotencyKey. There is no statement of when to call this versus solidrpc_keys or solidrpc_manage, no prerequisites, and no note about permissions or quota implications of creating a key.

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, so the safety profile is covered. The description adds a genuinely non-obvious behavioral guarantee — that key secrets are never revealed in the listing — which matters for an agent deciding whether this call is safe to expose in output. It does not address pagination, ordering, or the shape of returned metadata, 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?

A single sentence with no wasted words, front-loading the verb and resource before the security caveat. Nothing needs trimming or reordering.

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 an empty input schema, the description is the only source of information about results, yet it does not say which metadata fields are returned or whether the list is paginated. For a trivial no-arg tool this is acceptable but leaves a real 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?

The tool takes zero parameters, so the baseline is 4 and the description carries no additional parameter burden. There is nothing parameter-related left ambiguous.

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 ("List RPC key metadata"), which clearly separates it from write-side siblings such as solidrpc_create_key and solidrpc_revoke_key. It does not explicitly name those siblings as alternatives, so it falls 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?

Usage is only implied: an agent can infer this is the read/inspection counterpart to create/revoke key operations. There is no explicit statement of when to call it versus solidrpc_manage or solidrpc_usage, and no prerequisites are mentioned.

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

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

The annotations already declare destructiveHint=true, openWorldHint=true and idempotentHint=false, and the description adds real value on top: a scoped management credential is required, funding and key creation need a stable idempotency key, budget authorization needs an owner-approved wallet signature, and support content must be treated as untrusted data. It does not say what a destructive call actually destroys or whether changes are reversible, but the safety-relevant context is unusually rich for a passthrough 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?

It is compact and every sentence carries a distinct constraint, with no filler. The weakness is ordering: the definition of what the tool actually is sits buried in the middle ('Paths are relative to /agent/v1') rather than being front-loaded, and the constraint list reads as an unstructured run-on.

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 destructive, open-world passthrough with no output schema, the description covers credentials, eligibility, the main safety prohibitions and the two special-purpose parameters. What is missing is a statement that this is a generic HTTP escape hatch and any indication of which endpoints exist, which would be the remaining gap for an agent deciding whether it can accomplish a task through this tool.

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

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

Schema description coverage is 0% across five parameters, so the description must carry the load. It does explain the trigger conditions for idempotencyKey and paymentSignature, and it constrains path ('relative to /agent/v1'), but it says nothing about how method should be chosen, or what the free-form body may contain for each endpoint - the largest source of agent error here.

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 verb+resource pair is the generic 'Manage the SolidRPC account', which is broad enough to cover billing, keys, top-ups and support - all of which have dedicated siblings. The line 'Paths are relative to /agent/v1' hints that this is a raw path/method passthrough, but the description never states that plainly, so an agent cannot easily tell when this tool is the right choice over solidrpc_billing or solidrpc_keys.

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?

Useful operational constraints are present ('Never change owner identity or purchase a card plan', 'Funding and key creation require a stable idempotency key', 'Budget authorization requires the owner-approved wallet signature'), which effectively rule out certain paths. However, there is no guidance on when to route to this tool versus the eight purpose-built siblings, which is the primary selection decision an agent faces.

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 tells the agent this is a safe read, so the bar is lower. The description adds that the payload covers both supported networks and their RPC capabilities, which is useful signal about content, but says nothing about auth requirements, result size, caching, or ordering.

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 or redundancy. It is arguably under-specified rather than over-written, but every word earns its place and the key noun phrase comes first.

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 describing what comes back, and "networks and RPC capabilities" is only a rough sketch of the return shape (no field names, no structure, no per-network detail). For a simple zero-param read tool this is close to adequate, but a sentence on the response structure would close the 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?

The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. The description is consistent with the empty schema in signaling a no-argument enumeration call.

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?

"List supported networks and RPC capabilities" gives a specific verb (list) and two specific resources (networks, RPC capabilities), so the agent knows this is a read-only discovery/enumeration tool. It is clearly separable from siblings like solidrpc_keys, solidrpc_billing, and solidrpc_top_up, though it never explicitly contrasts itself with them.

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

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

Usage is only implied: an agent can infer this is the lookup call to run before picking a network for other solidrpc operations, but the description never says when to use it, when not to, or what alternative exists. No prerequisites, no mention of whether it should be called first in a workflow.

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 only declare readOnlyHint=false, so the description carries the real burden and does add value by disclosing the blast radius: applications using the key lose access. It still omits whether revocation is permanent or reversible, what happens if the id is unknown, and any permission requirements.

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

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

Two short sentences with the action first and the consequence second; nothing is wasteful. Every clause carries information relevant to the operation.

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 destructive tool with no output schema, the description covers the action and its impact, but leaves the identifier semantics and success/failure behavior unexplained. An agent could call it, but would be guessing about the id format and reversibility.

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% for the single required parameter 'id', and the description does not clarify whether it is a key ID, a key name, or a prefix. The only semantic hint is that the id identifies an 'RPC key', which is minimal compensation for the coverage gap.

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 ('Revoke an RPC key'), which unambiguously separates it from the sibling solidrpc_create_key. It does not explicitly reference the key-management siblings by name, but the operation is clear 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?

There is no when-to-use guidance, no prerequisites (e.g. ownership or admin role), and no pointer to alternatives such as solidrpc_keys for listing keys before revoking. The second sentence describes a consequence rather than a usage condition, so an agent gets no routing logic.

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=false annotation already signals a mutating operation, and the description adds a genuinely useful security constraint against including secrets. It does not say what is returned (e.g., a ticket ID), whether tickets are visible to the user, or any rate/eligibility limits.

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 that state what the tool does, then its main pitfall, with nothing redundant. It is on the sparse side, but every sentence is useful.

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 creation tool with no output schema, the description covers the action and the key safety caveat. It leaves out what happens after the call and how to fill in the fields, which an agent would need to use it confidently.

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 has to explain the parameters, but it never mentions subject or message. The names are self-explanatory, yet no guidance is given on expected content, length, or format.

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?

"Open an owned support ticket" gives a specific verb and resource, which is unambiguous and distinct from all siblings (manage, networks, keys, billing). The word "owned" is undefined but does not obscure the action.

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 gives no guidance on when to use this versus other support or billing tools, and no prerequisites or exclusions. The only guidance is a security constraint, not a routing rule.

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 annotations only declare readOnlyHint=false, so the description carries most of the burden. It adds real value by stating that no funds move and that settlement happens externally via x402 requirements, but it omits whether the reservation expires, whether it counts against the ceiling persistently, or what happens on failure.

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 the core action, then the key behavioral caveat, then the follow-up step. No filler 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 mutating two-parameter tool with no output schema, the description covers the essential safety caveat and next step but leaves the return payload (quote reference, expiry, x402 requirements shape) and ceiling-exceeded behavior undefined. Adequate but with clear gaps an agent would need to discover by calling.

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

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

Schema description coverage is 0%, so the description must compensate and largely does not. 'Within the signed payment ceiling' adds constraint meaning for amountCents, but the idempotencyKey — including its 16-character minimum and deduplication behavior — is never explained, and units/limits for amountCents are left to 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 uses a specific verb and resource ('Reserve a top-up quote') plus a scope constraint ('within the signed payment ceiling'), which is far more informative than the bare name. It is clear what the tool does, though it does not explicitly contrast itself with siblings such as solidrpc_billing or solidrpc_usage.

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 gives workflow context ('Does not transfer funds. Use the returned x402 requirements with an owner-authorized external wallet'), which implies this is the quote step preceding an external settlement. However, there is no explicit when-to-use vs. when-not guidance or named alternative, so usage is only 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?

readOnlyHint=true already declares this is a safe read, and 'Read' merely restates it. The description adds no behavior beyond the annotation: no time window semantics (current period? all time?), no scope (whole account vs. a resource), no pagination or response shape, despite there being no output 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?

It is a single front-loaded sentence with no filler, which is structurally clean. However, its brevity comes from under-specification rather than efficiency — the one sentence is too thin to guide selection or interpretation.

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 place to explain what 'usage' returns, and it says nothing. For a zero-parameter reporting tool sitting among billing, top-up, and key-management siblings, an agent cannot tell what data comes back or how it differs from solidrpc_billing.

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. Note the lack of parameters is itself informative — no time-range or scope filtering is possible, which the description does not call out.

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 verb ('Read') and a resource ('account usage'), but 'usage' is ambiguous — it could mean API call volume, quota consumption, spend, or seat counts, and the sibling set contains solidrpc_billing and solidrpc_top_up that plausibly overlap. It gives no differentiation from those 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?

There is no when-to-use guidance, no exclusions, and no mention of the billing/top_up siblings an agent must choose between. The agent is left to infer selection purely 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.