Execute Anonymous Apex

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

The description adds context beyond the annotations by noting that code runs in the authenticated user's context and that the tool returns compile errors, runtime exceptions, and debug log output. Annotations already indicate it is not read-only and not idempotent, so the description is consistent and provides useful extra details.

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 three sentences long, front-loaded with the core purpose, and each sentence contributes valuable information: what it does, what it returns, when to use it, and execution context. No words are wasted.

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 appropriately covers the return values (compile errors, runtime exceptions, debug logs). It also mentions execution context and typical use cases. It lacks information about potential side effects on data, but the annotations already signal non-read-only behavior, making this acceptable.

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 input schema fully documents the only parameter (apexCode) with a description and example. The description adds no additional parameter-level semantics beyond what the schema already provides, so baseline score of 3 is appropriate.

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 action (executes anonymous Apex), specifies the resource (Apex code) and the exact endpoint (Tooling API executeAnonymous). It distinguishes itself from siblings by mentioning the specific use cases like one-off data fixes and debugging, which are distinct from running formal tests or querying data.

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 explicitly lists when to use the tool (one-off data fixes, testing snippets, creating test data, running utilities, debugging). However, it does not explicitly state when not to use it or name alternative tools, so it falls short of a perfect score.

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