tmpl

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

No annotations at all, so the description carries the full burden. It hints that only authorized targets may be scanned, but never states whether the scan is intrusive, whether templates can modify the target, expected runtime, or what a detection result looks like. For a scanning tool with zero structured safety metadata this is a significant gap.

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 short sentences with no padding or redundancy, and the nuclei analogy is front-loaded. But the second sentence is an ambiguous constraint that reads almost as a restatement of the 'only' parameter, so the terseness comes at the cost of clarity rather than being purely economical.

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 half the parameters undescribed, the burden falls entirely on two short sentences that omit what the tool returns, how templates are selected, and how it relates to the other scanning tools. For an inherently complex detection tool this is far from complete.

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 50%: 'only' has an example value in the schema, while 'url' is completely undocumented. The description adds nothing – it never mentions 'only', and the phrase 'cible autorisée uniquement' is easily confused with the 'only' parameter in French. The description does not compensate for the undocumented target parameter or clarify the template-id format beyond 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 says it performs detections via JSON templates in the manner of nuclei, which does let an agent infer a template-driven vulnerability/detection scan. But the verb is nominal ('Détections') and the tool name 'tmpl' is opaque, so the resource being operated on (a target URL) is only implicitly conveyed by the required 'url' param. It is not distinguished from siblings probe/dirs/ports, all of which also take a target.

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?

'Cible autorisée uniquement' is a legal/permission constraint, not usage guidance – it never says when to prefer tmpl over probe, dirs or kev, nor what preconditions (e.g. target must be enumerated first) apply. An agent gets no routing signal from this text.

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