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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds valuable semantics: `observed` is first-seen date, not in-force date, and warns to say so when reporting. This contextual nuance goes 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.

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

Two tight paragraphs: the first gives purpose and usage in one sentence; the second adds necessary nuance about the date semantics and window. No filler; front-loaded with the core action.

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 read-only feed with two optional parameters, the description covers purpose, polling behavior, date semantics, and limits. An agent can correctly invoke it without further information; output format is noted as JSON, which is sufficient.

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

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

The schema documents `since` with a pattern and description, and `limit` with defaults. The description enriches `since` by defining what 'observed' means and clarifies the recency ordering. With 50% schema coverage, the description compensates meaningfully.

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

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

The description clearly states the tool returns provisions with recently changed text, ordered newest first, as a JSON freshness feed. This is a specific verb-resource-action combination that distinguishes it from siblings like search or getNorm.

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?

Explicit polling guidance is provided: set `since` to the newest observed value already processed. It also notes the 120-day window and contrasts with the law's own Änderungsverlauf, implying alternatives for older data, though it doesn't name the specific sibling tool.

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 readOnlyHint=true, destructiveHint=false, and idempotentHint=true, signaling a safe, non-mutating operation. The description adds valuable context on the tool's return structure ('totals, per-source windows, Aktenzeichen counts, limits') and explains the semantic nuances of 'limits' (version-archive floor, federal scope, version date meaning, source window differences). It also clarifies that the tool does not conflate absence types, which goes beyond the annotations. A small gap is not detailing the exact format or pagination, but that is minor for a zero-parameter read-only tool.

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

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

The description is three sentences long and front-loads the most critical information: the tool's purpose and when to use it. The second sentence lists return elements and constraints, and the third reinforces a key distinction. Each sentence earns its place, though the second sentence is dense and might be slightly overwhelming, but it is not verbose.

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 zero-parameter, read-only tool with a rich description, the description is nearly complete. It covers the tool's scope, what it returns, its limitations, and when to use it. The absence of an output schema is compensated by the detailed description of the return contents. The only minor gap is that it doesn't explicitly state that it requires no arguments, but that is trivially inferred from the zero-parameter schema.

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

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

The tool has zero parameters, so the schema provides no parameter details. The description compensates by explaining the context and what the tool returns, which is more than sufficient for a no-parameter tool. While the schema is trivial, the description's detail on the tool's output ensures an agent understands what it will receive without needing parameter guidance.

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 identifies the tool as reporting corpus coverage with a specific scope ('Corpus scope with its holes stated') and distinguishes it from siblings by clarifying it never collapses 'outside_coverage' with 'not_in_corpus'. It also mentions 'totals' and 'limits' to specify what the tool returns, making its purpose unmistakable.

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 first sentence states a clear condition for use: 'Call this once when your answer depends on whether an absence is real.' It also explicitly tells users not to collapse two different answers, thereby directing when to avoid using this tool and what distinction it maintains. No alternative sibling is named, but the guidance is sufficient for a tool with zero parameters, as the condition is highly specific.

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 mark this as read-only, idempotent, and non-destructive, and the description adds substantial behavioral detail beyond that: case-sensitive abbreviation handling, ambiguous-law fallback with other_laws, version archive boundaries, the distinction between first_observed and legal Inkrafttreten, and trust/citation semantics. This is rich, valuable context.

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

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

The description is long but every section earns its place: core purpose first, then parameter semantics, point-in-time behavior, response fields, and trust guidance. Clear section headers and front-loaded key facts make it easy for an agent to skim and apply.

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 takes on full responsibility for explaining return values and did so thoroughly: version_coverage, outside_coverage, first_observed, valid_to, date_precision, amendment_note, fundstelle, authoritative_source, markdown, url, and other_laws are all mentioned with practical guidance. An agent has what it needs to invoke and interpret the tool correctly.

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 has meaningful schema descriptions and examples. The description adds further semantic nuance for 'law' and 'ref', especially the citation-style abbreviation, case sensitivity, alias resolution, and dropping sub-units. Format is only lightly covered, but the schema enum and default already handle it.

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 opens with a specific verb and resource: it returns 'the text of one provision' as clean Markdown. It clearly distinguishes this from sibling list/version/search tools by emphasizing a single provision in compact form.

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

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

The description gives clear usage context: how to cite law abbreviations, what ref means, how case-sensitivity and ambiguity resolve, and when to use as_of. It does not explicitly name sibling tools or state when not to use this tool, but the context is strong enough for an agent to route correctly.

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 readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral context beyond that: rn is read from the court's own markup and never inferred, anchor_basis values and when pin-citing is safe, amtliche_seite is always null because texts carry no page breaks, pagination appears only when there is more than one page, and around returns not_in_corpus rather than silently returning a different passage. This is rich, honest behavioral disclosure.

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

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

The description is longer than average but every section earns its place: the opening sentence states the core purpose, the rn/anchor_basis paragraph prevents citation misuse, the amtliche_seite paragraph prevents a false expectation, and the SIZE/around paragraphs give operational guidance. It is front-loaded with the most important facts. Slight redundancy in the around paragraph (repeats the centred-window idea) keeps it from a 5.

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 read-only list tool with 4 parameters, no output schema, and no nested objects, the description covers everything an agent needs: what the tool returns, how to identify the case, how to page, how to cite safely, and what to expect when a number is absent. The absence of an output schema raises the burden, and the description meets it by describing the return shape (paragraphs with permalinks, rn, anchor_basis, amtliche_seite, pagination).

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 50%: the schema documents `case` and `around` but not `limit` or `offset`. The description compensates by explaining limit's max (400, enough for a whole decision), offset's role in paging, and around's semantics (centred window, takes a printed number, not combinable with offset). It adds meaning beyond the schema, though it doesn't spell out offset's default or exact paging math, which the schema already provides.

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 opens with a precise statement: 'The full text of one decision, split into its paragraphs, each with a permalink you can cite.' This clearly identifies the resource (case passages), the action (list), and the distinguishing output (paragraphs with permalinks). It also differentiates from siblings like listCitingDecisions and listCitedAuthorities by focusing on the decision's own text rather than citation relationships.

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

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

The description gives explicit when-to-use guidance: 'the right call when listCitingDecisions gave you a citing_rn, when a search hit came back anchored at …#rd_51, or when you want the passage around a pin cite and not the whole judgment.' It also explains when not to use it (when you want the whole judgment, use limit; when you want a specific page, you can't because amtliche_seite is null). It names the alternative navigation methods (offset, limit, around) and their trade-offs.

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 readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds crucial behavioral detail beyond annotations: `treatment` is always null and classifying edges is 'unbuilt work' (with a caution about using a wrong label in a brief), and the tool returns `known_missing` with attestations instead of a 404 for decisions that exist but are not held. This is exactly the kind of nuance an agent needs and is not in 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.

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

The description is about 150 words and front-loaded with the core purpose. The treatment paragraph is somewhat lengthy but each sentence adds value (warning against unbuilt classification). The known_missing sentence is crisp. It is structured but not as tight as a two-sentence ideal.

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 adequately explains the return semantics: statute provisions with counts, decisions relied on, treatment always null, and known_missing behavior. It also points to `listCasePassages` for deeper reading. For a read-only citation listing tool, this is sufficient for correct invocation and interpretation.

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

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

The input schema has 100% description coverage for the single `case` parameter, explaining accepted formats (juris doknr, ECLI, or decision URL from `search`). The tool description adds nothing beyond that, so it correctly relies on the schema. 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?

The description states a specific verb ('list') and resource ('outgoing citation edges of one decision'), and breaks down the two citation types: statute provisions with weighted counts (Normenkette) and decisions relied on. It clearly distinguishes from an incoming-citations tool by the phrase 'outgoing', and the detailed content leaves no ambiguity about what is returned.

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

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

The description implies usage: it is for a single decision's outgoing citations and is read-only. It explicitly directs to `listCasePassages` when you need to read the actual citing passage, which is a concrete alternative. However, it does not mention `listCitingDecisions` as the counterpart for incoming citations, so it lacks an explicit when-not-to-use statement.

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 readOnlyHint, idempotentHint, and destructiveHint, so the description's added context is valuable. It discloses ranking internals (weight → court tier → recency), coverage gaps (Land provisions may yield total:0 even when cited), the bounded nature of 'recent' ordering with fallback to weight, and the meaning of citing_rn. None of this contradicts 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.

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

The description is lengthy but well-structured into clear paragraphs (core modes, ranking, sorting, coverage). Every sentence adds operational value, and key constraints (exactly one mode, check sort_applied) are front-loaded. It could be trimmed slightly, but the density is justified for a tool with this complexity.

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 tool with no output schema, the description covers all critical call-time knowledge: how to select parameters, ranking order, pagination, coverage limitations, and the citing_rn anchor. It explains edge cases like procedural giants and Land provisions, so an agent can call it correctly and interpret results without additional lookups.

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 50% (case, sort, offset have descriptions; law, ref, limit do not). The description clarifies the required pairing of law+ref and the alternative case, explains sorting behavior and pagination via offset, and adds the coverage caveat. While the schema already documents sort and offset, the description adds contextual meaning beyond the raw field definitions, compensating for the half without schema descriptions.

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 states a specific purpose: listing incoming citation edges, with two mutually exclusive query modes (law+ref or case). It clearly distinguishes itself from siblings like listCitedAuthorities by focusing on incoming edges, and explicitly requires exactly one of the two modes, preventing 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?

Provides explicit when-to-use guidance: the law+ref mode for statute provisions, case mode for decisions, and when to pass sort:"recent" for current case law. It also names a fallback to the `search` sibling for Land provisions, and instructs checking `sort_applied` before drawing conclusions. No exclusions are 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?

Though the annotations already declare readOnlyHint and idempotentHint, the description adds substantial behavioral context beyond them: first_observed does NOT mean Inkrafttreten, at_archive_floor indicates a mirroring floor rather than an amendment, and earlier amendments may be listed in the Änderungsverlauf but not held. It even discloses the limitation that no diff is provided and explains why, which helps the agent set expectations.

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?

Every sentence earns its place: purpose, return-field semantics, floor-date caveat, and the no-diff guidance are all substantive. The description is front-loaded with the main use case and is organized in digestible paragraphs without repetition of schema or annotation values.

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 fills that gap by enumerating all meaningful return fields and their semantics. It also explains the critical edge case of archive floor dates and names the amendment_history_url field, making the tool's behavior fully understandable for an agent attempting to use it correctly.

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

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

The input schema has 0% description coverage, so the burden falls on the description to explain law and ref. The description mentions 'one provision' and 'law', but it never explicitly defines law as the statute identifier or ref as the specific provision reference. The schema examples (BGB, 288) help, but the description itself does not compensate for the missing parameter documentation.

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 states a specific action and resource: listing every stored version of one provision, newest first. It also distinguishes the tool from getNorm by explaining that it reveals which as_of dates getNorm can actually answer. This differentiates it clearly from the sibling tools.

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 explicitly says to use this tool before asking getNorm(as_of=…) so you know which dates are answerable. It also gives a strong when-not-to: there is no diff tool, so users should fetch two versions with getNorm and diff them manually. The alternative tool is named and the condition for using it is 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?

The annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, but the description adds substantial behavioral disclosure: normalization reporting (normalised_from/normalised_to), disambiguation via court/date, miss categories, date_mismatch/court_mismatch, docket_completed, fundstelle, and the 300-character stub danger. This far exceeds what annotations alone provide and contradicts nothing.

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

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

The description is long but front-loaded with the most important rule, then organized into clear sections for citation kinds, outcome categories, fundstelle, text behavior, and mismatch flags. Most sentences carry distinct, decision-relevant information, though some length could be trimmed without losing meaning.

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 full burden of explaining return behavior, and it does so thoroughly: miss enumerations, disambiguation evidence, docket completion, gazette fundstelle, text truncation, and mismatch warnings are all covered. Minor omissions like batch-level atomicity do not undermine an agent's ability to call and interpret the tool correctly.

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 adds critical parameter semantics: the court and date must be kept because Aktenzeichen are not unique nationwide, include values are opt-in with unknown values refused rather than ignored, and 'text' returns full text instead of the stub. It also gives concrete accepted citation formats, enriching both parameters well beyond the bare schema.

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

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

The description opens with 'Ground a batch of German legal citations against the corpus,' naming a specific verb and resource, and it is clearly distinct from a bare search or retrieval tool. It enumerates accepted citation kinds, but it never explicitly names or contrasts sibling tools such as search or getNorm, so it stops short of full sibling differentiation.

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

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

The description gives an explicit decision rule: 'Call this BEFORE stating any citation you did not read here.' It also explains how to interpret different miss outcomes (attested vs not_in_corpus) and what the agent may or must not do with them. However, it does not name alternative tools or state when to prefer a sibling, so exclusions are implied rather than explicit.

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?

Beyond the read-only/idempotent annotations, the description discloses important behavior: lexical search with concept pinning for statutes, semantic search for decisions, cross-Land jurisdiction roll-ups, full-text coverage for four Länder, best-match Randnummer anchoring, doknr propagation, and umlaut handling. This is substantial contextual disclosure.

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

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

The description is long but dense, with front-loaded essentials and clear section-like paragraphs. Every sentence contributes useful information, and the examples illustrate rather than pad.

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 complex, two-corpus tool with no output schema, the description covers the important invocation, scope, result-shape, and follow-up workflow. It stops short of describing pagination, result ordering, or exact response structure, but the schema covers limit constraints and the rest is sufficient for correct use.

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 75%, and the description significantly expands meaning for `q` (German, natural-language questions, raw umlauts) and `scope` (why narrowing to norms can fail, default 'all' behavior). It does not add anything about `limit`, but the parameter is relatively self-explanatory.

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 identifies a specific action and resource: 'One query over BOTH corpora: federal and Land statutes ... and court decisions'. It distinguishes this search tool from sibling retrieval/list tools by emphasizing the dual-corpus search behavior and result features like `doknr` and `#rd_51` anchors.

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

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

The description gives explicit when-to-use and when-not-to-use guidance: 'Search both unless you have a reason not to', warns that scope='norms' alone reads as empty for terms of art, recommends natural-language questions for case law, and tells the agent how to proceed with sibling tools using `doknr`.

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