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

With no annotations, the description carries the full burden, and it does include the key behavioral trait: the output is truncated because judgments are often 30,000–300,000 characters. It also explains section as a jump-to location and maps 'FOR THESE REASONS' to the operative part. It does not mention behavior on missing sections or exact truncation limits, but those are partly covered by the schema's maxChars constraints.

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: the first front-loads the primary action, and the second adds the essential length/truncation context and the section usage hint. There is no filler or 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?

For a single-document retrieval tool with one required parameter and no output schema, the description plus schema is sufficient to call it correctly: itemid source, section values, and truncation behavior are all present. The main gap is the lack of any stated output format or error behavior, but the operation is simple enough that this is not critical.

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 already defines two of three parameters with examples and constrains maxChars with default/min/max (67% description coverage). The description adds 'THE FACTS' and the mapping of 'FOR THESE REASONS' to the conclusion, but it does not explicitly tie maxChars to the truncation behavior, so the added semantic value over the schema is modest.

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 clear action: fetch the text of one ECHR judgment using an itemid from a search hit. It is specific about the resource (EMD-avgjørelse) and the retrieval mechanism, but it does not explicitly name sibling tools such as caselaw_search or get_document to differentiate them.

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 phrase 'hentet på itemid fra et søketreff' places this tool after a search operation and tells the agent to supply a HUDOC id. The second sentence also gives concrete guidance on when to set section. However, it never states exclusions or names the alternative tools for other document types.

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?

With no annotations, the description carries the full burden, and it delivers substantial behavioral context: the default search is against Norway, results are in English, `text` matches decisions that cite a case, and `importance: 2` filters to principal judgments. It does not describe result shape, pagination behavior, or rate limits, but for a search tool it is unusually transparent.

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 front-loaded with the core search capability and then provides useful disambiguation. The paragraph about Norwegian law and the free-source situation is somewhat verbose but serves the important purpose of preventing the agent from treating this as domestic Norwegian case law. Each section earns its place, though a bit of trimming would be possible.

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 zero annotations, no output schema, and 12 parameters, the description is quite complete: it explains defaults, source, key parameter semantics, and a common misuse trap. It does not describe the return format or pagination behavior, but the rich parameter guidance and disambiguation make it sufficient for most invocation 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?

Schema coverage is 83%, so the baseline is 3, but the description adds real meaning beyond the schema for several parameters: `respondent` accepts ISO codes or null, `importance` means 'level or higher', `text` searches full text including citing decisions, and `caseName` is for finding a specific case. This goes beyond the schema's terse 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 and resource: search decisions from the European Court of Human Rights via the open HUDOC database. It clearly distinguishes this from Norwegian domestic case law, which helps an agent avoid confusion. The scope and default behavior are immediately clear.

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 guidance on when to use `caseName`/`appNo` versus `text`, and warns that `text` is the wrong tool for locating a specific case. It also explains that this is not Norwegian case law and that ECHR case law is openly available. It does not explicitly name alternative sibling tools, but the routing advice within the tool is strong.

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?

With no annotations, the description carries the burden and does disclose important behavior: it returns the full paragraph text plus amendment history, and it contrasts this with incomplete search excerpts. For a read-only retrieval tool this is adequate, though it could state safety/permissions explicitly.

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 short sentences with no filler. The most important guidance—use before quoting—is front-loaded, and parameter clarifications are compactly appended.

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 single-article retrieval tool, the description covers what the tool does, what it returns, when to use it, and how to format both parameters. No output schema exists, but the description still provides enough return-value context.

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%, giving a baseline of 3. The description adds meaningful value by explaining that reference is interpreted as in get_document and by specifying accepted article formats like '§ 14-9' or '§14-9'.

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 precise resource: the full verbatim text of one article plus its amendment history. It clearly distinguishes itself from truncated search snippets and from get_document by focusing on 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 the agent to use this before quoting because search hits are excerpts with omissions. It does not explicitly name all alternatives or state when not to use it, but the provided context makes the intended use unambiguous.

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?

With no annotations, the description carries the full behavioral burden. It discloses what the tool returns, and importantly warns that large laws return truncated text when includeText is set. It does not mention edge cases like ambiguous names or empty results, but the core behavior is transparent.

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 dense sentences, with the primary lookup methods and result contents front-loaded. The second sentence handles the includeText caveat efficiently. No filler or repetition.

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 four parameters with full schema coverage and no output schema, the description provides enough context: how to reference documents, what output to expect, when text is truncated, and which sibling to use instead. An agent can correctly select and invoke this tool without further clarification.

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. The description adds meaningful semantic value by explaining accepted reference formats ('arbeidsmiljøloven', dokid, LOV-kode), clarifying includeText's truncation caveat, and pointing to search for large full-text needs.

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 and resource: 'Slå opp et dokument' (look up a document) using common name, docid, or legacy code. It clearly describes what is returned—metadata and a table of contents—and implicitly distinguishes itself from sibling tools like search and get_article by describing whole-document 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?

The description explicitly tells the agent when to use an alternative: for large laws with includeText, the text may be truncated, and 'search med docId' is better. This is a clear when-not-to-use condition with a named alternative.

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?

With no annotations, the description carries the behavioral burden. It discloses the sort order and the significant no-filter aggregation behavior, both of which are non-obvious. It does not specify the response format or pagination details, but these are partially covered by the schema's limit/offset fields.

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 tight sentences, each adding unique value: the core action, the specific use of 'since', and the no-filter fallback. No filler or repetition, and the main action is front-loaded.

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 covers filtering and a special no-filter case, but with 5 parameters, no output schema, and no annotations, it could have stated what fields are returned and how this relates to `get_document` or `search`. The lack of response-shape information and explicit routing to sibling tools leaves some gaps for correct invocation.

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 only 40%, but the description compensates by explaining 'since' as a date filter and interpreting 'departement' as a ministry filter. It also adds the interaction that omitting all filters produces ministry counts. Limit and offset are left to schema defaults, which is acceptable since they are conventional.

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 documents with filters on type, ministry, or change date, and sorts by most recently changed. This distinguishes it from the general 'search' sibling by focusing on structured browsing rather than full-text search, though it does not explicitly name that alternative.

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

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

It gives explicit guidance for the 'since' parameter ('what's new in the regulations since ...') and explains the no-filter behavior (returns ministry counts). It lacks direct 'when not to use' or explicit comparison to sibling tools like 'search', but the provided usage context is actionable.

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 behavioral disclosure burden. It does disclose that the returned content is the complete text of a single statement and adds the useful citation format SOM-ÅÅÅÅ-NNNN. It does not mention output shape, errors, access constraints, or the effect of maxChars, but the core retrieval behavior is reasonably clear.

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 short, focused sentences with no filler. The purpose is front-loaded in the first sentence, and the citation convention is compactly provided in the second. 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?

Given no annotations, no output schema, and a sibling set containing several similar retrieval tools, the description is under-specified. It does not explain when to choose this over ombudsman_search or caselaw_get, nor does it clarify the purpose of type and maxChars. An agent gets the basic what but not enough surrounding context for confident tool selection and invocation.

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 only 33%: only 'id' has an explanatory description. The tool description adds no parameter-level meaning; the case-number note is about the returned text's citation format, not about the id, type, or maxChars parameters. The description therefore fails to compensate for the low schema coverage.

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 title and description identify a clear verb and resource: retrieving one full statement/uttalelse from Sivilombudet. The phrase 'Hele teksten i én uttalelse' unambiguously indicates full-text retrieval of a single opinion. However, it does not explicitly distinguish itself from sibling retrieval tools such as get_document, caselaw_get, or ombudsman_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 implies the tool is for retrieving the full text of one statement and mentions how the case number appears for citation purposes. It does not state when to use this tool over ombudsman_search, caselaw_get, or get_document, nor does it explain that the id should come from a search hit. Usage context is only implied, not 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?

With no annotations, the description carries the full burden and does add meaningful context: statements are non-binding but followed in practice and serve as an established legal source. Still, it does not disclose response format, pagination, or any limitations of the full-text search behavior itself.

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: the core search purpose appears first, followed by the legal context, and the critical `type` override is placed last. Every sentence contributes, though the legal-status paragraph is useful context rather than invocation-critical.

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 and no annotations, the description omits what a successful search returns, how results are ordered, or how to go from a result to a specific document via siblings like ombudsman_get. It explains the corpus well but is incomplete for an agent deciding whether and how 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?

Schema coverage is only 50%, so the description should compensate. It does clarify the `type` parameter by explaining what `besoksrapporter` returns, but it adds nothing about `limit`, `offset`, or how the date filters interact with the search. The schema already documents `query`, `to`, and `from`, so the description adds marginal value beyond 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 'Fulltekstsøk i Sivilombudets uttalelser,' a specific verb plus resource, and clarifies the corpus as roughly 2,000 cases on administrative case processing. It does not explicitly differentiate itself from siblings like caselaw_search or preparatory_search, but the resource and scope are 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 description clearly instructs when to set `type: "besoksrapporter"` for visit reports versus the default statements, which is a useful usage cue. However, it gives no guidance on when to choose this tool over the many sibling search tools, leaving the choice mostly implied.

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

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

With no annotations provided, the description carries the behavioral burden. It usefully warns that document text is often long and is truncated ('den er ofte lang, så den avkortes'), but it does not describe return structure, permissions, or other behavioral constraints.

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: the first sentence states the core purpose, and the second explains the optional text behavior and its important truncation caveat. 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 description names the main returned content and the optional text behavior, which is adequate for a basic call. However, with no output schema and several sibling getters, the lack of tool-selection guidance and undocumented maxChars behavior leave some gaps for an agent.

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 67%, and the description adds meaningful context for includeText by explaining that it retrieves the actual innstilling/proposisjon text. However, maxChars is not explained in the description, and caseId is only minimally connected to a search result.

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 returns details about a single parliamentary case: subjects, committee, case process, decisions, and links to documents. The singular focus ('én sak') helps distinguish it from search tools, though it does not explicitly contrast it with sibling getters like get_document.

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?

There is no explicit guidance about when to use this tool instead of preparatory_search, get_document, or get_article. The only conditional instruction concerns setting includeText, which is a parameter choice rather than tool-selection 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?

With no annotations provided, the description carries the full burden and does it well. It explicitly discloses a key behavioral limitation: the search matches titles, references, and subject terms, not full document text, because the Stortinget API lacks free-text search. It also explains the output reference format and how it feeds into preparatory_get — valuable behavioral context beyond any structured field.

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 structured in three compact paragraphs: what the tool searches, how the search behavior differs from full-text search and how to adapt, and what the hit reference is used for. Each sentence contributes distinct, necessary context with no redundancy. It is front-loaded with the core purpose.

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 gives an agent everything needed to invoke the search correctly: scope, document types, search limitation, query strategy, and the follow-up tool. Since there is no output schema, it could have described result fields a bit more, but the citation format is covered and the operational path to preparatory_get is clear, making this adequately complete.

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 about 60%, and the description substantially enriches the most important parameter, query, by instructing users to search by the law/case name rather than by expected phrases. It also clarifies the citation/reference role of search results. It does not add much for limit/offset, but those are self-explanatory, so the description compensates well for the remaining 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 opens with a specific verb and resource: 'Søk i Stortingets saker' over preparatory works, and enumerates the exact document types (proposisjoner, innstillinger, stortingsmeldinger, representantforslag). This clearly distinguishes it from the other search tools by domain and scope. The mention of the date range adds further precision.

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 this search is relevant — when the statute text is unclear and legislative intent is needed — and gives concrete guidance on how to search (by title or name, not by expected wording). It also routes the user to preparatory_get for fetching the document text. It does not explicitly name sibling search alternatives or say when not to use this tool, so it falls just 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?

No annotations are provided, so the description carries the full burden. It discloses that each hit is one paragraph with an excerpt and that matched keywords are marked with quotation marks. It also explains search behavior differences for scope and docId, which is valuable behavioral context 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 dense but well organized: main behavior first, then query syntax examples, then scope and docId specifics. Every sentence adds value and there is no fluff or repetition of schema fields.

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 search tool with 7 parameters and no output schema, the description covers the core behavior, result shape, and important query options well. It does not explain pagination parameters like limit and offset or the type/ministry filters, but those are partly self-explanatory and the most critical usage guidance is present.

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 71%, and the description adds meaningful semantics for query syntax, exact-phrase quoting, truncation, scope:'titler', and docId restriction. It helps the agent understand how to construct effective queries, going beyond the bare 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?

Description states a specific verb and resource: full-text search across all paragraphs of laws and regulations, with each result being a paragraph excerpt. The title 'Søk i lover og forskrifter' plus the sibling tool names like caselaw_search and preparatory_search make it clearly distinguishable from other 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?

Provides explicit query guidance: use keywords rather than questions, use quotes for exact phrases, use * for truncation, and use scope:'titler' when searching document titles. It does not explicitly contrast with sibling search tools like caselaw_search, but the in-tool guidance is strong and contextually 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?

With no annotations, the description carries the burden of behavioral disclosure. It clearly states what data is returned and implies a read-only snapshot by referencing when the corpus was last fetched rather than saying it fetches now. It could be more explicit about being non-mutating, but nothing suggests side effects.

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 short sentences with no wasted words: the first lists the reported content, the second gives usage guidance. The information is front-loaded and 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?

For a simple status tool with no parameters and no output schema, the description sufficiently explains the return values (last fetch time, document count, paragraph count, type distribution) and the reasoning for using it. Nothing important is missing for an agent to invoke 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 tool has zero parameters, and the empty schema fully documents this. The baseline for zero-parameter tools is 4, and no additional parameter semantics are needed since there is nothing to configure.

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 specifies the tool reports when the local corpus was last fetched, counts of documents and paragraphs, and type distribution. This clearly distinguishes it from the sibling search/retrieval tools, making the purpose immediately understandable.

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 says 'Check this when freshness matters' (Sjekk denne når ferskhet betyr noe), providing a clear context for use. It doesn't name alternatives or exclusions, but the sibling list shows status is the only index-inspection tool besides sync.

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 behavioral burden. It discloses that the tool re-downloads all datasets, rebuilds the index from scratch, and takes about two minutes, which is meaningful behavioral context. It stops short of detailing side effects such as temporary unavailability or concurrent-run implications, so it is adequate but not rich.

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 short, information-dense sentences with the core action front-loaded and the time/scheduling context following. Every sentence earns its place and there is no 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?

For a no-parameter maintenance action, the description covers the key decision factors: what it does, how long it takes, and when it normally runs. It could mention output or operational impact, but the essential information needed to decide whether to invoke the tool is present.

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 empty, so the baseline of 4 applies. There are no parameter-level details for the description to add, and the description does not attempt to invent any.

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 concrete action: it downloads Lovdata datasets again, rebuilds the law index from scratch, and refreshes preparatory works from the Storting. This clearly identifies the resource and scope, and distinguishes sync from sibling read/search tools such as search, get_document, and status.

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 notes that a systemd timer runs the sync weekly and that manual runs are rarely needed, giving an agent clear guidance on when not to use it. It does not go as far as naming explicit alternative tools or conditions, but the scheduling context is strong and actionable.

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