lint

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

Beyond the annotations, the description discloses that general returns the text `wenlan lint` prints while deep returns a canonical typed report, that incomplete takes precedence over findings, that work_digest reads only this local MCP process and ignores other parameters, and that paging follows next_offset before submitting exactly one verdict per candidate.

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 opening sentence is front-loaded, but the rest is a dense single paragraph mixing profile behavior, paging, adjudication consent, and submission protocol. Every detail is relevant, yet the lack of structural separation makes the definition harder to scan than necessary for a 7-parameter tool.

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 complex tool with no output schema, the description explains the divergent return shapes (raw text for General, typed report for Deep) and the work-packet page shape. It does not explain what 'Incomplete' means operationally or how lint findings relate to the sibling repair tools, leaving a small completeness gap.

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 100%, so the baseline is 3, but the description adds meaningful cross-parameter behavior: profile selects the return format, work_digest changes the entire mode and causes other parameters to be ignored, offset and limit page the work packet, and agent_assist is Deep-only. It still leaves some nuance (e.g., precise interaction of space with each profile) to the 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 description clearly states the core action (run Wenlan's read-only system lint) and distinguishes two execution profiles plus a work-packet paging mode. It does not explicitly differentiate itself from sibling lint_repair_* tools, which is the main gap for a 5.

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 clear mode-selection context: general is the default bounded profile, deep adds expensive checks and semantic candidates, agent_assist requires explicit consent, and work_digest switches to paging the cached packet. It never names sibling tools or tells the agent when not to use this tool, so it stops short of full alternative guidance.

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