rpc_call

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

With no annotations, the description carries the full burden, and it does disclose a real behavioral constraint: destructive/configuration methods are blocked unless ARKKVM_ALLOW_DANGEROUS_RPC=1. It does not explain what happens on an unknown method, how blocked calls fail, or which methods count as 'configuration', but the safety gate is the key trait and it is surfaced up front.

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 dense sentences with zero waste: the capability and its risk gate. The example list is load-bearing rather than padding, and the blocking constraint is placed where it will be read before invocation.

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?

An output schema exists, so return values need not be described, and the description covers the capability, examples, and the safety gate. The remaining gap is the opaque params object and the absence of any note on error/unknown-method behavior for a generic dispatcher.

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 two params (method, params) have no descriptions at all. The example method names give the agent a sense of valid method values, partially compensating, but the params object's shape and per-method requirements are entirely undocumented in both schema and description.

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 ('call any ArkKVM JSON-RPC method') and immediately bounds it with concrete examples (getNetworkState, getEDID, setJigglerState). The 'Advanced' framing plus the generic-method nature differentiates it from every typed sibling (screenshot, click, power, usb_drive_*), which are single-operation wrappers.

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 'Advanced:' prefix and concrete method examples imply this is the escape hatch for capabilities with no dedicated sibling tool, and the description states the governing condition for the dangerous-method gate. It never explicitly says 'prefer the dedicated tool when one exists', leaving the agent to infer the fallback relationship.

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