Get authoritative rule fields (WAF or Smart Firewall)

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

The description discloses that this tool is the single source of truth and never drifts from what validation accepts, establishing trustworthiness. It also details the behavioral difference between rule types (waf gives HTTP L7 fields; smart_firewall gives L3/L4 + JA4 fields, no http.*) and the fallback to static context if the validator is unreachable. Since no annotations are provided, the description carries the full burden and addresses it comprehensively.

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 description is two sentences with no wasted words. It is front-loaded with the action 'Fetch the live, authoritative...', and every sentence adds value: the first explains what and how, the second asserts authority and notes fallback. It is concise yet information-dense.

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?

Given the tool has only one parameter, no output schema, and no annotations, the description covers all necessary aspects: purpose, parameter semantics, behavioral details (authoritativeness, fallback), usage guidance (prefer over static), and even comparative scope differences between rule types. It is fully self-contained and leaves no key question unanswered.

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 has 0% description coverage with one parameter (rule_type) lacking enums or descriptions. The description adds significant meaning by explaining that 'waf' returns HTTP L7 fields and 'smart_firewall' returns L3/L4 + JA4 fields with no http.*, and that it fetches from the rules-validator. This fully compensates for the missing schema detail.

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 it fetches the live authoritative Wirefilter field/function schema for a given rule_type ('waf' or 'smart_firewall'), specifying the source (rules-validator) and the scope. It distinguishes itself from siblings like validate_waf_expression and get_waf_context by emphasizing it is the single source of truth for field definitions.

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 description provides clear context for when to use this tool: when building expressions, prefer it over the static wafcontext://fields resource. It also mentions the fallback behavior if the validator is unreachable. However, it does not explicitly state when not to use it or describe scenarios where alternatives might be preferred, missing a full when/when-not distinction.

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