secure_coding_checklist

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

No annotations are provided, so the description carries the full disclosure burden, and it discloses almost nothing. It does not say whether the result is static reference content or computed output, how language/feature interact, or what happens when they are omitted (both parameters are optional). Only the implicit 'this is pre-commit guidance' framing is added.

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?

Extremely short and front-loaded, but the second half is a compressed value dump rather than a sentence, forcing the reader to decode which list maps to which parameter. It is efficient in size but under-structured rather than genuinely concise.

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 annotations, no output schema, and two undocumented optional parameters, the description should explain what the tool returns and how to combine language and feature. It leaves the agent unable to predict the response shape or the effect of calling with no arguments.

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 0% and neither parameter has an enum, so the description is the only source of value hints — and it does enumerate candidate languages (python, js/ts, go, java, php, c, rust) and features (login, upload, payment, webhook, search, admin, ai-chat, password reset). However, it never labels these as values for the `language` and `feature` parameters, nor explains defaults, optionality, or free-form behavior.

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 phrase "Pre-commit checklist for new code" signals the resource (a checklist) but never states the verb — does it generate, retrieve, or validate against a checklist? The trailing language/feature lists are raw value enumerations with no framing sentence explaining what they select. It is distinguishable from scan_code/scan_path (which scan), but only by inference.

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?

There is no statement of when to use this versus siblings like scan_code, scan_path, skills_for_task, or search_security, nor any prerequisite or exclusion. An agent must guess whether this produces static guidance or performs analysis.

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