rn_eval

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

With no annotations provided, the description carries the full burden of disclosure. It reveals two important behavioral traits: it only works in dev builds and that returned app data must be treated as untrusted instructions. This goes beyond the basic operation and provides critical safety guidance about a powerful tool. It does not detail error handling or side effects, but the key behavioral risks are addressed.

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 two sentences, front-loaded with the primary purpose, and includes a necessary safety warning. Every clause is informative, with no redundant or filler content.

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?

Given the tool's simplicity and lack of output schema, the description covers the essential aspects: what it does, the dev-only requirement, and a security warning. It does not explain the optional bundleId or return value structure, but for a straightforward eval tool, the description is adequate. It is not overburdened, yet could benefit from a bit more context on bundleId.

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 description adds no parameter information beyond what is in the schema. Schema coverage is 50% because bundleId lacks a description, and the tool description does not clarify its purpose or usage. The expression parameter's description in the schema is adequate, but the overall parameter semantics are not enhanced by the tool 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?

The description clearly states the tool evaluates a JavaScript expression in the running app, using a specific verb ('Evaluate') and a clear resource ('JavaScript expression inside the running app'). It also notes 'Dev builds only,' which is a distinctive context. No sibling tool appears to offer this functionality, so it is well differentiated.

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 provides a clear usage context by explicitly stating 'Dev builds only,' which tells the agent when this tool is applicable. It does not mention exclusions or alternatives, but given the absence of a sibling eval tool, the context is sufficient. The security note about treating returned data as untrusted also serves as a usage caution.

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