Server Quality Checklist

Tool Scores

• managerA
  4.4/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden of disclosure. It thoroughly covers behavioral nuances: non-2xx responses are returned as-is, specific endpoints now return 404 which is correct, response schemas have changed, and the security root is deliberately restricted. This is exceptionally transparent about edge cases and limitations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but well-structured, with the purpose stated up front followed by relevant context, bullet points, and a clean Args section. The length is justified by the complexity and the need to explain the unusual passthrough behavior and API volatility. It is not excessively wordy—each sentence adds useful information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a passthrough tool, the description is remarkably complete. It explains the return behavior (unchanged, non-2xx as-is), lists verified working endpoints, documents changed response schemas, and clearly delimits the security scope. Since the tool returns responses unchanged and an output schema exists (likely generic), no further return-value detail is necessary. This fully equips an agent to use the tool appropriately.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. The Args section gives a one-line explanation for each parameter: path with an example ('/agents') and params as 'Optional query parameters.' This adds basic meaning but does not detail the structure of `params` (free-form object) or provide format constraints. It meets the minimum threshold but leaves room for more specificity.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a clear, specific statement: 'Issue a GET against the Wazuh manager API and return the response unchanged.' It identifies the verb (GET), the resource (Wazuh manager API), and the behavior (unchanged passthrough). It also distinguishes itself from sibling tools by explicitly stating it adds no interpretation, making its role unique.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  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 the tool: when raw API responses are needed, and it notes the API is volatile. It implicitly excludes security enumeration by restricting the `security` root and stating the tool is 'meant for agent and event data.' However, it does not explicitly name alternatives or give a direct 'use this instead of X' comparison, so it falls short of a 5.

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

• searchA
  4.6/5.0
  Behavior5/5

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

  With no annotations provided (readOnlyHint, destructiveHint absent), the description carries the full burden. It discloses: returns raw JSON with a diagnostics block when needed, caps size at KLAXON_SEARCH_MAX_SIZE, caps aggregation sizes, and anonymizes bucket keys when enabled. It even mentions the '[AGG SIZE CAPPED]' diagnostics line. This is extensive behavioral disclosure covering data transformation, limits, and conditional output.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but each paragraph earns its place: the first gives the core purpose and diagnostics, the second lists common patterns, the third covers constraints (time field, track_total_hits, size cap), the fourth covers aggregation sizing, and the fifth covers anonymization. It front-loads the core purpose and the diagnostics. A minor deduction because the lsit of patterns and the anonymization paragraph could be trimmed or merged, but it's well-structured and not redundant.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there's an output schema, the return format is already defined. The tool is complex (2 parameters, high behavioral complexity with caps, anonymization, diagnostics), and the description covers: index patterns and constraints, time field naming, track_total_hits semantics, size caps for both hits and aggregations, anonymization behavior, and the diagnostics block. There's nothing an agent needs to correctly call this tool that is missing. The description is complete for its complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0% (no descriptions in the input schema) and there are only two params: index and body. The description explains index thoroughly (patterns, wildcard requirement, datastream naming) and body as 'OpenSearch query DSL as a JSON string'. It doesn't elaborate on the body's structure beyond that, but body is generic DSL where the user must provide the JSON. The description adds meaning for index beyond the schema (which only says 'string') and a reasonable definition of body.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('Run an OpenSearch query DSL request') and the resource ('Wazuh 5 index pattern'). It strongly distinguishes itself from siblings—while 'schema' likely describes the index schema and 'findings_overview' summarizes findings, this tool runs raw DSL queries. The description is specific about the API target, making it unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit usage guidance: which index patterns to use, to use wildcard patterns rather than backing indices, to set track_total_hits for exact counts, and to use size:0 with aggregations. It also warns against the wrong approach (backing index) and provides concrete examples of patterns. It doesn't explicitly name sibling alternatives, but the 'when to use' guidance is so complete that an agent knows exactly when this tool is appropriate.

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

• klaxon_posture_checkA
  4.7/5.0
  Behavior5/5

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

  With no annotations provided, the description fully carries the burden of behavioral disclosure. It explicitly states the tool is read-only, never emits the salt, omits PII, returns only counts/booleans/statuses, and reports 'unknown' when the indexer is unreachable. This goes far beyond a basic safety profile.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is detailed but every sentence earns its place: it covers output format, constraints, error behavior, and parameter semantics. The structure with paragraphs and an Args list is clear and appropriately front-loaded with the most critical safety guarantees.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has a rich output schema and complex behavior, and the description fully explains return values, statuses, and edge cases (e.g., unreachable indexer). It leaves no ambiguity about what the tool does, what it outputs, and what it avoids doing, making it complete for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema only provides titles and defaults, but the description's Args section explains the semantic role of each parameter (e.g., tenant specifies which masked/quarantine streams and RBAC roles are checked). This adds meaning beyond the schema, though it does not detail types or constraints beyond defaults.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as a read-only security/DSGVO posture check that returns facts and gaps, never a verdict. It also distinguishes itself from the sibling gdpr_check by referencing the same principle, ensuring no confusion with similar tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool (for posture checks) and references gdpr_check as a sibling with the same principle, offering some context. However, it does not explicitly state when to prefer this over other siblings or provide exclusions, so it is clear but not exhaustive.

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

• schemaA
  4.7/5.0
  Behavior5/5

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

  With no annotations, the description carries full weight. It discloses the cap on unfiltered listings, the behavior of 'only_populated' (a second pass with exists aggregations), and the fact that aggregating on the wrong field returns HTTP 200 with zero buckets. These are key behavioral traits beyond simple function.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but well-structured: purpose sentence, use-case context, namespace size reference, then parameter details. It is front-loaded with the core purpose and every sentence adds value, though the namespace size list could be seen as slightly tangential.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity, zero annotations, and no schema-level parameter descriptions, the description covers purpose, usage guidance, behavioral nuances, and parameter semantics thoroughly. The existence of an output schema means return value details are not needed in the description.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The Args section provides thorough explanations for all three parameters, including examples like 'wazuh-events-v5-network-activity*' for index and 'wazuh.' for prefix, plus the default behavior of only_populated. Since the input schema has no descriptions for properties, this fully compensates.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The opening sentence clearly states the tool's function: 'List the fields of a Wazuh 5 index and how many documents actually fill them.' It names a specific verb (List) and resource (fields of a Wazuh 5 index) and distinguishes itself from siblings like 'field_coverage' by focusing on populated vs. mapped fields.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly directs users to 'Use this before writing any aggregation' and explains the pitfall of aggregating on a mapped but unpopulated field. It provides clear context and a strong recommendation for the 'prefix' parameter, though it does not explicitly state when not to use the tool or name alternative tools.

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

• detectorsA
  4.8/5.0
  Behavior4/5

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

  With no annotations provided, the description takes on the transparency burden. It reveals implementation details (POST /_plugins/_security_analytics/detectors/_search with match_all), response nesting, and the fact that these detectors produce wazuh-findings-v5-* documents. It does not explicitly mention side effects or permissions, but read-only behavior is strongly implied by 'List or fetch.'

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and every sentence earns its place. It provides essential context, implementation notes, and a clear Args block. Despite being longer than average, the information is dense and relevant, with no fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a three-parameter tool with an output schema, the description is complete. It covers action semantics, parameters, defaults, implementation behavior, and the nested response structure. The output schema exists, so not detailing return values is acceptable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, but the description fully compensates by explaining all three parameters: action's allowed values, detector_id's requirement when action is 'get', and size's purpose with a default. This adds meaning far beyond the bare schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'List or fetch OpenSearch Security Analytics detectors.' It specifies the resource (detectors) and the two primary actions (list and get). It further differentiates from sibling tools by explaining that detectors in Wazuh 5 are indexer-based, providing unique context.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit guidance on when to use 'list' versus 'get' and notes that no list-all endpoint exists, so list is implemented via a search endpoint. It also clarifies that detector documents are nested under the 'detector' path, which is important for searching by name. This is strong practical guidance.

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

• gdpr_checkA
  4.8/5.0
  Behavior5/5

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

  With no annotations provided, the description fully discloses behavior: reading mappings, sampling documents, using three heuristics, classifying fields into high/medium/flagged, handling already-covered fields, and explaining the apply=true side effects (config merge, logging, report writing, restart requirement, and environment override). This is exemplary transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with clear paragraphs and an Args list. Every sentence contributes value: heuristics, priorities, apply behavior, and parameter details. It is detailed yet concise, with no wasted words or redundancy with the schema.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex tool with 6 parameters and significant side effects, the description covers all necessary contextual aspects: input parameters, heuristics, classification logic, side effects, environment variable override, and default behavior. Since an output schema exists, return value details are not required, but the description still mentions the report format and filenames.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description becomes the sole source of parameter meaning. It compensates comprehensively by listing all six parameters in an Args section, explaining each one's purpose, defaults (e.g., sample_docs defaults to KLAXON_GDPR_SAMPLE_SIZE, apply defaults to false), and examples (index pattern, prefix format, exclude semantics).

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states the tool 'runs the DSGVO plausibility check on an index: find sensitive fields.' It details three heuristics and clearly distinguishes itself from sibling tools (search, schema, etc.) by its unique GDPR-specific function.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on when to use this tool (for GDPR checks and finding sensitive fields) and explains the dry-run vs. apply modes. It does not explicitly mention alternatives or exclusions, but the purpose is unambiguous and self-contained.

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

• tester_sessionsA
  4.8/5.0
  Behavior5/5

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

  No annotations are provided, so the description carries the full burden. It discloses the HTTP endpoint, the need for KLAXON_ENGINE_URL, the read-only nature, and the lifecycle of sessions (recreated on policy import). This is thorough behavioral disclosure beyond what any schema could convey.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is detailed but every sentence earns its place. It front-loads the core purpose, then explains the failure mode, the API call, the URL requirement, and the design rationale. Slightly long but justified given the complexity and lack of annotations.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (internal API, environment variable requirement, misleading error behavior), the description covers everything an agent needs: what it does, when to use it, how it works, and why alternatives are absent. The output schema exists, so return format is covered elsewhere. Complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must compensate. It does: it explains the only parameter 'action' supports only 'list'. This fully documents the parameter's meaning and constraints, though it could have been more explicit about the default value. Still, it adds significant value beyond the bare schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists Wazuh 5 engine test sessions, which are the environments logtest can use. It distinguishes itself from siblings by explaining its role relative to logtest and the internal API. The verb 'list' and resource 'test sessions' are specific and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly explains when to use this tool: to discover which environments exist and whether they are enabled, especially when logtest returns a misleading success response. It also explains why create/delete/reload tools are not provided, preventing misuse. This is exemplary usage guidance.

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

• field_coverageA
  4.9/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden. It thoroughly discloses behavior: fields with 0% are listed, never filtered; the three-valued coverage semantics; how index:false fields are reported as 'not measurable' with dashes and sampled from _source instead; cost scaling with field count and the truncation cap; and that min_docs hides fields and the output reports how many were dropped.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is longer but every section earns its place. It opens with a clear summary, then explains the core distinction, the three-valued semantics, and cost/truncation. The Args section is formatted clearly. It could potentially be tightened, but the density of information is high and front-loaded with the most important facts.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity, 4 parameters, and an output schema, the description is remarkably complete. It covers output semantics, edge cases (index:false), cost considerations, parameter effects, and interpretation guidance. An agent has everything needed to call it correctly and interpret results.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description compensates fully. It explains each parameter in the Args section, providing defaults, meanings, and examples. For index it gives an example, for prefix it shows namespace examples and purpose, for hours it specifies the time window size, and for min_docs it explains the default behavior and the consequence of setting it higher.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool measures field coverage in documents, a specific verb-resource combination. It distinguishes itself from siblings like search or schema by emphasizing it's a normalisation-quality measurement callable without query DSL, and details its unique three-valued coverage output.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly explains when to use this tool versus alternatives, though it doesn't name siblings directly. It says it's for normalisation-quality measurement 'callable without query DSL', differentiates between whole datastream vs time-window coverage, warns about interpreting the gap, and explains the difference from a simple exists aggregation. It gives concrete usage context for the parameters like prefix to avoid truncation.

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

• findings_overviewA
  4.9/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and does so exceptionally. It discloses that severity is a string with a canonical order, that zero buckets are explicitly shown to avoid ambiguity, that unknown values are marked UNKNOWN, that the tool probes for field population, and that output is compact tables rather than raw JSON. This goes well beyond typical descriptions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is longer than a minimal one, but every sentence earns its place by explaining the rationale behind non-obvious behavior (e.g., explicit zero buckets, the probe before aggregation, output format). The structure is logical: purpose, usage, behavioral details, then args. Slightly verbose but not wasteful.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity and the absence of annotations, the description thoroughly covers purpose, parameters, output behavior, edge cases (missing levels, unknown values), and relationship to sibling tools. The output format is described even though an output schema exists, which helps set expectations. Nothing critical is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides only types and defaults with 0% schema description coverage, so the description must compensate. It does: each parameter (hours, top_agents, top_titles) is given a clear meaning, unit, and purpose, and defaults are restated with context. This fully resolves what the parameters control.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Summarise wazuh-findings-v5-* by severity, agent, rule title and category.' It clearly distinguishes itself from the sibling tool 'search' by explaining it is a frozen query for 'the breakdown every report starts with' and that 'search still covers everything else.'

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states when to use this tool: for the recurring aggregation that reports start with, and notes that 'search' covers everything else. This provides clear guidance on usage vs. alternatives, even naming the specific alternative and the scoping relationship between the two.

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

• logtestA
  5/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and does an excellent job. It discloses that the tool calls the Content Manager plugin on the indexer, explains the effect of trace_level values, and warns that without integration the detection phase is 'skipped.' It also notes that a valid space name does not guarantee the environment is provisioned, adding important behavioral context beyond the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but every sentence earns its place. It opens with the core purpose, then organises parameter details under a clear 'Args:' list. The prose about space and trace_level is dense but necessary. No filler or repetition exists.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (6 parameters, no schema descriptions, no annotations), the description provides all needed context: what the tool does, what the output looks like, how parameters affect behavior, and where to go for related information. The output schema exists, so return values are covered. This is a complete, self-sufficient tool definition.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 0% description coverage, but the description fully compensates by explaining every parameter: event, location, queue, space, trace_level, and integration. It includes allowed values, defaults, and behavior for each, such as 'trace_level: One of NONE, ASSET_ONLY, ALL' and 'Defaults to ASSET_ONLY.' This goes far beyond the bare schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a clear, specific action: 'Run a raw log line through the Wazuh 5 decoder chain and return the result.' It further explains the purpose by stating that the response shows which decoders matched and the normalised WCS document, positioning it as a diagnostic tool for field issues. This distinguishes it from sibling tools like search or findings_overview.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states both the context ('the way to find out why a field is empty in the index') and explicitly points to a sibling tool for complementary functionality: 'use the tester_sessions tool to see which ones exist and are enabled.' It also gives practical guidance about the integration parameter's effect on detection. This is strong when-to-use guidance with an explicit alternative.

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