check

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

With no annotations, the description must carry everything, and it does: hard limits (20 files, 200 KB, 15-90s timeouts), path confinement to a temp workspace, execution locally in a minimal environment, JSON-formatted failures, and the critical warning that there is no network or filesystem sandbox so only trusted code should be run. This is exactly the context an agent needs before invoking an execution 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?

Purpose is front-loaded, then parameter semantics, then limits, then safety — a sensible order. The telegraphic fragment style ('language: python, javascript, ... or php.') is dense and every line earns its place, though the list-of-languages line is slightly awkward as prose.

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 an output schema exists, the description needn't detail return values, and it still flags that errors/findings come back as JSON. Limits, safety posture, and the retry loop are all covered. The remaining gap is the cases.tsv format, which is required for test execution but never specified.

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 0%, so the description carries the full burden and does so: language is enumerated, files and tests are described as relative-path-to-complete-content maps, and tests additionally must include a self-contained runner and cases.tsv. mode is explained by contrasting the two behaviors. This is meaning well beyond the bare schema.

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 definition states a specific action plus the underlying mechanism: it compiles/runs supplied tests and reports static heuristics on source, rather than merely 'checking'. The opening line 'Check code before finishing' is terse, but the following sentences make the operation unambiguous. With no sibling tools there is nothing to differentiate against, which caps the upside slightly.

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 gives a clear usage trigger ('before finishing') and, importantly, the selection rule between the two modes: full compiles and runs tests, static only reports source heuristics. It also describes the remediation loop ('Fix it and call again'). It does not say when not to use the tool or when static alone is sufficient, so it stops short of full when/when-not guidance.

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