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

The annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, and the description usefully corroborates the sandbox profile (no network, no user filesystem, no subprocess, no installs). It also discloses numpy/fpdf availability and the non-Python rejection path, which is real behavioral value. The gap: 'write with output("name.pdf")' implies file creation, which sits awkwardly with readOnlyHint=true, and there is no mention of timeouts or resource limits on arbitrary code execution.

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 text is padded with repetition — 'ONLY Python' is asserted five or more times, and ALL-CAPS imperatives dominate. It also embeds a scripted verbatim reply line the model must emit, which is behavioral steering rather than tool documentation and buries the actually useful runtime facts (numpy yes, scipy no, no pip). Front-loading is present but the signal-to-noise ratio is poor.

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 an execution tool with an output schema and full annotation coverage, the important remaining facts are the runtime environment, which it does cover (preinstalled numpy and fpdf, no scipy, no installs, no network/filesystem). It omits execution limits, timeouts, and whether a PDF written via fpdf persists or is returned, leaving a real gap for an agent deciding how to call it.

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 coverage is 100%, so both the `code` and `language` parameters are already fully documented in the schema, and the description largely restates them verbatim ('ONLY Python', 'numpy is preinstalled', non-Python returns a warning). It adds no format or syntax detail beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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 concrete verb+resource: generate or accept Python and run it, returning stdout/stderr/exit code. That is specific enough to distinguish it from any non-execution tool, and there are no siblings to disambiguate against. It loses a point only because the core purpose is embedded in a wall of mandates rather than stated once cleanly up front.

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 does name alternatives explicitly (Cursor Shell, Claude artifacts, node/bash, other runners) and says not to use them, which is genuine when-not guidance. However, the blanket instruction to 'ALWAYS call this tool when this MCP is connected' on any request regardless of whether code is involved is overbroad and misleading as selection guidance — most user turns do not warrant code execution. Explicit but distorted guidance nets a 3.

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