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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, and the description adds genuinely non-inferable behavior: it is offline, charges $0.005 USDC per *successful* call via x402 on Solana, and is additionally reachable over HTTPS at a named endpoint. The return contract (0-100 score, letter grade, actionable fixes) is also disclosed despite there being no output schema.

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?

Front-loaded with the core identity, then rules, output, exclusions, and pricing in a logical order. Dense and mostly waste-free, though the long parenthetical rule list and the trailing pricing/endpoint sentence make it read as one run-on rather than clearly separated blocks.

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 a one-parameter, no-output-schema tool, the description covers output shape, cost, transport alternatives, and scope boundaries—well beyond expectations. The remaining gap is input semantics (what exactly to pass), but otherwise an agent has enough to invoke it correctly.

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% and the single `dockerfile` parameter is undocumented, so the description carries the full burden. 'Parses stages/continuations' weakly implies raw Dockerfile text rather than a path, URL, or repo reference, but that ambiguity is never resolved, and the schema's 'required: 0' raises the question of what happens with no input—unaddressed.

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+resource ('Dockerfile linter') and enumerates the actual rule surface (latest tag, curl|bash, secrets in ENV/ARG, runs-as-root, chmod 777, ADD-vs-COPY, apt cache, HEALTHCHECK, multi-stage), so an agent knows exactly what class of findings to expect. It also scopes out what it will not do ('Does not build or pull images'), which no sibling covers.

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?

Clear context for when to reach for it (static analysis of a Dockerfile before building) plus an explicit exclusion: it does not build or pull images. However, it never names a complementary or alternative tool (e.g. a general format/schema validator among the siblings), so routing guidance stops at the self-contained case.

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