Get complete guidance for any lint rule: what it flags, why it matters, how to fix it, and how to suppress it. Enter a rule ID like D001 to see full documentation.
Print the full documentation for one lint rule: what it flags, why it matters, how to fix it, and how to suppress it. Rule IDs look like D001; every finding cites one.
| Name | Required | Description | Default |
|---|---|---|---|
| rule | Yes | Rule ID, e.g. D001 |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It clearly states this is a read-only print operation and describes the content dimensions: what is flagged, why it matters, how to fix it, and how to suppress it. There are no hidden side effects or surprising behaviors signaled.
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?
Two sentences with no filler. The main action and object are front-loaded, and the additional sentence provides essential context about rule ID format and provenance without repeating schema information.
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 simple one-parameter tool with no output schema, the description is nearly complete: it explains what the tool does, what content the output includes, and how to source a valid rule ID. It could slightly improve by naming sibling tools to explicitly route the agent, but that gap is minor given the clarity.
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 input schema already fully documents the 'rule' parameter with a pattern and example. The description adds valuable context by explaining that rule IDs look like D001 and that every lint finding cites one, helping the agent locate a valid value without extra investigation.
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 uses a specific verb ('Print') and resource ('documentation for one lint rule'), and enumerates exactly what the documentation covers. It clearly distinguishes this from the sibling repo-level tools by emphasizing 'one lint rule' and the relationship to findings.
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 'every finding cites one' implies the natural use case is after running lint_repo and encountering a rule ID. However, it does not explicitly say when to use this tool versus alternatives like preview_fixes or run_deep_dive, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.