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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld=false, so the safety profile is covered. The description nonetheless adds real behavioral context: entries are never merged or ranked, payload is roughly 3 KB per entry with 50+ entries, results are informational only, and as_of requires a plan with as-of queries.

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?

Front-loaded with the core capability and an inline example, and every sentence carries information. It is dense but not padded; only mild redundancy exists between the as_of note and its schema pattern.

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?

No output schema exists, yet the description tells the agent the entry shape (same as get_rule), the approximate volume and size of results, the default scope, and the auth precondition for as_of — enough to call correctly and anticipate the response.

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 100%, so the baseline is 3, but the description goes beyond it by spelling out the default jurisdiction set and its size, a worked example payload, and the API-key constraint on as_of — details the schema cannot express.

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?

States a specific verb and resource (get one rule type across jurisdictions), the batch scope (in one call), and anchors the output shape to the sibling get_rule, so an agent can tell it apart from get_rule/get_rule_as_of without opening any schema.

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?

Explicitly describes what happens when jurisdictions is omitted (every state and province, or the named level) and notes level is the alternative selector to jurisdictions. It stops short of an explicit 'use get_rule for a single jurisdiction' routing sentence, but the relationship is strongly implied.

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

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

The annotations already declare readOnly, idempotent, non-destructive and closed-world, and the description goes well beyond them: it documents the return envelope (data, schema_url, effective_from, verified_at, id, verification, disclaimer) and, critically, the layering behavior — stacked levels come back as separate entries in `layers` and are never merged. That non-merge rule is exactly the kind of behavior an agent could otherwise get wrong.

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?

Core purpose and scope are front-loaded in the first clause, and the example is placed before the return-shape detail. The middle section is dense with colons and parentheticals, but nearly every clause carries information; only the enumeration of response keys could be trimmed.

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?

There is no output schema, so the description must carry the return contract, and it does: it names each top-level response field, dates it, explains the `layers` semantics, and adds the informational-only disclaimer. Nothing an agent needs in order to call this 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.

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

Schema description coverage is 100%, so both required parameters and the optional `domain` are already fully documented, including pointer to list_rule_types and list_jurisdictions. The description adds only a concrete call example, which is mildly useful but does not explain the optional `domain` fallback behavior itself. Baseline 3 is appropriate.

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?

States a specific verb and resource ("get the rule in force today") plus the scoping to one rule type and one jurisdiction, and adds that the citation is included. The phrase "in force today" implicitly distinguishes it from get_rule_as_of and get_rule_history, so an agent can place it among siblings 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.

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

The temporal qualifier "in force today" plus the pointer to resolve_version ("the version id to record with any decision that relies on it") tells the agent when this tool is the right call and what downstream action follows. It never explicitly says to use get_rule_as_of for past dates or get_rule_history for change tracking, so sibling routing is left partly to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world. The description adds real behavioral context beyond them: out-of-coverage dates return an error naming where coverage starts, plan-gated access returns a distinct error, and it carries an 'informational only, not legal advice' disclaimer plus the fact that future dates are valid.

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?

Front-loaded with the core behavior, then the example, then usage and edge cases. Dense and mostly waste-free; the legal disclaimer is slightly boilerplate but is arguably required for this domain.

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?

No output schema exists, but 'in the same shape as get_rule' plus the sibling tool list lets an agent infer the return structure. Error modes and an example call are covered. Only minor gap is not restating what happens with the optional domain parameter.

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 100% and each parameter is documented, so the baseline is 3. The description goes further with a full example call showing valid values for rule_type, jurisdiction, and as_of together, which conveys format and expected slug conventions better than the schema alone.

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?

States a specific verb (get), resource (the rule), and temporal scope (in effect on a date), plus the key differentiator 'in the same shape as get_rule'. That implicitly separates it from get_rule (current) and get_rule_history (change log) without ambiguity.

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?

Gives a concrete scenario: 'Use it to see what applied when a past decision was made.' It also covers the failure paths (pre-coverage dates, plan without as-of support). It stops short of explicitly routing to get_rule for the current rule, but the 'same shape as get_rule' framing makes that distinction inferable.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds value beyond them by disclosing the returned shape (effective dates, values, citation) and the status taxonomy current/superseded/withdrawn, plus the informational-not-legal-advice caveat. It says nothing about result size or pagination for a history that is potentially unbounded.

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?

Front-loaded with the scope and output facets, followed by the example, the exclusion, and the cross-reference to resolve_version. Dense but every sentence carries information; the trailing 'Informational only, not legal advice' is the only line that is closer to boilerplate than instruction.

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?

There is no output schema, and the description compensates by enumerating return fields and status values, which is exactly what an agent needs to interpret results. Combined with annotations covering safety and the schema covering all three parameters, nothing essential to correct invocation is missing beyond pagination behavior for large histories.

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 100% with per-parameter descriptions for domain, rule_type and jurisdiction, so the schema carries the semantics. The description's only added meaning is a concrete paired example (`minimum_wage` + `us-wa`) showing how the two required slugs combine. That is marginal on top of an already complete schema, so baseline 3 applies.

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?

States a specific verb+resource+scope: 'List every version ever published of one jurisdiction's rule', and enumerates the returned facets (effective dates, values, citation, status). The scope clause 'Covers that jurisdiction's own rule only; other levels that apply (e.g. us) are separate calls' lets an agent distinguish this from get_rule / get_rule_as_of / list_changes without opening any schema.

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?

Gives clear context for when this is the right call (full version history for a single jurisdiction) and explicitly scopes out other jurisdiction levels as separate calls. It also routes forward by noting each entry's `id` can be passed to resolve_version. It stops short of naming get_rule or get_rule_as_of as the alternatives for current or point-in-time lookups.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint false, closed world), and the description builds on that with ordering, the fields each change carries, pagination via has_more/cursor, and the version id to hand to resolve_version. It goes further with an auth prerequisite ("Needs an API key whose plan includes the change feed; otherwise the error says so") and a scope disclaimer, which are exactly the behaviors annotations cannot express.

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?

Front-loaded with purpose and ordering, then mechanics, then the auth caveat, which is a sensible progression with no repeated clauses. It is dense and runs long for a list tool, and the trailing "Informational only, not legal advice" is boilerplate that does not help an agent invoke it, though it is only one clause.

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?

There is no output schema, yet the description still tells the agent what comes back (rule identity, from/to versions, effective date, version id) and how to detect and handle more pages. Together with the auth and jurisdict ion caveats, nothing needed to call this six-parameter tool correctly is missing.

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 100%, so the schema already defines every parameter and the baseline is 3. The description earns above that by supplying a full example payload and, critically, explaining the consequence of the jurisdictions array — that each slug matches only its own rules, so multi-level coverage requires listing both levels. That practical implication is not derivable from the schema's terse "each matches its own rules only".

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?

States a specific verb and resource ("List changes to published rules") and enumerates exactly what a change is: new versions, amendments, corrections, repeals. It also specifies ordering ("oldest first"), which separates it from a point-in-time sibling like get_rule_as_of, so an agent can distinguish it from the surrounding tools without opening a schema.

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?

Gives concrete operational guidance: a worked example call, the cursor loop ("While `has_more` is true, call again with the response's `cursor`"), and the non-obvious jurisdiction rule about also passing the federal level for complete Washington coverage. It does not explicitly route away from alternatives such as get_rule_history for a single rule, so the when-not-to-use case is left implicit.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile needs no restating. The description still adds real context beyond them: it discloses the return shape (slug, name, level, parent), the level vocabulary, and the example slug mappings the agent will need downstream. It does not cover ordering or result size, which is a minor gap for a registry listing.

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?

Four short sentences, front-loaded with the purpose, then the critical routing fact, then the return shape, then the no-argument case. No filler and no repetition of the schema beyond what reinforces the workflow.

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?

For a single-parameter, read-only lookup with no output schema, the description supplies everything an agent needs: how to call it, what comes back, the enumerated level values, and example conversions. Nothing essential is missing.

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 100%, so 3 is the baseline, but the description goes further by explaining why the parameter matters: the slug this query resolves to is what every other Juriset tool consumes, with concrete name/abbreviation-to-slug examples. That downstream framing is meaning the schema does not convey, lifting it above baseline.

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?

States a specific verb and resource ('List the US and Canadian jurisdictions Juriset covers') plus the secondary mode ('find one by name'), and explicitly bounds it against the rule-oriented siblings with 'Reads the registry; no rule lookup.' An agent can distinguish this from get_rule or compare_jurisdictions without opening any schema.

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?

Gives the decisive routing rule — 'The other Juriset tools take slugs, not names' — which tells the agent to call this first to resolve a name into a slug, and gives the exclusion ('no rule lookup') for when to use a sibling instead. 'Omit `query` for all of them' closes the remaining ambiguity about the no-argument case.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered; the description reinforces it with "Reads the registry; no rule lookup." It adds genuinely useful behavior beyond annotations by spelling out what each entry contains — slug, domain, description, the `override`/`max`/`stack` combination semantics, and a described JSON Schema for `data`. It does not mention result size or pagination behavior, which keeps it off a 5.

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?

Three sentences, front-loaded with purpose and entry contents, then the filter, then the scope boundary. Every clause carries information: the field list, the combination-mode enum values, and the "no rule lookup" limit. No filler or restatement of the title.

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 output schema, the description carries the burden of describing return values and does so field by field, including the `override`/`max`/`stack` semantics an agent needs to interpret results. For a one-optional-param read tool this is nearly complete; only pagination/volume expectations are unaddressed.

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 100% on the single parameter, and the schema already labels `domain` with example values. The description only restates that the filter is optional and names an example domain, adding little beyond the structured field. Baseline 3 is appropriate when the schema does the work.

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?

States a specific verb and resource ("List the kinds of rule") plus a scope boundary ("Reads the registry; no rule lookup"), and explicitly ties entries to the `rule_type` argument of the other tools. Concrete examples (`minimum_wage`, `overtime`, domain `employment`) make it distinguishable from `get_rule`, `list_jurisdictions`, and `list_changes` without opening any schema.

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 closing clause "Reads the registry; no rule lookup" plus the `rule_type` reference implies this is the discovery step before calling `get_rule`/`get_rule_as_of`, and the optional `domain` filter is signalled. It stops short of naming the alternative explicitly ("to fetch an actual rule, use get_rule"), so the exclusion is inferable rather than stated.

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

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

Annotations already declare read-only, idempotent, closed-world, non-destructive behavior, so the description's added value is the permanence guarantee that a resolved version is retrievable even after supersession or withdrawal. It also enumerates the returned content (values, effective dates, citation, verification record and status today) and adds a 'not legal advice' disclaimer. What is missing is behavior on an unknown/unknown-format id, which the annotations do not cover either.

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 permanence guarantee and the returned-content list are front-loaded in the first sentence, and the practical uses follow immediately. The opening sentence is heavily clause-stacked with commas and colons, which slightly hurts scanning, but no sentence is filler.

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 one fully documented parameter, no output schema, and annotations covering the safety profile, the description supplies everything an agent needs: input provenance, the immutability semantics that make this tool distinct, and a summary of what comes back.

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 100% and the schema already states that version_id is a version id from a rule response's `id`, including the same example format. The description reinforces provenance and the `rv_…` prefix but adds no meaning beyond the structured field, so the baseline 3 applies.

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 names a specific verb and resource ('Get exactly the version a stored id names') and pins the scope with a differentiator that separates it from date-based siblings: 'forever, even after it was superseded or withdrawn.' An agent can tell this resolves a stored version id rather than fetching a rule by date (get_rule_as_of) or its history (get_rule_history).

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?

It gives concrete when-to-use scenarios ('re-check the value a decision relied on', 'show an auditor which rule applied') and explains where the input id comes from. It stops short of naming which sibling to use instead when you don't already hold a version id, so an agent must infer the alternative from the other tool names.

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