PRIMAMCP

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: paragraph-level matching, newest-first ordering, return of Leitsatz and ECLI, exposure of a cited_norms array, direct resolution of German/EU provisions, alias reverse-mapping, and the compact EURL form for unresolved instruments. No contradiction with annotations exists.

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 it is information-dense and front-loaded with the core purpose and sibling differentiation before diving into matching and resolution details. Each section adds distinct operational value, though the EU alias-resolution details could arguably be tightened 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?

Given the tool's complexity, the description covers everything an agent needs: court population, ordering, matching semantics, return contents, the cited_norms array, integration with legal_lookup, and resolution behavior for EU instruments. An output schema exists, so return-value details do not need to be repeated in the description.

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?

Although schema coverage is 100%, the description adds meaningful semantics beyond the schema: paragraph-level matching ('§ 280 Abs. 1 BGB' finds all decisions citing § 280 BGB), the distinction between directive articles and transposition norms, the behavior of EU regulations, and how cited_norms elements can be fed back into legal_lookup. This materially helps an agent choose and format the cited_norm parameter correctly.

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 ('List'), a precise resource (court decisions from German federal/state courts and EU courts), and a clear scope ('citing a specific legal provision — the raw citation inventory, newest first'). It also distinguishes itself from legal_search by explicitly noting legal_search ranks candidates against a question, while this tool returns the raw inventory.

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 explicitly contrasts this tool with legal_search: legal_search with the cited_norm filter searches the same population but ranks against a question or fact pattern. It also instructs the agent to pass cited_norms elements back to legal_lookup to walk the citation graph, and notes that a plain legal_search reveals an unknown transposition norm. This is clear when-to-use and when-not-to-use guidance.

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 read-only, idempotent, non-destructive profile. The description adds meaningful context that the result includes the target norm plus up to 10 neighbors in each direction, which clarifies behavior beyond the schema.

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

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

The description is compact and front-loaded with the core behavior, then adds the prerequisite and alternative tool in efficient sentences. There is slight redundancy between 'adjacent norms before and after' and 'Returns the target norm plus up to 10 neighbors', but it remains well structured.

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

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

Given the simple parameter set, rich annotations, and existing output schema, the description covers the essential context: what it returns, how many neighbors, where the norm_id comes from, and which sibling tool to use for broader overview. Nothing critical 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 parameters are already well documented. The description adds context about directions and limits, but doesn't provide significant new meaning beyond what the schema already states.

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') and resource ('adjacent norms/paragraphs/articles before and after a target provision'). Clearly distinguishes itself from siblings by describing document-order neighborhood retrieval.

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 requires a norm_id from legal_search or legal_lookup, describes the type of question it serves, and contrasts itself with legal_get_toc for law-wide context. No ambiguity about when to use it.

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 indicate readOnly, idempotent, and non-destructive behavior, so the bar is about added context. The description adds return ordering ('newest first'), output fields ('BT-Drs.', reasoning text, 'target_norm_keys'), the no-materials behavior for unknown/non-German provisions, the non-binding weight of the Begründung, and the fact that excerpts come from Bundestag-extracted text rather than the original PDFs.

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 sentence adds decision-relevant information: purpose, interpretive weight, usage scenarios, input format, output shape, sibling distinction, coverage limits, and source caveat. The primary action is front-loaded in the first sentence, and the rest is structured logically.

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 legal research tool with this complexity, the description covers what it returns, how it orders results, what input to pass, what scope limitations apply, how to interpret the evidence weight, and how it differs from the closest sibling. Nothing essential for an agent to select and call it 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 description coverage is 100%: both 'norm' and 'limit' are already fully described in the input schema. The description repeats the provision format ('§ 823 BGB', 'Art. 87a GG') and adds contextual guidance about scope, but it does not add meaningfully new parameter-level semantics beyond what 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 specific verb and resource: 'Return the official legislative reasoning (Gesetzesbegründung ...) for a specific German federal provision.' It also explicitly separates this tool from legal_find_citing_decisions by contrasting legislative intent with court application, so an agent can distinguish it from its siblings without inspecting 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?

It explains clearly when to use the tool: for questions about ratio legis, undefined terms, planwidrig gaps, deliberate silences, and amendment intent. It also names the alternative sibling legal_find_citing_decisions and states the boundary: this covers drafting intent, the other covers how courts apply a norm. It additionally notes the 1949-present and German-federal-law-only scope.

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, and destructiveHint=false, covering safety. The description adds detail about the nature of the statistics (database and search index, specific counts), which is useful but minimal. No contradiction 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.

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

The description is two sentences with no wasted words. It front-loads the core function (getting statistics) and then provides usage context. Every sentence earns its place.

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?

The tool has no parameters, the annotations fully disclose safety and idempotency, and an output schema exists to define the return format. The description covers the tool's purpose and use cases completely for an agent to decide when to call it.

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 and the schema is an empty object (100% coverage). The description does not need to explain parameters since none exist. Baseline of 4 is appropriate for a no-parameter tool.

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 retrieves database and search index statistics, listing specific counts (laws, norms, indexed vectors). It uses a specific verb (get) and resource (stats), and is distinct from all sibling tools, which focus on searching, looking up, or retrieving materials rather than corpus statistics.

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 explicitly states when to use the tool: for health checks or understanding the scope of the legal corpus. It does not mention alternative tools, but no sibling tool serves this purpose, so the guidance is clear and sufficient.

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 correctly aligns with them. It adds useful behavioral context beyond annotations: results come in document order, large laws are paginated, and returned norm_ids can be passed to legal_get_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 short and front-loaded, with the core purpose in the first sentence and only two supplementary facts added: integration with legal_get_context and pagination. 'Gives the overview of a law's structure' is slightly redundant with the first sentence, which prevents 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?

Given the rich fully documented schema, output schema, and read-only annotations, the description provides the missing behavioral context: what the TOC contains, ordering, pagination, and how norm_id connects to legal_get_context. 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.

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

Schema description coverage is 100%, so the schema already fully documents law_abbreviation, limit, offset, language, and source_type. The description adds no parameter-level detail, so the baseline of 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 uses a specific verb and resource: 'Get the table of contents of a specific law or court decision.' It also enumerates the returned content (norm keys, titles, chapter headings) and document order, making the tool clearly distinct from siblings like legal_get_context or legal_search.

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 explicitly positions the tool as providing an overview of a law's structure and states that a returned norm_id feeds legal_get_context for full text, giving an agent a clear workflow. It does not explicitly enumerate when not to use it or compare it with search/lookup tools, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds meaningful behavioral context: unfiltered results can contain thousands of entries, and EUR-Lex stores official long titles so short names/numbers may miss existing laws. These caveats go beyond structured fields and help 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?

Three tightly written paragraphs: first states the core function, second gives filtering and sibling-tool guidance, third clarifies edge-case behavior. Every sentence earns its place and important caveats are front-loaded near the top.

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

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

Given the tool's complexity (7 parameters, rich enums), the schema descriptions cover parameter semantics, annotations cover safety/idempotency, an output schema exists, and the description covers purpose, filters, caveats, and alternatives. Nothing essential for correct selection or invocation 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 the baseline is 3. The description adds a practical recommendation to pass a search term or source_type for focused responses, but it does not add new semantics for individual parameters beyond what the detailed 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 specific verb-resource pair ('List available laws, regulations, and court decisions') and states the exact fields returned per entry. It clearly differentiates itself from siblings by naming legal_get_toc for structure and legal_lookup/legal_search for existence checks.

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 guidance: use this tool to discover valid law abbreviations for legal_search, use legal_get_toc for a listed law's structure, and use legal_lookup/legal_search as the existence check for a specific law. It also advises passing a search term or source_type to handle unfiltered listings.

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, and destructiveHint=false. The description adds meaningful behavior beyond that: citation order flexibility, the fact that decision lookups return only the lead section, the language-corpus selection mechanics, and the separate DE/EN corpora. No contradiction 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.

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

The description is dense but efficient. Each sentence earns its place: first sentence gives the core purpose with examples; second sentence clarifies flexibility; third sentence explains return scope and links to sibling tools. It is front-loaded with the primary use case and avoids fluff.

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

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

Given that an output schema exists, the description need not describe the return structure. It covers citation formats, flexible input, language selection, decision-lookup behavior, and follow-up tool routing. Together with the annotations and schema, an agent has everything needed to decide and invoke 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 description coverage is 100%, but the description still adds substantial semantic value: it enumerates exact citation formats, explains the flexible ordering of citation components, and clarifies language corpus behavior (default 'de' vs. smaller 'en' corpus, separate entries per language). This goes well beyond the schema's basic field 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 verb ('Get the full text') and resource ('specific legal provision by exact citation' or 'court decision by Aktenzeichen or ECLI'). It gives concrete format examples and clearly differentiates from sibling tools like legal_search and legal_get_toc by specifying that it handles exact-citation lookups only.

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 explicitly routes to alternatives: a decision lookup returns only the Leitsatz and further sections are reachable via legal_get_toc or legal_get_context on the returned norm_id. This tells the agent not only when to use the tool, but what it does not do and which sibling to use next.

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 readOnlyHint, idempotentHint, and destructiveHint annotations, the description discloses exact-match-only behavior, not-found results appearing as found=false, accepted citation forms including court-decision references, and the 1-20 input bound. This gives an agent a clear behavioral model without needing to call the 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?

Three compact sentences front-load the core purpose and then cover exact-match behavior, examples, and routing advice. There is no filler or repetition of schema content; every sentence earns its place.

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 the annotations, output schema, and this description, an agent has the purpose, accepted input forms, exact-match semantics, max batch size, and the alternative for fuzzy cases. Nothing essential for correctly selecting and invoking the tool 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% and already documents the citations and language parameters. The description adds value by giving concrete accepted forms such as '§ 823 BGB', 'Art. 6 DSGVO', and 'VII ZR 184/14', and by linking citation format to legal_lookup, which goes beyond the bare schema description.

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 the tool's function with a specific verb and resource: 'Look up full text of multiple legal provisions in a single call (exact match)'. It also names legal_lookup as the related tool and clarifies this is the batch exact-match variant, making it distinguishable from siblings.

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 routing advice: 'Returns exact matches only' and 'For fuzzy matching of hard-to-find provisions, use individual legal_lookup' names the alternative and the condition that selects it. The 'single call' phrasing plus the 1-20 citation limit makes the intended multi-citation use case clear.

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 agent knows this is a safe read operation. The description adds substantial behavior beyond that: results are ranked with snippets not full text, query phrasing affects ranking, document_kind filter-class semantics, the 'decisions carry file-number identifiers not statute abbreviations' empty-set rule, corpus language separation, and citation-graph matching. The legal://filter_values and legal://rechtsrahmen resource URLs provide additional self-help context. Slightly long, but the behavioral content is rich and not redundant 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.

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

The main description is highly informative but long and dense. It front-loads the core purpose and query-language advice, then gets into detailed filter semantics, a 'common mix-ups' section that is arguably list-like reference material that could have been placed in legal://filter_values or a resource. Every part does carry useful signal for an agent, but the structure mixes general guidance with edge-case warnings. A tighter organization with clear sections and less repetition (e.g. document_kind filter-class rule appears in both description and schema description) would improve it.

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

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

Given 13 parameters and an output schema plus annotations, this description is remarkably complete. It covers ranking behavior, filter semantics, cross-source behavior, empty-set traps, language specifics, and disambiguation guidance for law selection. The only conceivable gap is not describing the output schema's exact fields, but the output schema itself exists and carries that burden. Robust guidance makes this highly usable.

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 the schema already documents every parameter thoroughly. The description adds extra value beyond the schema by explaining filter-class semantics in document_kind, the law_abbreviation+decision empty-set trap, language corpus separation, and cited_norm details. It doesn't enumerate every parameter in the main description, but the schema already covers that; the description meaningfully supplements instead of repeating.

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 ('Search') and resource ('legal documents across jurisdictions') with explicit detail on coverage (DE federal, EU, Bavaria, NRW, Saxony) and return behavior (ranked results with snippets, not full text). The hybrid semantic+keyword search mechanism and the language-quality rule distinguish it from plain keyword search 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?

Extensive guidance: explains which query phrasing works best (statutory language vs colloquial/doctrinal), how document_kind values behave (norm subtypes vs decision), when to use empty document_kind, when to use cited_norm vs plain legal_search, and includes a dedicated section on common mix-ups in law selection. It names the sibling tool legal_find_citing_decisions explicitly and tells when that alternative is preferred. The only minor gap is not mentioning legal_lookup/legal_get_materials, but legal_get_materials is referenced in the source_type description.

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 readOnlyHint annotation already indicates the tool is non-destructive. The description adds valuable context beyond this by explaining the output structure (JSON with resource metadata) and the key distinction between static 'uri' fields and templates with 'uri_template' placeholders. This extra detail about the return format and resource types exceeds what the annotation provides, though the read-only behavior itself is not elaborated further.

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 highly concise, consisting of two short sentences. It front-loads the primary action and object ('List all available resources and resource templates') and then provides necessary detail on return format and resource types without any redundant or vague phrasing. Every sentence adds meaningful content.

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

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

Given the tool's simplicity (no parameters, clear output schema present), the description is sufficiently complete. It explains what the tool returns (JSON metadata) and the critical distinction between static and template resources, which is essential for understanding the tool's behavior. The presence of an output schema means the description does not need to enumerate all return fields, and it covers the key context an agent would need to use 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?

The tool has zero parameters, and the schema coverage is 100% (vacuously). There are no parameter semantics to explain, so the description does not need to add any meaning. The description fully aligns with the input schema, and there is no ambiguity or missing parameter information.

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 action ('List') and the target ('all available resources and resource templates'). It distinguishes between static resources and templates, making the purpose unambiguous even without opening the schema. This is a precise, specific 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.

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

The description does not explicitly state when to use this tool over siblings like read_resource or legal_list_laws. It implies that this is for discovery (listing all resources), but it does not provide direct guidance on selection criteria. The information about static vs. template resources is helpful but does not constitute explicit usage direction.

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 readOnlyHint annotation is consistent with the described read-only behavior. The description adds useful details about return content and base64 encoding, going beyond the annotation without contradicting it.

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 compact and well-structured, with no unnecessary words or repetition. It delivers all essential information in two sentences.

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 simple read operation, the description is complete: it covers input format, output type, and encoding. No further details are needed for correct usage.

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 single parameter 'uri' is described in the schema, but the tool description adds important nuance about static vs. templated URIs, which is not present in the schema. This additional guidance improves parameter understanding.

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?

Clearly states the verb 'Read' and the object 'resource by its URI.' It distinguishes from sibling tools such as list_resources (listing) and legal_* tools (specific legal actions) by focusing on reading a single resource.

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 guidance on static vs. templated URIs and explains output encoding. Does not explicitly contrast with alternatives, but the purpose is straightforward and the instructions are sufficient for correct invocation.

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