Rettsarkiv

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

With no annotations, the description explains the source of results (law-aware tags) and ranking by citation count, but it does not mention potential limitations, authentication, or error handling, leaving some behavioral aspects unclear.

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 that is relatively concise and front-loads the main purpose, but it could be more structured for clarity.

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 3 parameters, no output schema, and no annotations, the description covers the main purpose and key parameter semantics well, though it could mention the expected output format.

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 for 'lov' (id or short title) and 'section' (implicitly) beyond the bare schema, but it omits any explanation for the 'limit' parameter, which is undocumented in 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?

The description clearly states that the tool finds Supreme Court decisions applying a specific law and section, and distinguishes from sibling tools like get_decision or search_decisions by focusing on law application tags.

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 some usage guidance, such as the format for 'lov' and a special case for EMK, but does not explicitly state when to use this tool over alternatives like search_decisions or when not 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?

No annotations are provided, so the description carries full burden. It reveals return structure (structured text, law-tags, provenance) and behavior of optional flags, which is adequate for a simple retrieval 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 a single paragraph but contains no filler. It could benefit from slightly more structure (e.g., separating parameter explanations), but it is concise and information-dense.

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 retrieval tool with no output schema, the description covers return format, parameters, and use cases. It lacks error handling or edge case details, but these are not critical for such a tool.

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?

With 0% schema description coverage, the description adds crucial meaning: 'id' gets example formats, 'paragraphs' and 'statutes' are explained with their effects. This significantly helps an agent understand each parameter.

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 one decision by a stable ID, with specific examples like 'HR-2024-123-A'. It distinguishes itself from siblings like 'search_decisions' which 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 explains when to use 'paragraphs' and 'statutes' flags but does not provide explicit guidance on when to use this tool vs. alternatives like 'find_decisions_applying_law'. Usage is implied but not contrasted.

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?

No annotations are provided, so the description carries the full burden. It discloses that the tool returns metadata and headings, implying a read-only operation. While it doesn't explicitly state read-only or describe the output format, the behavior is fairly transparent for a lookup tool. Could be improved by noting it is non-destructive.

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, each earning its place: first defines purpose and output, second provides usage guidance with alternative tool. No wasted words, front-loaded with core function.

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 tool (one parameter, no output schema, no annotations), the description is nearly complete. It covers purpose, parameter semantics, and when to use alternatives. It could mention potential errors or confirm the output is in Norwegian, but overall adequate.

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%, but the description fully explains the 'lov' parameter: it can be a lovdata-id (with example) or a short title. This adds significant meaning beyond the bare schema, clearly instructing the agent on how to format the input.

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 looks up a law with metadata and table of contents (paragraph headings), using a specific verb 'look up' and resource 'law'. It distinguishes from sibling 'get_law_section' by noting that sibling retrieves the full 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 (for metadata/headings) and when to use the alternative 'get_law_section' (for full paragraph text). It also specifies that the 'lov' parameter accepts lovdata-id or short title, providing clear context for when to invoke this 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?

No annotations are provided, so the description carries full burden. It discloses core behavior: returns current text, includes decisions when flag set, and returns a note if paragraph not found. It does not explicitly state it is read-only or mention authentication or rate limits, which are typical for data retrieval tools.

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 relatively concise (4 sentences) and front-loaded, starting with the main function followed by examples and parameter details. It avoids unnecessary repetition but could be slightly more 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 3 parameters and no output schema, the description covers usage and response conditions (note on not found). However, it does not specify the exact response format (e.g., JSON structure or plain text), leaving some ambiguity about what the agent will receive.

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 the description must compensate. It explains 'lov' as lovdata-id or short title, 'section' with examples, and 'with_decisions' as a boolean flag. This adds meaning beyond the schema, though it could specify data types or constraints more formally.

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 it retrieves the current text for a law section, with examples for parameters 'lov' and 'section'. It distinguishes from sibling tools like get_law (which retrieves whole laws) and search_decisions, making the purpose specific and unambiguous.

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 guidance on parameter usage (e.g., using 'lov' as id or short title, EMK example, setting with_decisions=true). However, it does not explicitly state when to use this tool versus siblings like find_decisions_applying_law or get_law, leaving the agent to infer context.

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 reveals that the tool is incremental, returns a next marker, and is read-only in nature (listing changes). No annotations are provided, so the description carries the full burden. However, it does not disclose pagination details, rate limits, or authorization requirements.

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 concise: two sentences, front-loaded with the primary purpose, and includes a helpful contrast with the export endpoint. No unnecessary 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?

The description explains the core functionality and return of a cursor, but given the lack of output schema, it does not fully describe the output structure, how to iterate, or the effect of the limit parameter. It is adequate but not complete for complex scenarios.

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 for the 'since' parameter by specifying it is an ISO timestamp marker, but the 'limit' parameter is not mentioned. Since schema coverage is 0%, the description partially compensates but does not cover all 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 the tool lists new or updated decisions since an ISO timestamp, and returns a 'next' marker for incremental sync. It distinguishes this tool from siblings by contrasting with a full export endpoint.

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 indicates when to use this tool (incremental sync via marker) and contrasts with the /export endpoint for full downloads. However, it does not compare with other sibling tools like get_decision or search_decisions.

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?

No annotations are provided, so the description must carry the behavioral burden. It reveals that the tool returns candidates when ambiguous and hints at read-only behavior (slå opp/lookup), but does not explicitly state if the tool is safe, irreversible, or requires permissions. The mention of 'candidates' implies aggregation, but the exact behavior on single vs. multiple matches is not fully specified.

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 adds value: the first states the core purpose, the second uses a critical constraint with an example, the third gives a practical date usage, and the fourth foresees ambiguity. The description is front-loaded and wastes no words, despite being in Norwegian.

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 no output schema, the description omits details about the return structure (what fields the candidates contain). It does not mention error handling (e.g., if no match found). For a lookup tool that provides raw IDs or candidates, this missing information leaves the agent partially blind about what to expect.

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 provides no descriptions (0% coverage), but the description thoroughly explains both parameters: 'name' is the short title, and 'on_date' is an optional date in YYYY-MM-DD format to resolve versioning. It uses a concrete example (straffeloven with dates) to clarify the parameter's purpose, adding significant meaning beyond the minimal 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 clearly states the tool resolves a canonical lawdata ID from a short title/name, and provides concrete examples (straffeloven with different IDs). It distinguishes itself from siblings like find_decisions_applying_law and get_law by focusing on ID resolution, not on fetching content or 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 explicitly advises using the 'on_date' parameter (formatted as YYYY-MM-DD) to get the law in force on a specific date, typically the judgment date. It also warns that short titles can be ambiguous across dates. However, it does not explicitly contrast with sibling tools or state when not to use this 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?

No annotations provided, so the description carries full burden. It explains the search behavior (full-text, ranking, filtering by law section), and describes return fields (primary_id, dato, sammendrag, sitering_count). Lacks details on pagination or rate limits, but adequate for a search 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 a single paragraph that efficiently conveys key information: tool purpose, filtering guidance, return format, and sibling reference. No unnecessary text, though could be more structured with bullet points.

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 8 parameters and no output schema or annotations, the description provides solid context for most aspects (search behavior, filtering, return fields). Missing explanations for date range and court/decision type parameters, but overall 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?

Schema coverage is 0%, so description must compensate. It explains q, lov, section, and limit, but leaves out descriptions for to_date, from_date, court_level, and decision_type. Partial coverage reduces effectiveness.

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 searches Norwegian Supreme Court decisions via full-text search, ranked by relevance and authority. It distinguishes itself from siblings by directing users to get_decision for full-text 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?

Provides explicit guidance on using lov+section parameters to filter decisions that actually apply a specific paragraph, and recommends get_decision for full text. However, it does not explicitly contrast with sibling tool find_decisions_applying_law.

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