Server Quality Checklist

Tool Scores

• delete_traceA
  4.6/5.0
  Behavior5/5

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

  Annotations already signal destructiveness, but the description goes far beyond that: spans cascade, evaluations keep verdicts but lose text, erased_at is stamped, deleted=false for absent/foreign traces is not an error, and no audit entry is written. It also discloses error behavior and malformed-id refusal, which is valuable execution context.

  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 clear sections, and the core action is front-loaded. There is some redundancy between the opening sentence and the 'What it does' section, but the richness of behavioral detail justifies most of the length.

  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 destructive delete tool with an output schema, the description covers inputs, side effects, return semantics, error format, and exclusions. Nothing an agent needs to decide whether to call it and interpret the result is missing.

  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 100% and the single parameter trace_id is already fully documented with format and provenance. The description adds no new semantic details about the parameter itself, so baseline 3 is appropriate.

  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 precise verb-resource statement: 'Remove one stored trace by id', and immediately distinguishes the tool from siblings like delete_rule. It names log_trace and get_traces as the sourcing/finding counterparts, so an agent can orient without opening schemas.

  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?

  It explicitly covers when to use the tool and, more importantly, when not to use it: bulk retention expiry, deleting evaluations, or pausing traces. It also names the sibling delete_rule as the equivalent for custom rules, giving the agent a clear decision boundary.

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

• log_traceA
  4.6/5.0
  Behavior5/5

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

  Annotations only indicate readOnlyHint=false, openWorldHint=false, idempotentHint=false, destructiveHint=false. The description goes far beyond those hints: it discloses that traces are immutable with no update path, that resubmission stores a second trace (no deduplication), that the local write never waits on the best-effort async OTel export, and that authentication is optional in stdio mode but requires a Bearer token over HTTP when an API key is configured. It also explains error behavior and return shape. No contradiction with annotations; the description carries the full burden and succeeds.

  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 every section earns its place and is heavily front-loaded: the first sentence states the core action and the returned key. The 'What it does', 'When not to use it', 'Returns', 'Errors', and 'Siblings' labels give it scannable structure. It is verbose, but the density of decision-relevant information justifies the length. Loses one point for minor redundancy (e.g., restating evaluate_output reuse in both the What and param description).

  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 an output schema exists (describing the return JSON), 11 parameters with 100% schema coverage, and a rich nested schema, the description is complete. It covers the operation's side effects (immutable write, second trace on resubmit), error contract, authentication nuance, and sibling routing. An agent has everything needed to decide when to call log_trace and what to expect.

  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 100%, so the schema already documents all 11 parameters in detail (e.g., agent_name is used for filtering in get_traces, cost_usd overrides per-span aggregation, metadata is queryable in dashboard but not via get_traces filters). The description adds cross-parameter context (tool_calls for trajectory rules, cost_usd/token_usage for cost rules, input/output for everything else), but much of that is already in the field descriptions. Baseline 3 is appropriate: the description complements rather than 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 description opens with a precise verb-object pair, 'Store one agent execution', and enumerates exactly what a trace captures (input, output, tool calls, spans, cost, latency, token usage) and what it returns (trace_id). It clearly distinguishes log_trace from siblings like evaluate_output and get_traces by naming them and their purposes. This is a specific, actionable statement of what the tool does.

  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 'When not to use it' section explicitly routes the agent: use a logger for transient log lines, call evaluate_output after logging to score, and use delete_trace then log again to modify a stored trace. It also gives a conditional alternative (IRIS_OTEL_ENDPOINT export behavior). This is exemplary guidance for selecting log_trace versus alternatives.

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

• verify_citationsA
  4.6/5.0
  Behavior5/5

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

  Beyond annotations, the description discloses: fetch is opt-in via allow_fetch or env var, SSRF protections (scheme allowlist, blocked private/cloud-metadata addresses, hostname allowlist, timeouts, byte caps, redirect limits), cost caps, per-citation failures never scored as unsupported, one evaluation row stored, and the null-verdict behavior including a 0.10.0 change note. It also explains errors like IRIS_JUDGE_FAILED. Annotations are minimal (readOnly=false, openWorld=true, idempotent=false, destructive=false), so the description carries the burden and does so thoroughly.

  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 earns its length: it uses labeled sections (What it does, When not to use it, Returns, Errors, Siblings) and front-loads the headline behavior. Some redundancy exists (e.g., 'When not to use it' repeats the key requirement mentioned in the opener), and the Returns section is dense, but the structure makes it navigable.

  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 10-parameter, complex tool with an output schema, the description covers the pipeline phases, error codes, env var interactions, security posture, edge cases, and return fields. The output schema exists, so the description need not spell out return shapes, but it still summarizes them and adds the critical behavioral notes about passed/NULL and stored evaluations. Nothing essential is missing.

  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 100%, so the schema documents every parameter meaning. The description adds operational context that interacts with parameters — e.g., allow_fetch defaulting from env, domain_allowlist merging with env, max_citations extras being skipped, max_cost_usd_total behavior — but the core semantic meaning per parameter is already in the schema. Baseline 3 is appropriate.

  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 phrase — 'Extract the citations in an output, fetch the sources (opt-in, SSRF-guarded) and ask an LLM judge on your key whether each source supports its claim.' This precisely states the tool's operation and resource. It differentiates from siblings by name ('verify_citations') and behavior, and the Siblings section explicitly distinguishes it from evaluate_with_llm_judge and evaluate_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 includes an explicit 'When not to use it' section naming concrete conditions: no citations, no key, and the risk of an open allowlist on untrusted output. It even points to evaluate_output's hallucination signals as the cheap alternative. This is exemplary guidance for when to use the tool vs alternatives.

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

• evaluate_with_llm_judgeA
  4.8/5.0
  Behavior5/5

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

  The description goes far beyond annotations, disclosing that Iris never proxies, that spend is pre-computed and capped before the call, that rate-limited calls retry once, that temperature defaults to 0, and that a row is stored with provider response id/tokens/cost/latency. It even explains that self_reported_pass is recorded but never obeyed, and that the pre-check refuses before spending. No contradiction with annotations (readOnlyHint=false, destructiveHint=false) — the write/store behavior is consistent.

  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 every section earns its place: What it does, When not to use it, Returns, Errors, Siblings. It is structured with headers and front-loaded with the essential purpose and cost/behavior caveats. Some redundancy exists (the template requirements are stated both in prose and in schema descriptions, and the return field list is exhaustive), but the structure makes it navigable and scannable. Not a 5 because it could be tightened by trimming the full return-field enumeration that the output schema already documents.

  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 12-parameter, externally-calling, cost-bearing tool with an output schema, the description covers everything an agent needs: what happens before the call (budget pre-check, trace validation), what happens during (retry, direct provider call), what is returned (mapped to the output schema), what errors look like (codes + recovery), and explicit when-not-to-use conditions. The error-code enumeration is especially valuable because the output schema exists but the error shape is partially described. This is as complete as a description of this complexity practically needs to be.

  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 100%, so the baseline is 3, but the description adds substantive meaning beyond the schema: it explains template-purpose mapping in prose, clarifies model cost variance ('hundredfold'), states how max_cost_usd is applied ('worst case computed before the call'), and defines temperature default determinism. It doesn't fully re-explain every parameter, but it enriches the key decision parameters enough to push above baseline.

  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 ('Score an output'), a precise resource ('with an LLM judge on your own provider key'), and enumerates concrete outputs (0..1 score, rationale, sub-scores, spend). It clearly distinguishes itself from siblings by naming exactly what it is not (evaluate_output, verify_citations) and describing its provider-direct behavior. An agent can identify what this tool does without guessing.

  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 contains an explicit 'When not to use it' section that names alternatives (evaluate_output for deterministic checks) and conditions (no key -> not enabled; large outputs -> budget refusal). It also explains template selection requirements (correctness needs expected, faithfulness needs source_material) and how provider/model relate. This is comprehensive routing guidance beyond what the schema provides.

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

• delete_ruleA
  5/5.0
  Behavior5/5

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

  Goes far beyond the destructiveHint annotation by disclosing the exact file modified, audit entries written, engine unregistration, persistence across restarts, no impact on past evaluations, error shape, and malformed-rule_id rejection. This gives the agent a rich behavioral model.

  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 tightly organized under clear labeled sections ('What it does', 'When not to use it', 'Returns', 'Errors', 'Siblings'), and the first sentence front-loads the core behavior. Every sentence contributes necessary information for a complex destructive/toggle tool.

  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?

  Covers side effects, timing, return values, error recovery, exclusions, and sibling routing. Even with an output schema noted, the operational nuances described here are essential and nothing critical is missing for an agent to call this tool correctly.

  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 coverage is 100%, so the baseline is 3, but the description adds critical operational meaning: omitting enabled means delete, enabled: false stops firing immediately while preserving history, enabled: true restores the same id, and return fields differ between delete and toggle modes. This materially improves correct invocation.

  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?

  States a specific verb and resource: 'Remove a deployed custom rule — or, with enabled, disable or re-enable it'. It clearly distinguishes this tool from siblings by naming delete_trace, deploy_rule, and the built-in rule exclusion, so an agent can select it correctly without ambiguity.

  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?

  Contains an explicit 'When not to use it' section naming alternatives and conditions: built-in rules cannot be modified, trace deletion belongs to delete_trace, and rule replacement belongs to deploy_rule with replace: true. This is ideal routing guidance.

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

• deploy_ruleA
  5/5.0
  Behavior5/5

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

  Annotations only indicate it is not read-only, not idempotent, and not destructive. The description substantially exceeds them by disclosing file writes, audit entries, engine registration, restart persistence, unique-name refusal, replacement semantics, and detailed error behavior. No contradictions with annotations.

  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 deliberately structured with clear sections: what it does, when not to use it, returns, errors, and siblings. It front-loads the core behavior in the first sentence and every paragraph covers a distinct needed concern.

  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 complex nested schema and 9 parameters, the description covers side effects, return shape, error codes, recovery behavior, and sibling relationships. An agent has enough information to decide when to call it, construct a valid definition, and interpret outcomes.

  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 coverage is 100%, but the description adds meaning beyond the schema: alias handling, the 'all' eval_type behavior, severity's hard-fail impact, definition.config key mapping, and rejection of unknown keys. It compensates richly for any ambiguity left by the 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 opening sentence states a specific action and resource: deploying a custom rule that fires on future evaluate_output calls, with persistence, immediate activation, and auditing. It clearly distinguishes this from siblings like list_rules and delete_rule.

  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?

  Includes an explicit 'When not to use it' section naming preview, evaluate_output's custom_rules argument, and delete_rule for pausing. This gives an agent concrete routing guidance for alternatives.

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

• evaluate_outputA
  5/5.0
  Behavior5/5

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

  The description heavily exceeds the annotations' coverage: it states 'In-process, no network, no key', says 'One row is stored, linked to trace_id when given', describes skip semantics for missing inputs, and enumerates error codes (IRIS_UNKNOWN_TRACE, IRIS_STORAGE_ERROR) with recovery guidance. It does not contradict annotations such as idempotentHint or destructiveHint.

  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 tightly sectioned with clear headings: What it does / When not to use it / Returns / Errors / Siblings. The core purpose is front-loaded, and each section carries non-redundant information needed for a 9-parameter tool with a rich output schema. No filler or tautology is present.

  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?

  Despite already having an output schema, the description still summarizes all key return fields, error conditions, default behavior, and skip conditions, making the tool's full contract explicit. It also names siblings and distinguishes their scope, so nothing essential for correct invocation 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?

  Schema coverage is already 100%, but the description adds critical behavior beyond the schema: input is 'REQUIRED when eval_type="relevance"', cost_usd is read by the cost bundle and any cost_threshold custom rule, expected 'feeds only expected_coverage', and tool_calls 'SKIP rather than pass' if omitted. custom_rules 'always fire' regardless of eval_type. This goes far beyond the standalone parameter descriptions.

  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 'Score an agent output against the deterministic rule bundles' — a specific verb, object, and judgment mechanism. It further distinguishes itself from siblings by naming them in the Siblings section ('evaluate_with_llm_judge — semantic scoring on your key; verify_citations — citation grounding'). An agent can quickly tell this is the deterministic rule-based evaluator.

  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?

  There is an explicit 'When not to use it' section that names three alternative cases — JSON Schema validation, input screening, and semantic judgment — and points to the correct sibling for each. It also explains eval_type bundle selection, the default ('Defaults to "all"'), and when to use custom_rules alone with eval_type='custom'.

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

• get_tracesA
  5/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint and idempotentHint, and the description reinforces and extends this by stating read-only, local-storage-only behavior. It also discloses exact-match semantics, inclusive time bounds, LATEST-eval score filtering, crossed-range refusal, error shape, empty-result behavior, and the absence of an event stream — far beyond what annotations alone convey.

  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 well structured with clear headings (What it does, When not to use it, Returns, Errors, Siblings) and a front-loaded summary sentence. Each section earns its place by covering important behavior, errors, and routing for an 11-parameter tool, so the length is appropriate to the complexity.

  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, 11 parameters, and rich annotations, the description is complete: it covers filters, pagination, sorting, optional summary, return shape, error codes, empty results, and sibling differentiation. An agent has everything needed to invoke it correctly and handle failures.

  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 coverage is 100%, but the description adds material meaning beyond the schema: exact-match vs wildcard behavior, inclusive bounds, score applied to the LATEST evaluation, default sort order, and the crossed-range validation rule that names both offending values. This is genuinely helpful parameter semantics rather than schema repetition.

  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 line states a specific verb and resource — 'Query stored traces with filters, pagination and sorting' — and the tool is immediately distinguished from siblings in the Siblings section. The description also names what it is not for (scoring, creating, live streaming), so an agent can tell it apart without inspecting other tools.

  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?

  There is an explicit 'When not to use it' section that names alternatives (evaluate_output, log_trace) and explains that this is a query, not a live stream, with polling guidance. This gives clear routing rules both for when to use the tool and when to choose a sibling.

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

• list_rulesA
  5/5.0
  Behavior5/5

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

  Annotations already declare the tool read-only and idempotent, and the description adds substantial behavioral context: no network access, built_in is never filtered, filters apply only to custom rules, quarantined rules do not fire, and a missing store file is treated as an empty list rather than an error. The error response shape is also disclosed, which goes well beyond the annotations.

  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 exceptionally well structured with clear sections: What it does, When not to use it, Returns, Errors, and Siblings. Every section answers a likely agent question, and the most important scoping information is front-loaded.

  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 description covers purpose, parameter behavior, return structure, error handling, non-usage cases, and sibling relationships. Given the tool's complexity, this is complete enough for an agent to invoke it correctly and interpret its response without additional probing.

  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?

  Although schema coverage is 100%, the description adds important semantic detail: eval_type only filters custom rules and never built_in, and enabled_only interacts with delete_rule semantics (disabled rules stay in the store but do not fire). This goes beyond the schema's short descriptions and clarifies edge behavior.

  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 defines the tool as a rule inventory covering both built-in and custom rules, listing exact fields returned and the distinction between the two stores. It also explicitly names sibling tools to contrast with, so an agent can select this tool without ambiguity.

  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 'When not to use it' section names the exact alternatives (get_traces, deploy_rule, delete_rule) and explains that built-in rules cannot be modified. This gives an agent concrete routing guidance and exclusion criteria, which is more than most tool descriptions provide.

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