solidrpc_manage

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.