lint_solidity

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

With no annotations, the description carries the full behavioral burden. It does add one genuinely useful trait beyond the schema: that the config falls back to the project's Solhint config rather than being required. However, it never states the nature of the operation (read-only diagnostic), the shape of the lint result (violations, severities), or determinism/latency characteristics.

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?

A single sentence with the action front-loaded and every clause earning its place; no filler or restatement of the title.

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 should ideally say something about what a lint returns (errors/warnings list, their format), which it omits entirely. The nested config object is also left unexplicated. It is adequate for a two-parameter diagnostic tool but leaves the result contract unspecified.

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 description coverage is 100%, so both parameters are already documented, which sets the baseline at 3. The description adds marginal value by clarifying the fallback semantics of "config" (project config when not supplied), but supplies no details on how a supplied config merges with or replaces the project config.

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 pairs the specific verb "lint" with the specific resource "Solidity source string," and the phrase "source string" cleanly separates it from the file- and project-oriented siblings lint_file and lint_project. An agent can choose correctly without opening any schema.

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?

Usage is only implied: the mention of "the project or supplied Solhint config" hints that config is optional and defaults to project settings, but there is no explicit when-to-use statement and no exclusion or routing advice relative to siblings like lint_file or fix_solidity (e.g. that fix_* should be used when the caller wants corrections applied).

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