datakilder-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.1
Disambiguation4/5
Most tools are grouped by source prefix and target a distinct resource (e.g., met_varsel vs met_farevarsel vs met_luftkvalitet), so an agent can usually tell them apart. A few close pairs require careful reading — udir_skole/udir_skoler and ssb_tabell_info/ssb_tabell_verdier are easy to mix up, and sted_kontekst overlaps with the single-source lookups it composes.
Naming Consistency3/5
The dominant pattern is {source}_{topic}, which makes the namespace readable and predictable. However, the topic part mixes nouns and verbs (brreg_foretak vs brreg_søk, kart_finn vs kart_punkt), and Norwegian special characters are transliterated inconsistently (brreg_søk vs fdk_sok, kartverket_hoyde, udir_kompetansemaal).
Tool Count2/5
47 tools is far beyond the 3–15 sweet spot and even the 16–25 'heavy' band, which burdens tool selection even though each source's subset is small. The broad 'Norwegian/Swedish public data' scope explains the count, but the surface could be consolidated without losing much.
Completeness4/5
The server covers its domain broadly: geocoding, height, weather, warnings, air quality, transport, companies, accounts, schools, statistics, road data, geology, species, and data catalog discovery, with meta tools (kilder, doctor) rounding out the surface. Minor gaps exist — e.g., no Norwegian historical weather observations and no generic reverse place lookup — but agents can work around them.
Average 3.8/5 across 47 of 47 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 20 commits in the last 12 weeks
- Last stable release on August 24, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It mentions the data source and license, which is useful context, but it does not explicitly state that this is a read-only query, mention any rate limits, or describe what happens with invalid coordinates. The behavioral implications are largely missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and to the point, with two short sentences. The first clearly states the function, and the second adds source/licensing information. No redundant content is present, though the license info could be seen as secondary for tool invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and no annotations, the description needs to explain more about the response format, parameter usage, and operational constraints. It only covers purpose and source, leaving significant gaps for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description provides no explanation of the 'lat' and 'lon' parameters beyond 'coordinates'. It does not clarify the order, format, or constraints (e.g., valid ranges). Since the schema only says 'number', the description fails to compensate for the lack of parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose clearly: 'Current warnings (MetAlerts) for coordinates' — a specific verb and resource. The title adds 'for a point', which distinguishes it from sibling met_varsel, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context implies this is for fetching current weather warnings at a specific coordinate location. However, there is no explicit guidance about when to choose this over met_varsel or other sibling tools, and no exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only mentions source and license. It does not describe output format, timezone handling, coordinate system, or any operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a front-loaded purpose sentence and a brief source/license note. Every sentence adds necessary context, and there is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must explain what the agent can expect. It does not describe return fields, timezone, or coordinate format, making it incomplete for correct invocation and result interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, with only 'dato' described. The description says 'dato og posisjon' (date and position), but does not explain lat/lon units, ranges, or ordering, leaving critical parameter meaning ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool provides sun and moon times for a date and position, including moon phase. This differentiates it from weather forecast siblings like met_varsel, though it lacks an explicit operation verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like met_varsel or met_farevarsel. It only states the input context (date and position) without any exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 does disclose that output is ready-made labeled rows rather than raw json-stat, and gives source/license context, but it does not mention errors, size limits, or response structure. This is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the main behavior and output format. The source/license sentence is not invocation-critical but is short and does not significantly bloat the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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, this description leaves important gaps: the required 'sti' parameter is never explained, and there is no pointer to sibling tools for discovering table paths or variable codes. An agent would likely need to open related tools to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, and the required 'sti' parameter has no description in either the schema or the tool description. The 'utvalg' parameter is well documented in the schema, but the description adds little beyond what the schema already states, and it fails to compensate for the undocumented required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('Henter tall fra en SCB-tabell') and the output form ('ferdige rader med etiketter (ikke rå json-stat)'). It does not explicitly differentiate from closely named siblings like scb_tabell_verdier, but the output-format detail helps narrow the intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only guidance is 'Angi ett utvalg per variabel du vil begrense', which says how to filter but not when to prefer this tool over alternatives. With siblings such as scb_tabell_info and scb_tabell_verdier present, the absence of explicit routing guidance is a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of disclosing behavioral traits. It only mentions the data source and license, not response format, pagination, rate limits, or error behavior. This is a significant gap for a tool with no structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core function. The source/license line is additional but not critical for invocation; still, it is brief and does not waste words. Could be slightly more focused but remains appropriate in size.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool, the description covers the main purpose and output fields (postcode, municipality, coordinates). However, it lacks usage alternatives, limitations, and edge cases. With no output schema or annotations, it is minimally adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only 'sok' has a description). The description mentions output fields but does not explain the 'antall' parameter or add any parameter-level semantics beyond what the schema already states. It fails to compensate for the missing 'antall' description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Finner offisielle adresser med postnummer, kommune og koordinater' (Finds official addresses with postcode, municipality and coordinates). This specific verb+resource distinguishes it from siblings like kartverket_sted (place names) and kartverket_adresse_fra_punkt (reverse lookup).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching addresses but does not explicitly state when to use this tool versus alternatives like kartverket_adresse_fra_punkt or kartverket_sted. No exclusions or alternative comparisons are provided, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 the search capability and the municipality filter, but does not mention result limits, pagination, error behavior, or what 'same fields' actually are. The source and license are useful metadata but not behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the purpose in the first sentence and source/license in the second. No unnecessary detail, perfectly front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description should be more self-contained. It references 'same fields as lookup' without defining them, and omits any mention of the 'antall' parameter or result format. The information about source and license is nice but not enough for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only kommunenummer has a description). The description explains 'navn' as the search term and 'kommunenummer' via the municipality filter, but it does not explain 'antall' (number of results). It partially compensates for the schema gaps but leaves one parameter undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Søker') and resource ('Enhetsregisteret'), with scope ('på navn') and an optional filter ('begrenset til én kommune'). It distinguishes itself from the sibling 'brreg_foretak' by noting it returns the same fields as lookup, implying this is the search variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for name-based searches and mentions an optional municipality restriction, but it does not explicitly say when to use this tool vs. alternatives. There is no direct reference to 'brreg_foretak' as the lookup alternative, only a vague 'samme felter som oppslag'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure and does list some output aspects (legs, transfers, travel time) and cites data source/license. However, it does not state whether the operation is read-only, possible errors, or the structure of the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no redundancy; the function is front-loaded, and the license/source note is compact and separately structured. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 critical details such as parameter units, the meaning of 'antall', and the response format. The coverage of required parameters is minimal and does not fully compensate for the lack of structured information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only refers to 'koordinat til koordinat', leaving the four coordinate parameters to be inferred from their names. The optional 'antall' parameter is entirely unexplained, despite having min/max constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific function: travel planning between coordinates, including legs, transfers, and travel time. The verb 'reiseplanlegger' and resource specification effectively distinguish it from sibling tools like stop and departure lookups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a travel itinerary between two coordinates is needed, but it does not explicitly discuss when to prefer this tool over alternatives or mention any exclusions. No sibling tools are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that results cover all Norwegian grid companies, include fixed/energy components, include VAT variants, and support county filtering. It does not mention pagination, response format, units, or historical coverage, but for a data-retrieval tool the core behavioral context is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the essential data content, then adds provenance and license information. Every sentence carries useful information, though the license line is auxiliary rather than core.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema already documents all five parameters, the description provides enough context to select and invoke the tool for the intended NVE tariff use case. The main omissions are output-shape and units, but the description's data-content coverage makes the tool reasonably complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter already has an individual description in the schema. The tool description adds context about fylke filtering and data composition but no parameter-level details beyond the schema, matching the baseline for full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific data domain: grid-network tariffs for households and holiday homes from all Norwegian grid companies over a period, including fixed and energy components with and without VAT. This is distinct from the sibling tools, which cover maps, weather, schools, and statistics. It could be slightly stronger with an explicit action verb, but the resource and scope are clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when an agent needs Norwegian grid tariffs for households or holiday homes, optionally filtered by county. However, it does not name alternative tools or state when not to use it, leaving some routing decisions to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions that the output is pre-formatted rows with labels (not raw JSON-stat) and includes source/license info, but does not disclose potential limitations, error behavior, aggregation behavior (though the schema touches on it), or any access requirements. This is insufficient for a tool without annotation safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences plus source/license. The first sentence delivers the core purpose, the second gives a key usage instruction, and the trailing lines provide provenance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex (table selection, variable filters), and there is no output schema. The description covers the basic output format and selection requirement but leaves open details like how table identifiers are structured, whether variable codes come from ssb_tabell_verdier, or how aggregation works. Given the schema provides some supplementary information, it is adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (tabell lacks a description). The tool description adds a directive about using 'utvalg' to limit selections, which aligns with the schema's explanation of the utvalg parameter. However, it provides no additional meaning for 'tabell', and the description does not compensate for the missing schema description of that parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Henter tall fra en SSB-tabell' (fetches data from an SSB table) and specifies the output format ('ferdige rader med etiketter'). It also distinguishes itself from raw JSON-stat output and from sibling tools like ssb_tabell_info and ssb_tabell_verdier by focusing on data extraction rather than metadata or value lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives some usage context ('Angi ett utvalg per variabel du vil begrense'), indicating that users must specify selections per variable. However, it does not explicitly state when to use this tool versus alternatives like ssb_tabell_info or ssb_tabell_verdier, nor does it mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description must shoulder behavioral disclosure; it indicates a read-only fetch ('Henter') and adds provenance/license, but says nothing about response shape, unknown-id errors, pagination, rate limits, or any side effects. This fails to fully disclose operational behavior beyond the basic lookup action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core purpose followed by source/license; zero fluff. The essential operation is visible in the first seconds without parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one param, no enums, no nested objects), so the description does not need heavy structure; but since there is no output schema or annotations, the vague 'detaljer' leaves the agent unsure what fields to expect. The Norwegian-context and source/license provide useful domain context, but error and return contract remain unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the lone parameter id described as 'NSR-id fra udir_skoler'. The description merely echoes this by saying 'via NSR-id', adding no new semantic detail such as format, range, or example. Thus the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the explicit action 'Henter detaljer for én enhet i skoleregisteret via NSR-id' – a specific verb (fetch), a concrete resource (one school entity), and the key identifier (NSR-id). It is clearly distinguishable from the sibling udir_skoler (list/search) and from skolverket_skole (Swedish counterpart). The addition of source and license further pins the domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for a single-school lookup keyed by NSR-id, and the title says 'slå opp én skole'. However, it does not explicitly direct when to use it over udir_skoler or state that NSR-id must first be obtained from udir_skoler (that dependency is only in the schema's parameter description). There are no exclusions or alternative routing hints in the description text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the response can be large without filtering and includes license/source info. However, it does not describe the response structure or any error/rate-limit behaviors, which would be expected for a data-fetching tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a license note. The purpose is front-loaded in the first sentence, and the filtering guidance is in the second. No unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Because there is no output schema, the description should explain what 'ferdige rader' means (fields, format), but it does not. It also fails to describe the crucial 'datasett' parameter or provide examples of dataset identifiers, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes 'filtre' and 'sisteperioder', but the description adds no new parameter details beyond the example already present in the schema. The required 'datasett' parameter remains undescribed in both schema and description, and the description does not compensate for this gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Henter' (fetches) with resource 'Eurostat-datasett' and output 'ferdige rader' (ready rows). This clearly distinguishes it from sibling 'eurostat_info' which likely provides dataset metadata, and from other statistics tools like ssb_tabell_verdier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises filtering on dimensions to keep the response small, which is useful context. However, it does not explicitly state when to use this tool versus alternatives like eurostat_info or SSB tools, and no exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral disclosure burden. It does convey meaningful traits: a non-empty search term is mandatory, the search can be limited to one municipality, and the data source is Skolverket under CC0. It does not disclose matching behavior, result limits, pagination, or return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it states the search operation, the required-input rationale, and the source/license in just a few lines. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity search tool with two string parameters, the description provides enough to invoke it correctly: what to search, required input, optional filter, and data source. It omits return-value details, but those are not essential for making the call, and no output schema exists to set a higher expectation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters well: 'søk' as part of a school name and 'kommunkod' as a four-digit code. Schema description coverage is 100%, so the description adds little beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Søker'), resource ('det svenske skolenhetsregistret'), and search criteria ('på skolenavn') with an optional municipal filter. This clearly identifies a search operation over Swedish school units, but it does not explicitly differentiate from the similarly named sibling skolverket_skole.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete usage rule: search text is required because the registry has over 10,000 units, and it explains the optional kommune restriction. However, it provides no explicit guidance on when to use this tool instead of sibling tools 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses the data source and license (CC BY 4.0), but it does not mention any behavioral traits such as read-only nature, case sensitivity, partial matching behavior, response limits, or error handling. This is a minimal disclosure for a tool that should explain how the search behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first delivers the core purpose and result fields, the second adds source and license. Every sentence adds value, and it is perfectly front-loaded with the action. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter search tool with no output schema, the description lists the return fields (taxon-id, names, group), which helps set expectations. However, it omits behavior for the 'antall' parameter and what happens when no results are found. Since the tool is straightforward, this is adequate but slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only 'sok' has a description). The description adds some context for 'sok' by explaining it accepts Norwegian or scientific names, but it says nothing about 'antall' (the count parameter). With partial coverage, the description needed to compensate for the undocumented parameter, which it fails to do.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches species names (Norwegian or scientific) and returns specific fields: taxon-id, valid scientific name, Norwegian name, and species group. This is a specific verb+resource that distinguishes it from all sibling tools (transport, statistics, weather, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for looking up species data ('Søker i artsnavn...'), which gives clear context. It does not explicitly mention when not to use it or alternatives, but the sibling list makes it obvious this is the only species-lookup tool. Lacks explicit exclusions, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It adds useful context: the source (Meteorologisk institutt), license (NLOD 2.0 / CC BY 4.0), and that height materially affects results. However, it does not describe response format, time series nature beyond 'time-for-time', or potential external API behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences deliver the core purpose and a key usage tip, with source/license appended without clutter. 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should convey return expectations. It lists forecast variables (temp, wind, gusts, precipitation, symbol) and says 'time-for-time', but does not specify units, format, or response structure beyond that. Complexity is moderate, so a bit more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50% (hoyde and timer have descriptions, lat/lon do not). The description partially compensates by emphasizing the importance of the 'hoyde' parameter in Norway, but it does not add semantics for 'timer' or clarify coordinate units, leaving some gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides time-by-time weather forecasts (temperature, wind, gusts, precipitation, symbol) for given coordinates. This distinguishes it from sibling tools like met_farevarsel (warnings) and met_sol_og_mane (sun/moon) by specifying the point-based forecast scope and listed variables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives contextual guidance: specify height when known, noting it significantly changes the forecast in Norway. However, it does not explicitly state when to use this tool versus alternatives (e.g., met_farevarsel for warnings), leaving tool selection to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It does disclose the core behavior — returning code/text pairs and optionally filtering by search text — and adds source/license context. However, it doesn't explain important behavioral details such as whether search is case-insensitive, substring-based, or how invalid sti/variabel values are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded: first sentence states the function, second gives a concrete usage example, third provides source and license. Every sentence earns its place with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description needs to fully compensate for missing structured context. It explains what the tool returns at a high level but leaves the required 'sti' parameter ambiguous and does not describe result shape or edge-case behavior. This is enough for a simple example, but not fully complete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already documents 'søk' and 'variabel', and the description's Malmö example adds little beyond that. The required 'sti' parameter is undocumented in both the schema and the description; the agent is left guessing what format or source the path should have, which is a significant gap for a required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific action: 'Gir kode/tekst-parene for én variabel i en tabell', with a concrete example ('finne f.eks. kommunekoden for Malmö'). This clearly separates it from sibling tools like scb_tabell_data (fetch data) and scb_tabell_info (table metadata) by focusing on valid code lookups for a variable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit usage context: use it to look up codes before fetching data ('før du henter tall'). It doesn't explicitly name alternatives or exclusions, but the context is clear enough for an agent to know when this lookup step is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the content returned (competency goals plus assessment text) and cites source and license, but it does not describe response format, error behavior, or whether results are returned as text or structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core semantics and usage rule are front-loaded into a compact first paragraph, and the source/license note is brief. No filler, though the misleading year-range shorthand shows the text was not fully aligned with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter lookup, the description covers parameters, output content, and one key exclusion, and it gives provenance. It is incomplete in two ways: it does not describe the response shape (no output schema exists), and the 1–13 instruction is inconsistent with the schema, forcing the agent to reconcile conflicting guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters completely, so the baseline is 3. The description's contribution is weakened by the 'årstrinn 1–13' shorthand, which conflicts with the schema's valid values of 1–10 or vg1/vg2/vg3 and could lead an agent to submit invalid integers. The fag examples merely repeat schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the deliverable: competency goals from LK20 for one subject at one year level, plus the underveisvurdering text. It also distinguishes itself from school-specific lookups by saying it is not about a particular school.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit use condition: choose this tool when the question is about what is expected at a year level, not about a specific school. It does not name sibling curriculum tools such as udir_laereplan, so the routing guidance is directional rather than exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that this is a generic WMS client (so behavior varies by service) and that license varies, which is useful. However, it does not describe the response format, error behavior, or coordinate system assumptions, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with two sentences delivering the core purpose and context, plus a brief source/license note. It is front-loaded with the main verb and resource, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, yet the description provides some context about being a generic WMS client and returning properties. However, it lacks details about the response structure, what happens when no feature is found, or any prerequisites like coordinate reference systems, making it only partially complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 40%, with descriptions only for 'lag' and 'boks'. The description does not explain 'url', 'lat', or 'lon' beyond implying they define a point. It also doesn't clarify coordinate system or how 'boks' relates to the point, so the description adds little value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs GetFeatureInfo on a map layer and returns the properties at a point, using the specific verb 'returnerer' and resource 'kartlag'. It also distinguishes itself by emphasizing this is how to get DATA out of a map layer, not just an image, which separates it from image-related map tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage for retrieving feature data from a WMS layer, contrasting with merely obtaining an image. However, it does not explicitly name alternative tools or state when not to use it, though it does reference that layer names come from 'kart_lag' via the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden. It discloses the unit (meters), data source (Kartverket/Geonorge), and license (CC BY 4.0), which is useful. However, it does not mention coordinate system, error handling, or response format, leaving some behavioral traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus a source/license line. The core purpose is front-loaded, the usage tip is relevant, and the provenance/license adds necessary context without fluff. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description gives the essential purpose, unit, and usage context. However, it omits the coordinate system and return value structure, which are important for a lookup tool. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions for lat/lon and schema_description_coverage is 0%. The description only says 'for koordinater' without explaining the coordinate format, order, or bounds. This does not sufficiently compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns terrain height in meters for coordinates ('Terrenghøyde i meter for koordinater'), which is specific and distinct from sibling tools like kartverket_sted and kartverket_adresse. The title further clarifies it provides height above sea level for a point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends using this tool with met_varsel ('Nyttig sammen med met_varsel') and explains why elevation affects weather forecasts in Norway. This provides clear context for when to use it, though it does not mention exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It discloses the returned fields and the data source/license, which signals a read-style lookup, but it does not mention error conditions, response format, authentication, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences: the first front-loads the tool's purpose and returned data; the second adds source and licensing context. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup with no output schema, listing the returned fields (rektor, skoletype, kontaktinfo, besøksadresse, WGS84-koordinater) largely completes the picture. It lacks an explicit link to the required skolverket_skoler code and error behavior, but the simple scope makes it nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the single 'kode' parameter is fully documented as 'Skolenhetskod fra skolverket_skoler'. The tool description adds no additional parameter meaning, so the schema-heavy baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a concrete verb ('Gir') and names the exact resource ('detaljer om én skoleenhet') plus the returned fields (rektor, skoletype, kontaktinfo, besøksadresse, WGS84-koordinater). The singular scope and explicit Skolverket source distinguish it from siblings like skolverket_skoler and udir_skole.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when an agent needs detailed data for one specific school unit, but it does not explicitly state when to use this over skolverket_skoler, udir_skole, or other detail endpoints. No when-to-use or when-not-to-use guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 the source and license, which is useful context, and the verb 'Søker' implies a read-only operation. However, it does not mention response format, pagination, or behavior on no results, which would strengthen transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first is front-loaded with the core action and result, the second adds provenance (source and license). No redundant wording, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with no output schema, the description covers the essential need: what it does and what you get (ID). It could be more complete by explaining parameter usage and possible response behavior, but given the low complexity, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 the tool's overall purpose but does not elaborate on the 'sok' or 'antall' parameters beyond what the schema already shows (name and constraints). The meaning of 'sok' is inferable, but 'antall' is only hinted by the schema's max/min, not described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Søker etter holdeplasser og stasjoner') and resource (stops/stations), with a concrete output (Entur ID needed for departures). It differentiates from sibling tools like entur_avganger (departures) and entur_reise (journeys).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use: you need the Entur ID 'for avganger' (for departures), clearly positioning this as a prerequisite to departure queries. It does not explicitly name alternatives, but the context is enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the core behavior (reverse geocoding with radius) and adds useful context about data source and license (Kartverket/Geonorge, CC BY 4.0). It does not detail return format or limitations, but for a simple read-only geocoding API, the key behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main function. The source and license information is concise and useful for context. No wasted words; it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 simple parameters and no output schema, the description states the purpose and data source but does not describe the response structure (e.g., address fields returned). This is a gap, but the core operation is sufficiently clear given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only radius has a description). The description helps by explaining that lat/lon define a coordinate point and that the search is within a radius, but it does not specify coordinate system, units, or order. Since lat/lon are self-explanatory, the description adds moderate value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'revers-geokoding' (reverse geocoding), finding nearest addresses within a radius from a coordinate point. This specific verb+resource combination distinguishes it from siblings like kartverket_sted (place names) and kartverket_hoyde (elevation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when you have a coordinate point and need to find nearby addresses. It does not explicitly name alternatives or exclusions, but the context is unambiguous, and the sibling list makes the alternative tools identifiable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the core behavior (search and return coordinates/kommune/fylke) and includes source/license context, but it does not disclose result limits, no-match behavior, or response format. This is adequate but has clear gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with purpose, and uses only two sentences. The source and license sentence is brief and relevant, adding value without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no output schema), and the description covers the main purpose, output fields, use case, source, and license. However, it omits parameter semantics for 'antall' and does not describe return shape, leaving it slightly incomplete for a tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The 'sok' parameter can be inferred as the place-name query from the tool's purpose, but 'antall' is not mentioned or explained in the description, leaving the agent without guidance for that parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Søker i stedsnavnregisteret og gir koordinater, kommune og fylke' (searches the place-name register and gives coordinates, municipality, and county). It also clearly differentiates from sibling tools like kartverket_adresse by focusing on place names and explicitly mentions converting a place name to lat/lon for weather forecasts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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: 'Bruk denne for å gjøre et stedsnavn om til lat/lon før et værvarsel'. It provides a clear use case, though it does not mention alternatives or when not to use it, which keeps it just below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral burden. It does disclose a useful behavior: the response includes a 'mangler' field for parts that could not be fetched. It also names the source and license. However, it does not describe read-only status, response wrapping, rate limits, or coordinate-system expectations, which remain unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the tool's purpose and content, followed by use cases, error behavior, the sibling alternative, and source/licensing. It is slightly longer than strictly necessary, but every sentence contributes practical information for invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter lookup tool with no output schema, the description covers purpose, domain, common use cases, partial-failure behavior, and the key sibling alternative. It is missing precise coordinate-parameter semantics and any indication of response shape, leaving the agent to guess about lat/lon formatting and default radius behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, so the description must compensate for the undocumented lat and lon parameters. It refers vaguely to 'dette koordinatet' and 'i nærheten', but never defines coordinate order, CRS, value ranges, or how radius_m behaves beyond the schema's own brief description. This is not enough to fill the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear question-resource mapping: 'Hva består grunnen av på dette koordinatet' and then enumerates the concrete data categories it returns (radon, løsmassetype, marin grense, wells). It also explicitly distinguishes itself from ogc_punkt for NGU's other 27 datasets, so an agent can tell it apart from related siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly gives usage contexts ('Bruk denne ved boligkjøp, tomtevurdering, graving eller planlegging av bergvarme') and names the alternative for other NGU datasets ('bruk ogc_punkt'). This is exactly the when-to-use and when-not-to-use guidance the dimension asks for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the data source (SMHI), the license (CC BY 4.0), and the requirement for a search text, all useful signals. However, it does not describe the return format, output fields, matching behavior, or whether results may be partial or paginated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded: the main purpose appears in the first sentence, followed by the key usage constraint. The source and license lines are concise and add useful provenance without bloating the description. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and both required parameters are fully documented in the schema, so the invocation path is clear. However, there is no output schema and the description does not explain what the returned station data looks like, such as whether it includes station IDs, names, or coordinates. This creates a notable gap, especially if the result is meant to feed into a sibling tool like smhi_observasjoner.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and both parameters are already described clearly in the input schema ('Stedsnavn, f.eks. Malmö' and 'Parameterkode fra smhi_parametere, f.eks. 1'). The description itself adds no new parameter-level meaning beyond noting that search text is mandatory, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Søker opp') and names the exact resource ('målestasjoner') with clear scoping ('for en parameter på stedsnavn'). It also includes the operational detail that search text is required because each parameter has around 1,000 stations. This distinguishes it from siblings like smhi_observasjoner and smhi_parametere.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: to find measurement stations for a given parameter by place name. It also provides an important usage constraint, that søketekst is required, which prevents agents from calling it without a search term. It does not explicitly name alternatives or exclusions, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden. It discloses that the call aggregates data from Kartverket, MET, and Entur, and that failed sub-parts are reported in a 'mangler' field. This gives useful behavioral context without contradicting any structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core capability and usage, followed by failure behavior and source/license. Each part has a purpose, though the source/license sentence is background rather than invocation guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must cover both invocation and expected return shape. It lists the semantic output fields and the failure field, but not exact output keys, coordinate format, or the 'timer' parameter. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'timer' is described), and the description does not compensate for lat/lon. It only says 'koordinat', without specifying coordinate format, order, or bounds. The description adds little beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: one call that returns municipality, address, elevation, current weather, warnings, and nearest stops for a coordinate. It clearly differentiates itself from sibling tools by being an aggregator instead of a single-domain lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to use this tool instead of chaining kartverket_*, met_*, and entur_* when the question is 'what applies here?'. It names the alternatives and the triggering condition, but does not explicitly state 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It clarifies scope ('alle gjeldende LK20-læreplaner') and intended output ('Gir koden du trenger'), and even adds source/license context. However, it does not describe response format, matching behavior, or empty-result/error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the action and object, the second explains the downstream use. The source/license line is short and adds useful provenance without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's purpose and relationship to a sibling, but there is no output schema and the description does not specify what the response contains beyond 'koden'. An agent would benefit from knowing whether matches return a list, status info, or only the code.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already well documented in the schema. The tool description adds no parameter-specific meaning beyond the schema, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Søker i alle gjeldende LK20-læreplaner på navn eller kode.' It also explains the output's purpose by pointing to the downstream sibling 'udir_kompetansemaal', which clearly differentiates it from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool to search curricula and obtain the code needed for 'udir_kompetansemaal'. It does not explicitly list exclusions or alternative tools beyond that relationship, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 the data source, license, and returned fields, but does not describe default filtering (e.g., 'baraktive' defaulting to true), result limiting, or matching behavior. The absence of warnings about side effects is acceptable for a search operation, but richer behavioral context would help.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences plus a source/license line, with the core action front-loaded. Every sentence adds relevant information; no word is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description lists the return fields and the source, which is helpful. It remains incomplete about parameter interactions and default behavior (e.g., 'antall' default/max and 'baraktive' s role), and does not clarify whether results are paginated or limited. Overall it is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, and the description compensates by identifying 'navn' and 'kommunenummer' as search criteria and outlining the output fields. However, it adds nothing about 'antall' (result count limits) or the meaning/filtering behavior of 'baraktive', so parameter semantics remain only partially clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Søker i det nasjonale skoleregisteret') with explicit search criteria ('på navn og/eller kommunenummer') and lists the returned fields. This clearly distinguishes it from the singular 'udir_skole' sibling as a search/list tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this to find schools in the national register by name or municipality number. It does not explicitly name alternative tools or exclusion rules, but the search-oriented wording implies when it should be selected over the singular school lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 the returned data fields, possible status values, source, and license, which is useful. However, it does not mention error handling, response format, data freshness, or any rate limits or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a main sentence listing the action and fields, followed by a short source/license note. Every sentence provides relevant information, and the most important details are presented first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter lookup with no output schema, the description is fairly complete. It lists the returned fields and provides source/license context. It could be improved by noting behavior for invalid or missing organization numbers, but it is sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a complete description of the only parameter 'orgnr' (9 digits, spaces allowed), so schema coverage is 100%. The tool description adds only the context that this is the organization number to look up, which does not significantly exceed what the schema already communicates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Henter' (retrieves) and clearly identifies the resource: an enterprise by organization number. It enumerates the exact data fields returned, which distinguishes it from sibling tools like 'brreg_søk' that perform searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'for ett organisasjonsnummer' (for one organization number), providing clear context that this tool is intended for single-ID lookups. However, it does not explicitly mention alternative tools or exclusion criteria, stopping short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It implies read-only behavior with 'Viser' (shows) and adds useful context with 'kodeverket er ikke til å gjette' (codes are not to be guessed). However, it does not disclose output format, error handling, or any potential side effects, leaving room for improvement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tightly written sentences plus a standard source/license line. The first sentence states the core function, the second gives usage guidance, and the license is relevant metadata. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter info tool, the description covers what it does, when to use it, and the data source/license. It does not describe the return value, but the purpose is straightforward. An output schema or explicit return-format note would make it more complete, but current detail is adequate for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single parameter with a concrete example ('prc_hicp_midx'), giving 100% coverage. The description's mention that codes are not guessable reinforces the need for a correct dataset code but doesn't add new semantics beyond the schema, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence clearly states the function: 'Viser dimensjonene i et Eurostat-datasett med eksempelkoder' (shows dimensions in a Eurostat dataset with example codes). It differentiates from sibling eurostat_data by framing itself as a preparation step before data fetching, making its distinct role obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Kjør denne før du henter data' (Run this before you fetch data), providing clear when-to-use guidance. It doesn't explicitly name alternatives, but the context of sibling tools (especially eurostat_data) makes the recommended sequence unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the tool is read-only ('kun oppslag') and provides source attribution (data.norge.no) and license (NLOD 2.0). This goes beyond a minimal description, though it doesn't detail error handling or response structure. The read-only nature 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the core purpose, and the second adds source and read-only context. No unnecessary words or repetition of schema details. It earns its place in two sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should clarify what the response contains. It mentions endpoint URL and license, but 'Full metadata' is vague. For a simple tool with two parameters, this may be adequate, but it leaves gaps around error cases and the full return structure. The source and read-only context help, but more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the input parameters. Schema coverage is only 50% (id is described, katalog is not). The description mentions 'katalogoppføring' but does not clarify the 'katalog' enum or how to select the right catalog type. The id parameter is documented in the schema, but the description adds no semantic value for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Full metadata for én katalogoppføring' (full metadata for one catalog entry), with specific mention of the endpoint URL and license. It distinguishes from sibling tools by noting 'kun oppslag, ikke datauttrekk' (lookup only, not data extraction), and the title explicitly says 'hent endepunkt og lisens' (get endpoint and license).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it is a lookup tool, not for data extraction ('kun oppslag, ikke datauttrekk'). It also identifies the source (Felles datakatalog). While it does not explicitly name alternative tools, the parameter description 'Id fra fdk_sok' implies integration with the search tool. This gives sufficient guidance for when 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It adds useful traits beyond the schema: results come from a harvested index of WMS services, iLag=true is slower on first call but yields broader matches, and licenses vary per service. It does not describe the output format, but for a simple read-only search this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the main purpose and when-to-use guidance. The trailing 'Kilde' and 'Lisens' lines add useful context, though the 'Kilde: Generisk WMS-klient' phrasing is slightly vague and could confuse rather than inform.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter search tool with no output schema, the description gives the agent enough to invoke it correctly: what is searched, when to use it, and the key parameter behavior. It would be slightly more complete with an explicit statement about the returned result shape, but that is not a blocking gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters and examples. The description adds real value by explaining the tradeoff of iLag=true ('tregere første gang, men treffer bredere'), which goes beyond the schema's simple boolean definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Søker i en indeks over norske WMS-tjenester' from data.norge.no. It is clear and distinct in behavior, but it does not explicitly name or contrast sibling tools like kart_lag or ogc_tjenester, so differentiation is more implicit than direct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit usage directive: 'Bruk denne FØRST når du leter etter kartdata ... og ikke vet hvilken tjeneste som har dem.' This clearly tells the agent when to prefer this tool, though it stops short of stating when not to use it or naming alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral disclosure burden. It adds useful context such as source, license, and the fact that this is a pre-data-retrieval step, but it does not explicitly state that the operation is read-only, what the response shape is, or any error/rate-limit behavior. The 'info' nature of the tool mitigates this gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose, then gives the critical ordering instruction, and ends with a compact source/license note. Every sentence earns its place and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter metadata tool with no output schema, the description is nearly complete: it explains what the tool returns and when to use it. It could be more explicit about the exact response format, but the core contextual information an agent needs to invoke it correctly is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'sti' is described in the schema as 'Tabellsti fra scb_finn_tabell', and coverage is 100%. The description does not add additional parameter-level semantics beyond reinforcing that this tool should be run before data retrieval, so it stays at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'Lister variablene i en SCB-tabell ... med eksempelverdier.' This clearly states what the tool returns and distinguishes it from sibling data-fetching tools like scb_tabell_verdier and scb_tabell_data by positioning it as the prerequisite step before retrieving data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit when-to-use rule: 'Kjør denne FØR du henter data' and a concrete consequence if ignored ('ellers må du gjette dimensjonskodene'). It lacks an explicit when-not-to-use or named alternatives, which keeps it 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses that the tool returns actual (not forecast) measurements with timestamps and quality flags, and it identifies the data source and license. It does not describe the response format or error behavior, but for a simple read operation it adds useful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the main function, followed by source and license. Every sentence earns its place with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with three parameters fully described in the schema. The description states what is returned (measurements with time and quality flags), which partially compensates for the lack of an output schema. It does not detail the response structure or error cases, but that is a minor gap for a straightforward data-fetch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes all three parameters with 100% coverage, including the default for 'periode' and the meaning of 'corrected-archive'. The description adds no parameter-specific meaning beyond this, so it stays at the baseline for fully covered schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Henter faktiske målinger') and the resource ('en parameter på én stasjon'), and indicates the return contents (tidspunkt og kvalitetsflagg). It distinguishes this from sibling tools like smhi_parametere (which list parameters) and smhi_stasjoner (which list stations), since it is specifically about fetching measurements for a known station/parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (fetching observed measurements) but does not explicitly mention alternatives or when not to use it. The schema references smhi_stasjoner and smhi_parametere as sources for parameter/station codes, but the description itself lacks such routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the tool's function (listing variables with example values) and its source/license (PxWebApi, NLOD 2.0), but does not describe response format, error behavior, or any limitations. For a read-only metadata tool, this is adequate but not rich; it adds context but stops short of deeper behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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, the second provides a critical usage directive, and the source/license line is useful context. Every sentence earns its place with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema and no annotations, the description is sufficiently complete. It tells what the tool does, when to use it, and its provenance. It doesn't describe the exact return structure, but that's not essential for an agent to select and invoke it correctly, especially given the clear sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'tabell', with a descriptive example '07459'. The description indirectly reinforces that the parameter identifies a table and that dimension codes are involved, but it doesn't add new meaning beyond what the schema already provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's action with a specific verb and resource: 'Lister variablene i en SSB-tabell (region, alder, år ...) med eksempelverdier.' This clearly distinguishes it from sibling tools like ssb_tabell_data (fetching data) and ssb_tabell_verdier (likely fetching specific values), by focusing on table metadata rather than data or values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage timing: 'Kjør denne FØR du henter data, ellers må du gjette dimensjonskodene.' This tells the agent when to invoke this tool relative to data-fetching operations. While it doesn't explicitly name alternative tools, the context makes it obvious that ssb_tabell_data is used for fetching data, and the instruction 'FØR du henter data' implies a preceding step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden for behavioral transparency. It discloses the core behavior (returns code/text pairs, supports filtering) and source/license, but it does not mention pagination, match type, ordering, or potential errors. The read-only nature is implied though not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the main function, and includes a useful example. The source/license line is additional context but not wasteful. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool, the description is fairly complete: it states what it does, gives an example, and notes the optional filter. It lacks explicit return-format details and how to identify the table, but the schema references 'tabell_info' for the variable code and sibling tools provide context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers two of three parameters ('søk' and 'variabel'), and the description adds the 'Halden' example and the concept of a single variable. However, the required 'tabell' parameter has no description in either the schema or the tool description, leaving an important semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns code/text pairs for one variable in a table, with optional text filtering. The concrete example of finding Halden's municipality code before fetching data distinguishes it from sibling tools like ssb_tabell_data and ssb_tabell_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Bruk den til å finne f.eks. kommunekoden for Halden før du henter tall' gives a clear use case and tells the agent when to use the tool (before retrieving data). However, it does not explicitly mention alternatives or when not to use it, so it falls short of the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the core behavior (search and return an id) and adds source/license context, but does not explain edge cases such as empty search, multiple matches, or output format. Since this is a read-only lookup, the lack of side-effect disclosure is acceptable, but more detail on expected behavior would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise and well-structured. It opens with the primary action and resource, provides a usage hint, and ends with source/license attribution. Every sentence contributes necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers the essential purpose and usage context. It could be more complete by explaining the output format or how to use the returned id with vegvesen_vegobjekter, but the given information is sufficient for basic invocation and understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the 'sok' parameter already has an example ('F.eks. "fartsgrense"'). The tool description adds further examples but does not introduce new meaning (e.g., that the parameter is optional or how to handle empty input). The baseline for high schema coverage is 3, and the description adds only marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches NVDB's 424 road object types and returns the needed id. It provides concrete examples ('fartsgrense, rekkverk, skilt, tunnel') and explicitly positions it as a precursor to fetching objects, distinguishing it from the sibling tool vegvesen_vegobjekter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 the tool: 'Kjør denne først hvis du ikke vet id-en' (run this first if you don't know the id). It does not explicitly name the alternative tool or state when not to use it, but the sequential hint ('først') clearly implies using another tool after obtaining the id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 the data source, license, and that results are per-year financial figures, but it does not mention output format, historical depth, or pagination/limits. For a simple read-only lookup this is acceptable but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose and usage condition. The source/license line adds attribution but is not directly operational; still, it is short and does not detract meaningfully.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one required parameter and no output schema, the description covers the returned financial fields, the use case, and the data source. It could be slightly more specific about the temporal scope of 'per år' and that this covers Norwegian enterprises, but overall it is sufficient for an agent to invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter orgnr has 100% schema description coverage with '9 siffer'. The description adds no additional meaning beyond the schema, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Henter innsendte årsregnskap') and names the concrete financial fields returned: driftsinntekter, driftsresultat, årsresultat, eiendeler, and egenkapital. It also distinguishes the tool from existence-check siblings with 'ikke bare om det finnes.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool: when the question is about company size or solvency, not merely whether the company exists. This is clear usage guidance and implicitly routes the agent away from brreg_søk or brreg_foretak.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and discloses important behavioral traits: the data is modeled per grunnkrets, not measured on-site, and the source and license are stated. It does not mention auth or rate limits, but for a read-only data lookup and with the modeled-vs-measured caveat explicitly disclosed, this is solid coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core output details, followed by the important modeling caveat and source/license information. Each sentence provides useful context; the license line is slightly auxiliary but contributes to data provenance transparency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately explains the return content: index, health risk text, pollutant concentrations, and source contributions. It also covers the time range and the modeled nature of the data. Minor gaps like units or coordinate reference system are not critical for invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (33%) since lat and lon lack descriptions, but the description says 'for koordinater', making their role clear. It also mentions 'opptil 56 timer', reinforcing the timer parameter's meaning which the schema already explains. The description adds some context but does not fully compensate for the undocumented lat/lon format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: provides hourly air quality (up to 56 hours) for a coordinate, including a combined health-risk index, specific pollutant concentrations (NO2, PM10, PM2.5, ozone), and source attribution. This is specific and distinct from sibling tools like met_varsel, met_farevarsel, and met_sol_og_mane, which cover weather forecasts, warnings, and sun/moon data respectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear context for use: air quality at a point, with a notable caveat that data is modeled per statistical unit, not measured at the address. It does not explicitly name alternatives or state when not to use it, but the domain and limitations are clear enough for an agent to select it appropriately among the MET tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the transparency burden. It discloses the browse behavior ('ett nivå om gangen'), the path-based ID model, the no-argument top-level case, and the source/license. It does not describe the exact response structure or edge cases, but the core behavior is clearly visible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded, and free of filler. Every sentence contributes: what it does, why it must be used first, how to invoke it without parameters, and where the data comes from.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-optional-parameter tool, the description is mostly sufficient, but there is no output schema and the description never explains what the returned 'folders and tables' entries look like or how callers should feed the returned path into sibling tools. It implies the loop but does not fully complete it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already describes 'sti' with an example and the omit-for-top-level rule. The description reinforces the point and adds a fuller path example, but it does not add significant meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action and resource: it navigates SCB's subject tree one level at a time and shows folders and tables. It also distinguishes itself from sibling SCB tools by stating 'START HER', making clear it is the discovery entry point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to call it first, that no other tool can be used without the path, and that omitting the argument gives the top level. It does not explicitly say 'use scb_tabell_info/verdier/data instead when you already have the path', so it stops short of naming alternatives, though the implication is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses the output composition (line, direction, platform, schedule vs. expectation, cancellations), the data source (Entur, all Norwegian operators), and the license (NLOD 2.0). It does not cover edge cases such as empty results or timezone handling, which prevents a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two short, information-dense segments. The core behavior is front-loaded, and the source/license line provides useful context without unnecessary padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description covers the essential return contents and context well. It omits details like result ordering or behavior when no departures exist, but these are minor gaps for a simple two-parameter departure-list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes stoppestedId as 'NSR-id fra entur_stoppested', and antall has type/min/max constraints. The description itself adds no parameter semantics, and with 50% schema coverage it does not compensate for the unexplained 'antall' behavior beyond what can be inferred from the name and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a real-time departure board ('Sanntids avgangstavle') and enumerates the specific return fields: line, direction, platform, scheduled vs. expected time, and cancellation status. This distinguishes it from siblings like entur_stoppested (stop lookup) and entur_reise (journey planning).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The title and opening line make the intended use explicit: next departures from a stop, with real-time updates. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to select this over entur_reise or entur_stoppested.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context by specifying that it reads GetCapabilities and lists layers, and it notes the source/license for the data. With no annotations, the description carries the full burden, but it does not disclose the return format, error handling, or rate limits, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core function. Each sentence adds value: the action, the scope (Norwegian WMS), and the source/license. There is no waste or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, and the description covers its main usage and inputs. With no output schema, it could be more explicit about the return format, but the essential information for selecting and invoking the tool is adequately addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the 'sok' parameter as 'valgfritt filtrert på tekst' (optional text filter), which is missing from the schema (coverage is 50%). The url parameter is already described in the schema, and the description adds example URLs, providing complementary meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads GetCapabilities and lists the layers that can be queried, optionally filtered by text. This specific verb+resource (WMS layer listing) distinguishes it from map-related sibling tools like kart_punkt or kartverket_sted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: against any Norwegian WMS service, with named examples like Geonorge, NVE, and others. However, it does not explicitly mention exclusions or alternative 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses a read-only listing operation and specifies the output content (license, website, tools). It does not mention auth or rate limits, but these are unlikely for a catalog tool and the action is transparently non-mutating.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with no redundancy. It effectively communicates the tool's purpose and output without exceeding necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's purpose and the content of the listing for a simple, no-parameter tool. It could mention practical use (e.g., to select a specific source tool), but it is sufficiently complete for a directory/catalog function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain them. The description adds value by detailing what the listing includes, which matches the baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all data sources covered by the server, including license, website, and available tools. This is a specific verb+resource+scope and distinguishes it from the individual data source tools listed as siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for discovering available data sources and their capabilities, which is clear context. However, it does not explicitly state when to use it versus the specific sibling tools, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It reveals the default query scope (all collections except map-sheet/delineation layers) and that skipped layers are reported in “hoppet_over”, plus source and license variability. It does not mention error behavior, response format, or potential performance, so it is not a full 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, and each sentence contributes behavioral or usage context. A small redundancy exists between the provenance sentence and the earlier list of NGU/HI sources, preventing a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The definition is reasonably complete for selecting and invoking the tool: it covers data source, parameter lookup, default collection behavior, and an alternative. However, with no output schema it does not describe the return shape beyond a passing reference to “hoppet_over”, and coordinate reference system/error handling are left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% and the description adds meaning for samling (default all collections) and tjeneste (find via ogc_tjenester or use full URL), but required lat/lon parameters lack any coordinate-system or format guidance beyond “koordinat”. The schema already documents antall, radius_m, samling, and tjeneste, so the marginal value over the schema is moderate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (“Henter data i et koordinat”), a concrete resource type (Norwegian OGC API Features services from NGU and Havforskningsinstituttet), and the coordinate/radius mode. It also explicitly names ngu_grunnforhold as the tool to use instead for ground-condition queries, which differentiates it from a sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete when-to-use guidance: find tjeneste via ogc_tjenester or supply a full landing-page URL, and states that ngu_grunnforhold should be used for residential ground conditions. The default all-collections behavior is also described, so an agent knows what will happen if samling is omitted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It discloses the coordinate system (WGS84), the output content (egenskaper og vegnavn), and a critical constraint (0.5° limit). It does not mention potential edge cases, response limits beyond the schema, or API-specific quirks, leaving some uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences plus source/license information. It is front-loaded with the main action and immediately provides the most important constraint. Every sentence adds value, with no redundant or vague wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with six parameters and no output schema. The description explains the output includes properties and road names, and provides source/license context. It could be more complete by mentioning what happens if no objects are found or how results are ordered, but for a straightforward bbox query it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 83%, and the description adds meaningful parameter context: it gives a concrete example for the 'type' parameter (105 for speed limit) and constrains the bounding box parameters with the 0.5° per axis rule. This goes beyond the terse schema descriptions (e.g., 'Østlig lengdegrad') and enhances parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Henter' (fetches) and the resource: NVDB-objekter of one type within a map extent (WGS84), including properties and road names. It also provides a concrete example ('Fartsgrense = type 105'), which helps differentiate it from the sibling tool 'vegvesen_objekttyper' that likely lists types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a key usage constraint: the extent must be under 0.5° per axis, which guides when the tool can be used. It also implies the need to know the object type ID from a companion tool. However, it does not explicitly state when to use this tool over alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does a good job: it notes that NGU's 28 services are pulled from their own index ('så lista er fersk'), names the source, and warns that licensing varies per service. This goes beyond the minimal read-only expectation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action, then the optional filter, freshness note, and downstream usage. The source/license line is a small addition but earns its place by warning about per-service licensing. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter optional-filter tool with no output schema, the description is sufficiently complete: it states what the response conceptually contains (id and description), how to filter, and where the output is intended to be used. Nothing critical for a correct call is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents 'sok' as filtering on id or name (100% coverage), so the baseline is 3. The description adds value by giving concrete examples ('løsmasser', 'gytefelt', 'grunnvann') and reaffirming that filtering is optional, making the parameter's intent easier to grasp.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Lister kjente norske OGC API Features-tjenester med id og beskrivelse'. It also clarifies the relationship to the sibling tool ogc_punkt, making it distinguishable from other list-style tools in the sibling set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The statement 'Id-en herfra brukes i ogc_punkt' gives a concrete workflow cue: use this tool to discover service ids for later use in ogc_punkt. It does not explicitly enumerate when not to use it, but the intended context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, and it adds meaningful context: results are observations of past weather, SMHI has no forecasts here, and data is from a CC BY 4.0 licensed source. It does not detail response structure or pagination, but for a simple zero-parameter metadata list that gap is minor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded in the first sentence, and the 'START HER' instruction is highlighted early. The source/license line is slightly extra for invocation purposes but not excessive, keeping the description compact and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameter-count tool with no input schema, no output schema, and no annotations, the description covers the essentials: what is returned, why to use it first, and the observation-not-forecast caveat. It could mention the exact output shape or whether all parameters are returned at once, but the current level is adequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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%, so the baseline is 4. The description goes slightly beyond by indicating the useful output content (code and unit) and giving examples of parameters, which helps the agent interpret what it will receive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and object: 'Lister målte parametere ... med kode og enhet', making it unmistakably a parameter-catalog tool. It also distinguishes itself from sibling tools by declaring 'START HER — kodene trengs av de andre verktøyene', placing it as the entry point before smhi_stasjoner and smhi_observasjoner.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to start here because the codes are needed by the other tools, which tells the agent when to invoke it. It also states this is observations, not forecasts, so it should not be used for forecast lookups, though it does not name the alternative forecast tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the tool makes real API calls, that it is deliberately cheap, that it touches one endpoint per source, and that it can take several seconds. This is meaningful context beyond a simple 'check health' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences with no filler. The first sentence establishes the action and output, the second gives concrete use cases, and the third sets latency expectations. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter diagnostic tool without an output schema, the description covers the essential expectations: what it calls, what it reports, when to use it, and that it takes seconds. It stops short of describing the exact response format or listing which sources are checked, but it is sufficient for correct invocation and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, which gives a baseline of 4. The description does not need to explain parameter meaning, and it correctly describes the tool as needing no user input to perform its per-source checks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Kaller ett billig, ekte endepunkt per kilde') and a clear resource (each data source), then defines the output: which sources respond, how fast, and what error they give. It clearly differentiates from the sibling data-access tools by positioning itself as a diagnostic health check rather than a data-fetching tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names when to use this tool: when another tool behaves strangely or when checking whether a source changed its contract. It does not explicitly name alternative tools or state when not to use it, but the intended diagnostic context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 an excellent job: it explicitly states return type (metadata), what it does NOT return (data), a behavioral nuance (94% of links point to web pages), source, and license. This is rich behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise: it front-loads the core purpose, then adds a behavioral note, usage guidance, and source/license. Every sentence adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple search tool with no annotations or output schema, the description covers the essential aspects: purpose, return type, usage context, source, and license. It could provide more detail on output structure or parameter specifics, but it is largely complete for an agent to decide correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not directly explain the parameters (sok, antall, katalog). It mentions the return metadata fields (name, publisher, endpoint) but not how to use the search query or count. The parameter names are fairly self-explanatory, but the description adds little semantic value beyond the schema's type/enum definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: searching the national data catalog to find APIs, returning metadata (name, publisher, endpoint) rather than data. It explicitly distinguishes itself from data-fetching tools by stating it does NOT fetch data, and positions itself as a discovery tool for building modules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: use it when no typed source covers the question, and use it to discover APIs, not to answer data questions. It also implies that other sibling tools (typed sources) should be preferred when they fit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![datakilder-mcp MCP server](https://glama.ai/mcp/servers/smlhus1/datakilder-mcp/badges/card.svg)](https://glama.ai/mcp/servers/smlhus1/datakilder-mcp)

Score Badge

Copy to your README.md:

[![datakilder-mcp MCP server](https://glama.ai/mcp/servers/smlhus1/datakilder-mcp/badges/score.svg)](https://glama.ai/mcp/servers/smlhus1/datakilder-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/smlhus1/datakilder-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server