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

With no annotations, the description carries the behavioral burden, and it does disclose that the audit is static, deterministic, and limited to 10 named patterns. It does not describe return format, input handling, whether code is sent externally, or limitations beyond pattern coverage, so transparency is only partial.

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 compact and front-loaded with the main purpose, followed by a concrete pattern list and known behavioral qualifiers. The 'Case:' URL is somewhat peripheral for selection and invocation, but the overall length is appropriate.

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?

Despite being a meaningful audit tool, the description leaves important invocation details unspecified: all five parameters are optional, no required input is identified, no output structure is described, and there is no instruction on whether to pass raw code, a source string, a gzipped source, or base64. With no annotations and no output schema, an agent cannot confidently know how to call this tool 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?

The schema has 100% property description coverage, but every description is essentially 'parameter name to process,' which adds little meaning. The tool description itself gives no guidance on which parameter to supply, whether code and source are interchangeable, or what format is expected, so it lands at the baseline rather than above it.

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 identifies the tool as a smart contract security audit / Solidity vulnerability scanner and enumerates the 10 static patterns it covers. It is more specific than the name alone, but it never explicitly calls out sibling tools such as contract-scan or ai-audit, so differentiation is left implicit.

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 phrase 'Fast pre-check, deterministic' implies the tool is appropriate for quick, reproducible static checks, which gives some usage context. However, it does not state when to prefer a deeper AI audit, a triage tool, or another contract-analysis sibling, and it provides no explicit when-not-to-use guidance.

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