Rettsarkiv

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

Annotations already declare readOnlyHint=true (no contradiction). The description adds significant behavioral context: result is date-filtered, ranked on relevance+authority, 'note' appears only when flagging issues, edition ambiguity is handled, and 'overgangshjemmel' changes ranking. This goes well beyond 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 thorough but slightly lengthy (5 paragraphs). However, it is well-structured with bold headings, a sample query front-loaded, and each paragraph adds value. Could trim some redundancy (e.g., 'Resultatet er allerede...' could be merged) but remains effective.

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 fully explains returns: primary_id, decision_date, summary, sitering_count, section, edition, and note field. It covers edge cases like overgangshjemmel, edition resolution, and how to present results. No gaps found for a legal research tool of this complexity.

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 0%, so the description bears full burden. It explains every parameter in detail: 'lov' as lawdata ID/title, 'section' as paragraph, 'on_date' to lock edition, 'overgangshjemmel' to lift old-edition results, 'instanser' to limit court instance. Only 'limit' is implicitly covered (default 50).

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 finds Supreme Court decisions applying a specific law paragraph and returns a ranked list ready for presentation. It includes a sample query in Norwegian, specifying the verb 'Finn' (find) and resource 'dommer som anvender lov', and distinguishes from sibling tools by its focused law-paragraph scope.

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?

Excellent usage guidance: explains when to use 'overgangshjemmel', how 'on_date' locks edition, that result is pre-ranked and pre-filtered, how to interpret 'note' field, and that without 'on_date' both editions are covered. Provides clear context for when to use this tool vs. alternatives (e.g., search_decisions) via implied specificity.

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?

Despite annotations providing readOnlyHint=true, the description adds substantial behavioral context: it details the ranking logic (direct neighbors before co-citation siblings, sitering_count as tie-break), explains the relation field values, and describes the output as a ready-ranked list. 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 well-structured with bullet points and a clear hierarchy, but it is somewhat verbose. However, every sentence adds value, and the key question is front-loaded. A minor reduction in explanation could improve conciseness 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 moderate complexity (3 parameters, no output schema), the description is comprehensive. It explains the output format (ranked list with relation field), the ranking logic, and the _meta.note for empty results. No output schema is needed as the description covers return value semantics.

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 0%, but the description compensates fully. It provides example formats for the id parameter (HR-2024-1016-A, Rt-1979-524), lists allowed values for instanser (hoyesterett, lagmannsrett, tingrett, alle), and clarifies the behavior when results are empty.

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 question ('Hvilke dommer henger sammen med <id>?') and clearly defines the tool as finding precedent neighbors via citation graph. It explicitly distinguishes itself from sibling tools like search_decisions (topic-based) and find_decisions_applying_law (section-based).

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 this tool (e.g., user asks for similar/related decisions, mapping a doctrine) and when the alternatives are insufficient. It also explains the meaning of an empty result and directs the user to _meta.note.

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 declare readOnlyHint=true, and the description reinforces that it is a read operation. Beyond annotations, the description details the return structure (structured text, law-tags, provenance, section_heading, section_text), which is valuable behavioral 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 a single, well-structured paragraph that front-loads the core purpose, then efficiently covers parameter behavior and output details. Every sentence adds value without redundancy.

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 has no output schema, the description adequately covers the return fields (structured text, tags, provenance, etc.). However, it does not mention error handling, rate limits, or prerequisites, which slightly reduces completeness.

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 no descriptions (0% coverage), so the description fully compensates by explaining each parameter: 'id' format, 'paragraphs' for numbered chunks with inherited tags, and 'statutes' to include law text. This is thorough and actionable.

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 a single decision with a specific stable ID format (e.g., HR-2024-123-A or Rt-1979-524). It immediately distinguishes itself from sibling tools like search_decisions which are for searching, not retrieving a specific decision.

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 when the user has a stable decision ID, but it does not explicitly contrast with sibling tools or provide when-not-to-use guidance. The ID format is specified, which helps, but alternatives are not mentioned.

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, so the description doesn't need to re-state safety. It adds some context about the output (metadata + TOC) and input formats, but doesn't disclose other behaviors like auth requirements or rate limits. Given the annotation coverage, a score of 3 is appropriate.

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 sentences: first states purpose and what is returned, second gives parameter guidance and alternative tool. Front-loaded, no extraneous words.

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 low complexity (single parameter, no output schema), the description covers all essential aspects: purpose, return content, parameter format, and alternative tool. It is complete for the tool's simplicity.

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 only one parameter 'lov' with no description (0% coverage). The description compensates fully by explaining it can be a lovdata-id (e.g., 2005-05-20-28) or a short title (e.g., straffeloven), adding crucial semantics beyond the 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?

Description clearly states verb 'slå opp' (look up) and resource 'lov' (law), and specifies it returns metadata + table of contents (paragraph headings). This distinguishes it from sibling 'get_law_section' which returns the text of a single paragraph.

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 tells when to use this tool (to get metadata and TOC) and when to use the alternative 'get_law_section' (for the actual text of a paragraph). Also provides details on the 'lov' parameter format (lovdata-id or korttittel).

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 indicate readOnlyHint=true, consistent with description. The description adds important behavioral details: edition-awareness (text for the resolved edition only), possibility of null text for historical editions, and combined decision retrieval with with_decisions. No contradictions.

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?

Information is packed in one paragraph with clear front-loading of purpose. Every sentence adds value, though a more structured layout (e.g., bullet points) could improve readability. Still concise and efficient.

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 5 parameters (one undocumented), no output schema, and moderate complexity, the description covers main functionality but lacks full return value structure and explanation of the instanser parameter. Partial completeness limits agent understanding.

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 0%, so description carries the burden. It explains lov, section, on_date, and with_decisions meaningfully, including examples and behavior. However, the instanser parameter is not described, leaving a gap.

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 text for a law section with a concrete example (lov='straffeloven', section='257'). It distinguishes from siblings like get_law (whole law) and find_decisions_applying_law (decision search) by focusing on a specific section and optionally including decisions.

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 provides context on when to use on_date for edition disambiguation and how to specify law using ID or short title. It mentions with_decisions as a combined alternative to separate tool calls. However, it does not explicitly state when not to use this tool or compare with all siblings.

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 readOnlyHint=true, so the description's addition of returning a 'next' marker for incremental sync adds valuable behavioral context beyond annotations. It could further discuss rate limits or error behavior but is sufficient 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 concise sentences, front-loaded with the core purpose and return value, followed by an alternative usage note. No extraneous information.

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 (2 parameters, no output schema), the description covers the core functionality, return marker, and a key alternative. It lacks details on pagination semantics (e.g., limit behavior, error cases) but is reasonably complete for its complexity level.

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 description explains the 'since' parameter as an ISO timestamp marker, adding meaning beyond the schema. However, it does not address the 'limit' parameter at all, leaving its behavior undocumented. With 0% schema coverage, the description partially compensates but is incomplete.

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 lists new/updated decisions since an ISO timestamp, with a specific verb and resource. It distinguishes from the export endpoint for full download, making its purpose unambiguous even among 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?

The description explicitly tells when to use the tool (incremental sync) and when not to (full download should use the /export endpoint). This provides clear usage guidance and an alternative, which is excellent for agent decision-making.

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?

Details return values including editions list, resolution field, warning, and behavior for unresolved cases. Consistent with readOnlyHint annotation as a safe lookup.

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 well-structured and front-loaded, but slightly verbose. Every sentence adds value, though could be tightened.

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?

Complete for a complex tool with edition-awareness. Covers all return fields, edge cases (ambiguous, defaulted, unresolved), and no output schema needed as description suffices.

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?

Despite 0% schema coverage, the description thoroughly explains both parameters: name as short title, on_date as date for edition resolution, with examples and fallback behavior.

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 resolves a law's canonical ID from a short title, being edition-aware. It distinguishes from sibling tools like find_decisions_applying_law by specifying when to use this beforehand.

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 says to use this before find_decisions_applying_law when the law is ambiguous. Provides guidance on providing on_date (typically court date) and explains behavior without 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?

The description lists output fields and states that results are ranked, which adds some behavioral insight. However, it does not disclose pagination behavior or rate limits. Since annotations already indicate readOnlyHint=true, the additional disclosure is moderate but not extensive.

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 a single paragraph but efficiently packs purpose, parameter details, and sibling reference. It is well-structured with front-loaded purpose, though slightly dense. Could benefit from bullet points but remains concise.

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 9 parameters, no output schema, and complexity, the description covers primary purpose, output format, parameter usage, and related tools. It lacks explicit pagination details but is otherwise complete for an agent to use effectively.

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 description adds meaning to many parameters (lov, section, court_level with aliases, date range) beyond the schema titles. However, decision_type is not explained. With 0% schema description coverage, the description compensates well for most parameters.

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 that the tool performs free-text search on Norwegian Supreme Court decisions, returning ranked results with specific fields. It distinguishes itself from sibling tools like find_decisions_applying_law and get_decision.

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 provides explicit guidance on when to use this tool (for free-text search) and explains how to filter by parameters like lov, section, court_level with aliases. It also directs users to get_decision for full text, clarifying alternatives.

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