mcp-skatteetaten

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes, but some near-overlaps exist: get_restanse and get_krav both relate to outstanding tax claims, and get_trinnskatt_satser overlaps with get_skattesatser. Descriptions are specific enough to guide selection, so agents are unlikely to misselect if they read carefully.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern using lowercase with underscores, primarily get_*, with a few action verbs like submit_, validate_, order_, search_, and list_. No mixing of conventions such as camelCase, so the naming is highly predictable.
Tool Count1/5
At 52 tools, this server is excessively large, exceeding the 50-tool threshold for an extreme mismatch. While the Norwegian tax domain is broad, this many tools creates navigation overhead and suggests unnecessary granularity; many rate/deduction tools could be consolidated.
Completeness4/5
The server covers a wide range of tax-related operations: fetching rates, retrieving income/tax data, submitting A-melding and third-party reports, managing skattekort, and accessing the population register. However, there are notable gaps, such as no tool to submit a skattemelding (only validate) and no update/delete operations for several entity types.
Average 3.8/5 across 52 of 52 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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 the full burden of behavioral disclosure, but it only states the basic operation. It does not disclose whether the result is a list, how 'outstanding' is defined, if there is pagination, or any authentication/authorization needs. For a tool with five parameters and no output schema, this is a significant gap.
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 only two sentences, with the first being directly informative. The second sentence ('Part of Fremtidens innkreving') adds marginal context but is not wasteful. It is concise and without redundancy.
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 five parameters, only one required, and no output schema or annotations. The description lacks crucial context: return value format, pagination, default filters, and its relationship to similar sibling 'get_restanse'. This makes it inadequate 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?
The input schema has 100% coverage with each parameter described, so the baseline is 3. The description adds no extra parameter semantics beyond the schema; it merely implies that 'identifikator' is the key, which the schema already states as 'Norwegian identity number'.
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 identifies the action ('Get') and resource ('outstanding tax claims (krav)') and specifies the target as 'a person or organisation'. However, it does not differentiate from the sibling tool 'get_restanse', which likely covers similar debt/claim data, so it stops short of a 5.
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 provided on when to use this tool versus alternatives. It does not mention filters, limitations, or exclude scenarios. The phrase 'Part of Fremtidens innkreving' is a program label, not usage instruction.
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 of behavioral disclosure. It does not mention what statuses may be returned, whether the operation is read-only, error behavior, or any other practical details. The description only states a simple read operation without elaborating on the response or edge cases.
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 a single, focused sentence that front-loads the purpose and explicitly mentions the parameter. Every word earns its place with no unnecessary elaboration.
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 with one parameter and no output schema. The description adequately explains the primary use case, but it omits details about possible status values or how the response relates to other A-melding tools. Given the minimal complexity, the description is acceptable but leaves the agent to guess about response semantics.
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 documents the parameter 'innsendingId' with the description 'ID from submission'. The tool description provides no additional semantic information beyond what is already in the schema, and since schema coverage is 100%, the baseline of 3 is appropriate.
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 action (Check status), the resource (submitted A-melding), and the key parameter (innsendingId). It is specific and aligned with the tool name, though it does not explicitly differentiate from the sibling tool get_amelding_tilbakemelding, which might also be used after submission.
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?
Usage context is implied by the word 'submitted'—the agent can infer this is for checking the status of a previously submitted A-melding. However, there is no explicit guidance on when to use this tool versus alternatives like get_amelding_tilbakemelding or list_amelding_for_maaned, so the guidance is minimal.
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 output content (errors and deviations) but does not state whether this is a read-only operation, what happens if no feedback exists, or any prerequisites beyond processing. Minimal 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 consists of two concise sentences, front-loaded with the primary action and output content. No superfluous words or repetition.
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 with one parameter and no output schema. The description explains what the tool returns but lacks usage context and behavioral details. It is minimally complete but could mention when feedback becomes available or how errors are formatted.
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 the single parameter (innsendingId) with a description 'ID from submission' at 100% coverage. The tool description adds no further parameter meaning, 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 clearly states the tool retrieves feedback for a processed A-melding, specifying it contains errors and deviations found by Skatteetaten. This distinguishes it from sibling tools like get_amelding_status or submit_amelding.
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 provided on when to use this tool versus alternatives. The mention of 'processed A-melding' implies a post-submission context, but there is no explicit mention of alternatives, prerequisites, or 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?
Annotations are absent, so the description carries the full burden for behavioral disclosure. It states that the tool returns data, implying a read operation, but does not mention access requirements, sensitivity of the data, error conditions, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the purpose and enumerates key outputs. It is efficient with no filler or redundancy.
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 core purpose and return content are clear, but with no output schema and no annotations, the description should clarify the meaning of 'rettighetspakke' values and the optional 'stadie' parameter. It is adequate for a simple lookup but leaves gaps for a complete 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?
Input schema coverage is 100%, so the baseline is 3. The description does not add parameter-level detail beyond what the schema provides, and the schema descriptions are terse (e.g., 'Rights package'), but the high coverage means the description does not need to compensate much.
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 specific action ('Get calculated tax details') and the resource ('for a person'), listing concrete components returned (income, deductions, assets, debt, final calculated tax). This distinguishes it from sibling tools like get_inntekt or get_summert_skattegrunnlag.
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 provided on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description merely states what it does, leaving the agent to infer usage context from the name and sibling list.
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 provided, the description carries full responsibility for behavioral disclosure. It only says 'Get payment history', implying a read operation, but it omits any details about prerequisites, return format, pagination, auth requirements, or data scope beyond 'person or organisation'.
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 a single, front-loaded sentence that states the core purpose without extraneous words. It is appropriately sized for the tool's simplicity, earning a perfect score for conciseness.
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 the tool has no output schema and only 3 parameters, the description is adequate but leaves gaps: it does not mention date-range usage, expected response shape, or how it relates to other 'get' tools. It is sufficient for basic selection but lacks richer context 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?
All three parameters are fully described in the schema (100% coverage), so the description adds minimal extra meaning. While 'person or organisation' hints that 'identifikator' may refer to either type, it does not explicitly map to the parameter. The baseline of 3 is appropriate because the schema already handles parameter semantics.
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 retrieves payment history, specifically for a person or organisation. This distinct resource (payments) differentiates it from sibling tools like get_inntekt or get_restanse, and the scope is explicit.
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 description provides no guidance on when to use this tool versus alternatives, no exclusions, and no mention of specific scenarios. It simply states what the tool does; usage context is left entirely 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 only mentions that authentication is not required, but omits other behavioral traits such as whether the value is static or calculated, data freshness, or return format. This is minimal disclosure for a get-style 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?
The description is a single, front-loaded sentence that immediately states the purpose and includes a key access note. There is no wasted wording, and the structure is optimally concise.
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 tool's simplicity (no parameters, no output schema), the description provides sufficient context for basic usage. It explains what is retrieved and the authentication requirement. However, it could be slightly more complete by indicating the return type or that it's a fixed annual amount, so a small gap remains.
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 accepts zero parameters, so the input schema fully covers the parameter space (100% coverage). The description adds no parameter details, but none are needed. Baseline for 0 parameters is 4, and this is met.
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 identifies the tool as retrieving the union membership deduction (fagforeningsfradrag) and specifies it returns the maximum deductible union fee. While this is a clear verb+resource indication, it does not explicitly distinguish it from sibling tools beyond the unique name.
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 description provides no guidance on when to use this tool versus alternatives. The only usage-related note is 'No authentication required,' which is more of an access prerequisite than a contextual recommendation. No exclusions or alternative tools 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?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns classification and ownership, but it does not explicitly state whether the operation is read-only, any authentication requirements, potential errors, or limitations. For a tool with no annotation coverage, this minimal behavioral context is insufficient.
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, front-loaded with the action and resource. Every word contributes meaning, with no filler or repetition of schema details. This is an appropriately sized description.
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 is adequate for a simple GET-like tool, but gaps remain. With no output schema, it only vaguely mentions 'classification and ownership' without detailing the response structure. It also does not explain the 'rettighetspakke' parameter, which may be domain-specific. While the core purpose is clear, the lack of usage context and output details makes it only moderately complete for an agent invoking this 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 has 100% description coverage, with each parameter (inntektsaar, rettighetspakke, norskIdentifikator) already described. The tool description adds minimal value beyond the schema: it clarifies that the person is identified by Norwegian identity number, but it does not elaborate on 'rettighetspakke' or parameter formats beyond what the schema already provides. The schema does most of the work, warranting the baseline score of 3.
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: 'Get property assets (fast eiendom) for a person' with a specific verb and resource. It also adds detail about the return content ('classification and ownership of real properties'), which distinguishes it from related sibling tools like get_formuesgrunnlag_eiendomsskatt that focus on property tax basis.
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 provided on when to use this tool versus alternatives. The description simply states what the tool does, without mentioning related tools, exclusions, or scenarios where this tool should be preferred. The sibling list includes similar property-related tools, but no differentiation is offered.
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 provided, the description carries the full burden for disclosing behavioral traits. 'Check' implies a read-only operation, but it does not explicitly state safety, rate limits, or possible outcomes (e.g., not-found statuses). This minimal disclosure is inadequate for a tool with no annotation support.
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 a single, front-loaded sentence with no filler or redundancy. It efficiently states the tool's purpose, earning a perfect score for conciseness.
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 parameter, no nested objects) and the schema covers the parameter. However, without an output schema, the description does not explain what statuses will be returned or how they are represented, leaving a gap in completeness for an agent needing to handle the response.
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 parameter 'ordreId' described as 'Order ID from order_skattekort', which is clear and references a related tool. The description itself adds no additional parameter meaning, 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 'Check the status of a skattekort order' clearly states a specific action (check) on a specific resource (skattekort order status), distinguishing it from siblings like get_skattekort or order_skattekort. The name reinforces the purpose, making the tool's intent unambiguous.
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 description provides no guidance on when to use this tool relative to alternatives, such as after ordering a skattekort or instead of get_skattekort_resultat. There are no exclusions or alternative suggestions, leaving the agent without contextual usage information.
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?
Annotations are absent, so the description must carry the burden. The description only states the purpose, not any behavioral traits like read-only nature, possible statuses, error behavior, or authentication requirements. It adds no context beyond what the name implies.
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 a single concise sentence that immediately states the action. No filler or redundant information; it is appropriately minimal for a tool with one parameter.
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 is minimal viable for a simple status-check tool. It doesn't link to the corresponding submission tool or explain expected statuses, but given the low complexity and full schema coverage, it is not severely incomplete. However, it could benefit from more 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% since the only parameter innsendingId is fully described as 'ID from the submission'. The description's mention of a submitted report is consistent but adds no additional semantic detail 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 uses a specific verb 'check' and clearly identifies the resource: processing status of a submitted tredjepartsopplysninger report. This distinguishes it from sibling tools like submit_tredjepartsopplysninger and get_tredjepartsopplysninger_oppgavetyper.
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 description provides no guidance on when to use this tool or how it relates to submission flows. It doesn't mention that it should be used after submitting a report, nor any alternative status endpoints. There are no exclusions or alternative tool references.
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 provided, the description carries the full burden for behavioral disclosure. It only says 'Returns validation result' without explaining what that result contains, whether it checks schema or business rules, or any error behavior. This is too vague for a validation tool.
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 short and front-loaded with the main action. The second sentence 'Returns validation result' adds little beyond the first and could be considered redundant, preventing a perfect score.
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 no output schema and no annotations, the description should explain what the validation result looks like and what kind of validation is performed. It does not mention the result format, possible outcomes, or required fields of the input object, leaving significant gaps.
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 provides a description for the only parameter ('MVA melding object'), yielding 100% schema coverage. However, the description adds no further meaning about the expected structure or content of the melding, so it does not improve on 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 a specific verb ('Validate') and resource ('a VAT return (MVA-melding)') with the format ('provided as JSON'). This distinguishes it from the sibling tool validate_mva_melding_xml by calling out the JSON input format.
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?
Usage context is implied by the phrase 'provided as JSON', which suggests this tool is for JSON-formatted MVA meldings. However, it does not explicitly mention when not to use it or point to the XML alternative (validate_mva_melding_xml) for XML input.
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 mentions the return contents but does not address read-only status, authentication needs, potential errors (e.g., not found), or data freshness. The word 'Look up' implies a safe read operation, but the description lacks deeper 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 a single, efficient sentence that front-loads the main purpose and list of return fields. Every word earns its place; there is no waste or 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 lookup tool with two parameters and no output schema, the description gives a reasonable overview of return values and purpose. However, 'and more' is vague, and it does not mention that using 'part' limits the response, though that is in the schema. Overall, it is adequate but could be more specific.
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% – both parameters are described in the input schema. The description adds no additional parameter semantics beyond what the schema already provides (e.g., the 'part' array's purpose is explained in the schema). This meets the baseline but does not exceed it.
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 a specific verb ('Look up') and resource ('person in the Norwegian Population Register'), and lists the types of data returned. It implicitly differentiates from sibling tools like search_personer_folkeregisteret by using 'look up' rather than 'search', but does not explicitly mention the need for a national identity number or contrast with alternatives.
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 provided on when to use this tool instead of alternatives such as search_personer_folkeregisteret. The required parameter implies use for direct lookup by ID, but the description does not explicitly state this or any exclusion criteria.
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 provided, the description carries the full burden of behavioral disclosure. It only states 'No authentication required,' adding minimal value. It fails to mention whether the operation is read-only, the output structure, or any 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?
The description is concise, consisting of two short sentences. Every word earns its place, with no redundant information or unnecessary padding.
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 no-parameter, no-output-schema tool, the description provides minimal viable context. It identifies the resource and authentication requirement, but could clarify what 'amounts' means (e.g., list vs. single value) or the applicable tax year. Overall, it meets the minimum but lacks depth.
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 baseline is 4. The description does not need to add parameter semantics since the input schema is empty and nothing further could be clarified.
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 tool retrieves pension income tax credit amounts, using a specific verb and resource. It differentiates from sibling tools by targeting a specific credit type, though it does not explicitly name alternative tools.
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 pension income tax credit amounts are needed, but provides no explicit guidance on when to choose this tool over alternatives. The 'No authentication required' note hints at accessibility but not selection criteria.
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 states the action 'Order' but does not disclose side effects, permission requirements, asynchronous behavior, or follow-up steps. For a write operation, this is a significant transparency 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 a single, front-loaded sentence that is efficient and free of unnecessary words. It fully earns its place with no redundancy.
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?
There is no output schema, and the description does not mention what the tool returns, prerequisites, or how this relates to the ordering workflow (e.g., status checks via get_skattekort_ordre_status). For a simple write tool with no annotations, this is incomplete.
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 descriptions for both parameters ('List of skattekort requests' and 'Tax year'), achieving 100% coverage. The description adds no extra parameter-level meaning, so the baseline score of 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?
The description clearly states the verb 'Order' with a specific resource 'tax deduction cards (skattekort)' and scope 'for multiple employees at once'. It effectively distinguishes this batch ordering tool from sibling getter tools like get_skattekort.
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 batch ordering, but it does not explicitly state when to use this tool versus alternatives such as get_skattekort or get_skattekort_ordre_status. No exclusions or alternative guidance is provided.
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 present, so the description must disclose behavioral traits itself. It only states the search criteria and fails to mention that this is a read-only operation, what response format to expect, or any pagination or authentication considerations. This is a significant gap for an API with 8 parameters.
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 a single, front-loaded sentence that directly states the tool's purpose without filler or redundant explanation. It is concise and well-structured, making it easy to parse.
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 the tool's moderate complexity (8 optional filters, no output schema, no annotations), the description is too sparse. It does not explain that the tool returns a list of matching persons, how filters combine, or any operational limits, leaving the agent without essential context for correct 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?
All 8 parameters have descriptions in the schema (100% coverage). The description merely lists some criteria ('gender, birth date range, municipality, citizenship, or civil status') that are already documented, adding no new meaning about parameter combinations, constraints, or defaults.
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 ('Search'), the resource ('persons in the Population Register'), and lists specific filter criteria. It distinguishes from siblings like get_person_folkeregisteret by indicating a multi-criteria search rather than a single-person 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 through 'Search for persons by criteria' but gives no explicit guidance on when to use this tool versus alternatives like get_person_folkeregisteret or get_folkeregisteret_hendelser. No exclusions or alternative mentions are provided.
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 of behavioral disclosure. It only states that the tool returns market value and calculated tax basis, which is output-focused. It fails to explicitly indicate that it is a read-only operation or mention any access restrictions, rate limits, 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?
The description consists of two short, front-loaded sentences. The first sentence names the action and resource, and the second lists the key outputs. There is no unnecessary content, making it highly concise and well-structured.
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, the description should provide more detail about return values. It mentions market value and calculated tax basis at a high level but does not describe their structure or any edge cases, prerequisites, or special conditions. The description is adequate for a simple getter but leaves some gaps.
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 the schema already fully documents all parameters. The description adds no additional meaning beyond the schema, such as clarifying the role of 'rettighetspakke' or how 'inntektsaar' affects the query. Baseline 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 clearly states the action (get), the resource (property value basis for property tax), and the expected output (market value and calculated tax basis). It distinguishes itself from sibling tools like get_formuesobjekt_fast_eiendom and get_formuesskatt by focusing on the tax basis specifically.
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 by its title and content, but it does not explicitly state when to use this tool versus alternatives. There is no mention of exclusions or comparison to sibling tools such as get_formuesobjekt_fast_eiendom or get_skattemelding, leaving the context implicit.
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 disclose behavioral traits. It only states 'Retrieve', which implies read-only, but adds no context about response format, error handling, or prerequisites. It does not explain what is returned or any limitations.
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 a single, front-loaded sentence with no unnecessary words. It states the action, resource, and scope efficiently.
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 two simple parameters and no output schema. While the description conveys the core purpose, it lacks information about the return value or any special cases, making it minimally adequate for a complex tax-retrieval 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 input schema provides full descriptions for both parameters (norskIdentifikator and inntektsaar) with 100% coverage. The description adds no additional parameter semantics, so 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?
The description clearly identifies the action (retrieve), the resource (tax return/skattemelding), and the scope (person, year). This distinguishes it from siblings like get_skattemelding_frister (deadlines) and validate_skattemelding (validation).
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 retrieving a tax return but provides no explicit guidance on when to choose this over related tools such as get_inntekt_for_year or get_beregnet_skatt. No exclusions or alternatives 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?
No annotations are provided, so the description must disclose behavior. It only states that it gets events, but does not mention that it operates on sequence numbers (fraSekvens) or what the response looks like, which is a significant gap for a paginated event stream.
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 no redundant words. Front-loaded with action verb and resource, and the purpose clause is efficient.
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 no annotations and no output schema, the description should explain the sequence-number-based pagination mechanism and how it relates to the current sequence tool. It does not, leaving the agent unsure how to use fraSekvens or what the returned events contain.
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 covers both parameters with descriptions (100% coverage), so the baseline is 3. The description adds no additional parameter semantics beyond the schema, so the baseline stands.
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 'Get' tied to a concrete resource ('population register change events'), and adds a clarifying Norwegian term 'hendelsesliste' plus a usage purpose ('track changes to person records'), clearly distinguishing it from sibling tools like get_person_folkeregisteret which fetch single person records.
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 states a use case ('Use to track changes to person records'), indicating when this tool is appropriate. However, it does not explicitly mention alternatives or when not to use it, such as pointing to get_folkeregisteret_current_sekvens for the latest sequence number.
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 burden of behavioral disclosure. It does disclose a key behavior by noting 'Aggregates monthly data', which indicates the tool combines monthly income data. However, it lacks details on output format, required permissions, or error handling, so transparency is only partially addressed.
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 consists of two concise sentences, with the main purpose front-loaded in the first sentence and a valuable behavioral detail in the second. No redundant or unnecessary information is present.
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 get tool with well-documented parameters, the description covers the core functionality and aggregation behavior. However, it does not describe the return value format or explicitly differentiate from sibling tools like get_inntekt, so it is not fully complete for an agent without prior 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 input schema provides descriptions for all three parameters (100% coverage), so the schema already handles parameter semantics. The description adds minimal extra meaning beyond referring to 'a given year', which aligns with the inntektsaar parameter. Thus, a 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 clearly states the tool retrieves all income for a person across all 12 months of a given year, using the specific verb 'Get' and resource 'income for a person', and the phrase 'Aggregates monthly data' distinguishes it from a simple per-month retrieval.
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 description provides no guidance on when to use this tool versus alternatives like get_inntekt, nor does it mention exclusions or preferred contexts. It only states what the tool does, not when to choose 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 burden of behavioral disclosure. It does reveal the return variants and implies read-only behavior through 'Get', but it omits details about required permissions, error conditions, or absence of side effects. This is adequate for a simple retrieval but not comprehensive.
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, front-loaded with the primary action, and every phrase adds value: the resource, the employee scope, and the expected return variations. There is no redundancy or unnecessary 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?
For a simple get tool with fully described parameters and no output schema, the description satisfactorily explains the high-level return values. However, it does not specify the response shape or handle edge cases, and it does not clarify the distinction from related skattekort workflow tools, so it falls just short of 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?
The input schema already provides descriptions for all three parameters, so schema coverage is 100%. The description adds context about the return values but no parameter-specific meaning beyond what the schema offers, warranting the baseline score of 3.
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 ('Get'), the resource ('tax deduction card'), and the target ('for an employee'). It also specifies what is returned (table number, percentage rate, or frikort status), which distinguishes this direct retrieval tool from the order/status/result sibling tools.
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 explicit guidance is given about when to use this tool versus alternatives such as order_skattekort or get_skattekort_resultat. The description implies a read operation for tax card data but does not mention exclusions or related workflow steps, leaving potential ambiguity for an agent.
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 disclose behavioral traits on its own. It only says 'Submit' and the legal requirement, but does not mention side effects, authentication requirements, idempotency, possible validation errors, or what happens after submission. This is a significant gap for a mutation 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?
The description is two short sentences, front-loaded with the core action and target. The second sentence provides useful legal/periodicity context without redundancy. Every word 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?
Given the tool is a submission action with no annotations and no output schema, the description is incomplete. It does not state what the response contains, how to check submission status, or whether prior validation is needed. Sibling tools like get_amelding_status exist but are not referenced, leaving the agent without a complete workflow picture.
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% with a single 'amelding' parameter described as 'A-melding payload (see AMeldingRequest type).' The description adds the clarifying phrase 'wage and personnel report,' which provides some domain context, but it does not add structural details beyond what the schema already references.
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-resource pair: 'Submit an A-melding (wage and personnel report) to Skatteetaten.' This clearly identifies the tool's action and target, and distinguishes it from sibling tools like submit_tredjepartsopplysninger and the various get_/validate_ 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 states when this tool is relevant: 'Required for all employers monthly.' This provides clear context for use, though it does not explicitly mention alternatives or when-not-to-use scenarios, such as validating first with validate_skattemelding or checking status via get_amelding_status.
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 provided, the description carries the full burden of behavioral disclosure. It only says 'Submit' which implies a write operation, but it does not explain what happens after submission, whether it is synchronous, if there are authorization requirements, or how errors are surfaced. This is a significant gap for a mutation 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?
The description is two sentences long, front-loaded with the core action and purpose, and contains no redundant information. Every word earns its place, making it highly concise and well-structured.
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 the tool's complexity—a single object parameter with nested structure, no output schema, and no annotations—the description is incomplete. It lacks information about the expected response, how to check submission status (despite the sibling status tool), and any prerequisites or side effects, leaving critical gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes 'data' as a 'Tredjepartsopplysninger payload' with 100% coverage, so the baseline is 3. The description adds that the data contains 'taxpayer data', which gives some semantic context beyond the schema, but it does not explain the structure or format of the payload, nor does it compensate for the nested object complexity.
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 (Submit), the resource (third-party information/tredjepartsopplysninger), and the destination (Skatteetaten). It distinguishes itself from sibling tools by using the verb 'submit' rather than 'get', and the mention of banks, insurance companies, and brokers clarifies 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on who should use this tool (banks, insurance companies, brokers) and for what purpose (reporting taxpayer data). However, it does not explicitly state when not to use it or mention alternative tools like get_tredjepartsopplysninger_status, leaving some ambiguity for 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 burden of behavioral disclosure. It states the returned data (unpaid claims held by Skatteetaten) and implicitly indicates a read operation via 'Get'. However, it lacks explicit statements about safety, authorization requirements, or any side effects. The description adds some context but does not fully compensate for the absence of annotations.
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, consisting of two short sentences. The first sentence states the core action, and the second clarifies the result. There is no redundant or extraneous information, making it efficient and easy to parse.
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 a simple getter with no output schema, so the description must provide enough context for an agent to invoke it correctly. It explains what is returned but lacks important context about the 'rettighetspakke' parameter, which is required and likely related to access rights. The description is adequate for basic understanding but incomplete for fully informed usage, especially regarding required authorization 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 description coverage is 100%, so the schema already documents both parameters with minimal meanings ('Rights package' and 'Norwegian national identity number'). The tool description does not add any extra explanation of parameter usage, particularly the 'rettighetspakke' parameter, which is not obvious from its name. With high schema coverage, baseline 3 is appropriate; no additional value is provided by the 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 identifies the tool as retrieving outstanding tax debts (restanse) for a person, using a specific verb ('Get') and a specific resource ('outstanding tax debts'). It further clarifies the content by stating it returns unpaid claims held by Skatteetaten, which distinguishes it from other tax-related getters like get_krav or get_betalinger.
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 retrieving a person's outstanding tax debts, but it does not explicitly state when to use this tool over alternatives or provide exclusions. Sibling tools like get_krav (claims) and get_betalinger (payments) exist, and no differentiation or selection guidance is given. This is only implicit usage guidance.
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. It only says 'Retrieve' (implying read-only) and 'completed order' as a precondition, but does not disclose error behavior for incomplete orders, authentication needs, response format, or any side effects. This is a significant gap for a no-annotation 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?
A single, front-loaded sentence with no filler. Every word earns its place, and it conveys the core purpose and key condition efficiently.
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-parameter retrieval tool without output schema, the description covers the essential purpose and a key usage condition. However, it lacks any hint about the result contents, the relationship to sibling tools like order_skattekort (beyond the parameter description), or potential failure scenarios, leaving it minimally adequate.
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 ordreId as 'Order ID from order_skattekort', giving 100% coverage. The description adds no further parameter detail, but since the schema fully documents the parameter, 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 ('Retrieve') and resource ('skattekort results for a completed order'), clearly distinguishing it from siblings like order_skattekort (ordering) and get_skattekort_ordre_status (status only). The qualifier 'completed order' removes ambiguity about what results are being fetched.
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?
'For a completed order' provides clear context that this should be used only after an order has been finalized, implying the sequence relative to order_skattekort. However, it does not explicitly name alternatives or say when not to use it, so it stops short of full exclusion 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?
No annotations are provided, so the description must disclose behavior. 'List' implies read-only, and the scope is clear, but no additional behavior (e.g., pagination, return format) is disclosed.
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 a single concise sentence that is front-loaded and contains no waste.
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 lacks details about the return value or response structure (no output schema), though the core purpose is clear. For a simple list tool, this is functional but incomplete.
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 description does not elaborate on parameters beyond the schema; both parameters are already described in the schema with 100% coverage, so no additional value is added.
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 'List' as a specific verb and identifies the resource 'A-meldinger' with a clear scope ('submitted for a given calendar month'). It distinguishes from siblings like submit_amelding or get_amelding_status.
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?
No explicit guidance on when to use this tool vs alternatives is provided. The description implies usage for monthly listing, but does not mention exclusions or alternative tools for specific status checks.
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 full responsibility for behavioral disclosure. It discloses 'No authentication required' and the verb 'Get' implies a read-only operation, but it omits details about return format, data source, or potential annual changes. The minimal disclosure covers basic safety but not full behavioral 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 a single, compact sentence that expands the BSU acronym and provides the key fact about authentication. It is front-loaded and avoids unnecessary words, making it efficient.
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 zero-parameter, no-output-schema nature, the description is fairly complete: it explains what the tool returns conceptually (deduction limits) and that no auth is needed. However, it does not specify whether the limits are current/yearly or what exact shape the result takes, which is a minor 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?
The tool has zero parameters and a 100% schema description coverage (empty schema), so there is nothing for the description to add. The baseline of 4 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?
The description clearly states the action ('Get') and the resource ('BSU deduction limits'), and expands the acronym with a parenthetical explanation ('home savings scheme for young people'). It distinguishes itself from sibling deduction tools by focusing specifically on this Norwegian tax scheme.
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 description offers no guidance on when to choose this tool over alternatives like get_rentefradrag or get_reisefradrag. It only notes 'No authentication required,' which is a prerequisite, not a usage context. Thus, it lacks explicit usage guidelines.
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 one behavioral trait: 'No authentication required,' which is useful. However, it does not describe the return format, data currency, or other potential side effects. For a simple read-only lookup, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the primary purpose front-loaded. The second sentence adds the only necessary behavioral note (no authentication). No unnecessary words 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 tool with zero parameters and no output schema, the description covers the core purpose and authentication requirement. However, it could add context about the applicable tax year or data source to help an agent decide between this and a general tax-rate tool. Despite that, it is largely complete for its simplicity.
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 input schema confirms an empty object. With no parameters to document, the description does not need to add parameter-level details. The baseline for zero-parameter tools is 4, and the description's content about rates and thresholds is sufficient.
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 'Get formuesskatt (wealth tax) rates and net wealth thresholds' – a specific verb plus a clearly identified resource. The parenthetical translation aids understanding and the resource is distinct from sibling tools like get_mva_satser or get_trinnskatt_satser, which focus on other tax types.
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 description offers no guidance on when to use this tool vs. alternatives. It only mentions 'No authentication required,' which is a prerequisite, not a usage condition. There are no references to situations where another tool would be more 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?
No annotations are provided, so the description carries the full burden. It discloses the return content (income, deductions, tax) and the operation is implicitly a read ('Get'), but it does not mention permissions, error behavior, or any side effects. This is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded sentences. The first states the purpose, the second lists the return content. No wasted words.
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?
Since there is no output schema, the description appropriately lists the key return components (employer-reported income, deductions, withholding tax). It is complete enough for a simple getter tool, though it omits details about output structure and does not emphasize the rettighetspakke requirement beyond the schema.
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 covers 100% of the parameters with descriptions, so the baseline is 3. The description does not add further meaning about individual parameters, though it clarifies the nature of the income data (employer-reported) which indirectly relates to the rettighetspakke 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 uses a specific verb ('Get') and clearly identifies the resource: income information for a person in a given month. It distinguishes from the sibling tool 'get_inntekt_for_year' by specifying the monthly temporal scope, and it also lists what is returned (employer-reported income, deductions, withholding tax).
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 monthly scope implies when to use this tool, but it does not explicitly mention the alternative 'get_inntekt_for_year' or provide exclusion criteria. There is no guidance on prerequisites such as needing a valid rettighetspakke, though that appears in 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, the description carries the full burden. It discloses a key behavioral trait: 'No authentication required.' However, it does not describe the return format, pagination, or any other side effects. As a read-only rules lookup, the omission is moderate, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states the purpose with the deduction concept, the second notes authentication. Every sentence earns its place, 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 simple, parameterless rules-lookup tool, the description covers the essential purpose and a key access condition. It could be slightly more complete by indicating the format of the rules (e.g., list, text) or year applicability, but given the simplicity, it is nearly complete.
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 baseline is 4. The description adds no parameter-specific details (none needed), but it confirms the tool is a simple lookup. Schema coverage is trivially 100% with no properties.
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: 'Get rules for commuter/travel deduction (reisefradrag / pendlerfradrag)'. It uses a specific verb ('Get'), names the resource with both English and Norwegian terms, and adds scope ('deduction for work travel above the minimum threshold'), distinguishing it from sibling deduction tools.
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 provided on when to use this tool versus alternatives. The description only states 'No authentication required,' which is not a usage guideline. It does not mention exclusions or alternatives like get_hjemmekontor_fradrag or get_bilgodtgjorelse.
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 provides useful context: no authentication required and returns content from the most relevant public page. However, it does not explicitly state read-only behavior or potential rate limits, though search implies non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, direct, with no filler. The first sentence establishes the core functionality and the second adds return and auth context.
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 search tool, the description covers purpose, return value, and auth. It could be enhanced with guidance on when to use this over specific data tools, but overall it is complete enough.
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% with a clear parameter description ('Search query (Norwegian or English)'). The description adds no additional parameter semantics beyond the schema, so 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?
The description states a specific action (search) on a specific resource (skatteetaten.no) for any tax-related topic, clearly distinguishing it from sibling tools that return specific data points or search persons.
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 for general tax-related queries but does not explicitly compare with alternatives like get_skatteetaten_page or specific getter tools. No exclusions or when-not guidance is 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?
With no annotations provided, the description carries the full burden. It adds one behavioral trait: 'No authentication required.' However, it does not disclose what the response contains (e.g., amount in NOK, year, object structure) or any error behavior, leaving the return format ambiguous for a 0-parameter 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?
The description is two concise sentences, front-loaded with the verb 'Get'. Every clause earns its place: the definition clarifies the purpose, and the authentication note adds a critical behavioral detail. No waste or redundancy.
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 0-parameter, no-output-schema tool, the description gives the core domain definition and authentication requirement, which is helpful. However, it lacks any indication of the return format or whether the value is year-dependent, leaving a clear gap in what an agent should expect from the response.
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 input schema has zero parameters, so the description does not need to explain parameter semantics. The schema covers all parameters vacuously, and the baseline for 0-parameter tools is 4. The description adds contextual meaning about the allowance without needing to describe 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 states exactly what the tool does: 'Get personfradrag (personal allowance) — the standard deduction applied to all taxpayers before income tax is calculated.' It uses a specific verb and resource, and the definition distinguishes it from sibling deduction tools like get_minstefradrag and get_fagforeningsfradrag.
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 provides clear context about what the deduction is, implying when it should be used (when the standard personal allowance is needed). However, it does not explicitly mention when not to use it or point to alternatives, such as other deduction tools for specific cases.
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 adds 'current (latest)' indicating the value changes over time, but does not disclose authentication requirements, return format, or whether a prior sequence number is needed. For a simple getter, this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose without filler. Every word 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?
Given the tool's simplicity (0 parameters, no output schema), the description is sufficient: it states what is returned (sequence number) and the scope (current/latest). However, it does not explain how this fits into the event feed polling flow, which a more complete description could add.
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 baseline is 4. The description does not need to explain parameter details, and there are none in 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 gets the current (latest) sequence number for the population register event feed. It uses a specific verb (get) and resource, and distinguishes itself from sibling tools like get_folkeregisteret_hendelser (which likely returns events) and get_person_folkeregisteret.
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 used to retrieve the current sequence number, offering clear context but no explicit guidance on when to use it versus alternatives like get_folkeregisteret_hendelser. There are no exclusions or examples of 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 provided, the description carries the burden of behavioral disclosure. It adds 'No authentication required,' which is useful, but it does not explicitly state the operation is read-only, describe the output format, or mention any side effects or rate limits. For a simple read-only tool, this is adequate but not comprehensive.
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 long, front-loaded with the purpose, and contains no redundant or filler text. Every word serves a purpose.
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 no parameters and no output schema. The description provides sufficient context about its purpose and authentication requirement, though it does not detail the structure of the returned rules/limits. Given the simplicity, this is nearly complete.
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 parameter meanings. Per the rubric, 0 params gives a baseline of 4, and the description adds no irrelevant parameter 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 tool's function with a specific verb ('Get'), resource ('rules and limits for interest deduction'), and scope ('on mortgage and other loans'). It distinguishes itself from sibling tools like get_reisefradrag and get_bsu_fradrag by focusing on rentefradrag.
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 retrieving interest deduction rules when needed, but does not explicitly state when to use it versus alternatives, nor does it mention any prerequisites or exclusions. Since the tool has no parameters, the implied usage is sufficient but not explicitly documented.
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 key behavioral trait that no authentication is required. It does not, however, mention the return format, whether rates are percentages or decimals, or any update frequency, leaving moderate gaps in 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 two concise sentences with no filler. The first states the function, the second provides the authentication requirement. Every word contributes value, and it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only rates lookup, the description covers the essential facts: what data is returned and the access requirement. It doesn't specify response structure or effective dates, but given the simplicity and lack of output schema, this is a minor omission.
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 schema is entirely complete by definition. The description correctly avoids mentioning parameters, and the baseline for zero-parameter tools is met.
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 'Get' and identifies the exact resource: Skatteetaten's current interest rates for underpayment, overpayment, and late payment. This clearly distinguishes it from sibling tools like get_skattesatser and get_mva_satser, which focus on tax rates rather than interest rates.
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 whenever interest rates are needed and notes that no authentication is required, which is a useful prerequisite. However, it does not explicitly mention alternative tools or when not to use this tool, leaving the agent to infer context from the sibling list.
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 disclosing behavior. It mentions that no authentication is required, which is useful. However, it does not describe the response format, potential errors, or any limitations. For a simple getter this is acceptable, but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and key behavioral note. Every word earns its place with no 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 zero-parameter, no-output-schema tool, the description is largely complete. It states the resource (deadlines/key dates) and the tax year scope. It does not explicitly detail the return structure, but given the simplicity and clear naming, this does not create a significant 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?
The tool has zero parameters, and the schema is empty. The baseline for no parameters is 4, and the description correctly adds no parameter-related clutter. There is no need to explain parameters that do not exist.
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 gets tax return deadlines and key dates for the tax year, using a specific verb ('Get') and a specific resource ('tax return deadlines'). It is easily distinguished from sibling tools like get_skattemelding, which retrieves the tax return itself.
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 provides some usage context by noting that no authentication is required, implying it is a public read-only tool. However, it does not explicitly explain when to use this tool versus alternatives like get_skattemelding, nor does it mention any prerequisites or exclusions.
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 that the return consists of aggregated income, assets, and deductions, which is useful, but it omits other behavioral aspects such as authorization requirements, data freshness, or error handling. For a simple read operation, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. It avoids unnecessary words and clearly communicates the tool's purpose and output scope.
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 must explain the return value, which it does by enumerating the categories. It is complete enough for a straightforward read tool, though it lacks details on output structure or error handling. Given the tool's simplicity, this is sufficient.
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 provides 100% coverage of all four parameters with descriptions, so the description does not need to compensate. The description adds no additional meaning about parameters like 'stadie' or 'rettighetspakke' beyond what the schema already provides, matching 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 clearly states the tool's function: 'Get aggregated tax basis (summert skattegrunnlag) for a person.' It uses a specific verb and resource, and explicitly notes that it returns 'total income, assets, and deductions without item-level detail,' which distinguishes it from sibling tools that may offer item-level 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 phrase 'without item-level detail' provides clear context that this tool is for aggregated summaries, implying a distinction from more granular tools. However, it does not explicitly name alternative tools or provide a definitive when-not-to-use scenario, so it falls 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.
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 burden. It discloses the key output behavior: 'Returns validation errors, warnings, and deviations.' However, it does not explicitly state that the operation is read-only with no side effects, nor does it mention any prerequisites or limitations beyond what the schema implies. 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 a single sentence that is front-loaded with the action and resource. Every word contributes meaningful information: 'Validate', 'VAT return (MVA-melding) XML document', and the return categories. There is no redundancy or wasted text.
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 tool's simplicity (2 parameters, no output schema, no annotations), the description covers the essential aspects: what the tool does and what it returns. It stops short of a 5 because it does not describe the structure of the returned errors/warnings or explicitly mention that the XML is not submitted and only validated locally.
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 has 100% description coverage for both parameters (meldingstype and xmlContent), so the baseline is 3. The tool description does not add any additional parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Validate') and the specific resource ('a VAT return (MVA-melding) XML document'). It explicitly mentions XML, distinguishing it from the sibling tool validate_mva_melding_json, which validates JSON. This gives a specific verb+resource and differentiates from siblings.
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 that this tool is for validating XML VAT returns, which implies it should be used when the input is XML rather than JSON (as with the sibling validate_mva_melding_json). However, it does not explicitly mention alternatives or when not to use it, so it falls 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns errors, warnings, and deviations, which is useful output context. Since no annotations are provided, the description carries the full burden, but it does not mention side effects (e.g., whether it writes anything) or any authentication requirements. The absence of these details makes this adequate but not exceptional.
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 a single, tightly worded sentence that includes the action, resource, timing, and return type. There is no extraneous information, making it highly efficient and front-loaded.
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 has low complexity with two simple parameters and no output schema, so the description covers the core aspects of purpose and output. It could further detail the structure of the returned errors or mention any limitations, but given the simplicity, it is reasonably 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?
The input schema provides 100% coverage with both parameters ('xmlContent' and 'inntektsaar') having descriptions. The description adds no extra parameter semantics beyond what the schema already exposes, 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 clearly states the tool validates a tax return XML document before submission, using the specific verb 'Validate' and the resource 'tax return XML document'. It distinguishes itself from siblings like validate_mva_melding_xml by specifying 'skattemelding' while mentioning a distinct purpose ('before submission').
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 'before submission' provides clear context on when to use the tool. However, there is no explicit mention of when not to use it or alternatives like validation for other XML types (e.g., VAT), though the name and resource distinguish it sufficiently.
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 does disclose a key behavioral trait (no authentication required) and clarifies the nature of the data (tax-free rates per km). However, it does not mention whether this is a read-only operation, data recency, or any limitations, leaving some gaps for a zero-parameter rate lookup.
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 a single, well-structured sentence with no redundant words. It front-loads the main purpose and adds the relevant qualifiers (tax-free per km and no auth) efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only rate lookup with no output schema, the description provides enough context: it explains what is returned (rates per km), the tax treatment, and the auth requirement. There are no missing details that would prevent an agent from invoking it correctly.
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 accepts zero parameters and the schema coverage is 100%, so the schema already fully defines the input space. The description adds no parameter-level meaning, but since there are no parameters, this is acceptable and the baseline of 4 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?
The description clearly identifies the resource as car mileage reimbursement rates (kilometergodtgjørelse / bilgodtgjørelse) and specifies the type of data (tax-free rates per km). This is specific enough to distinguish it from sibling rate-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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Get car mileage reimbursement rates' implies this is the tool to use when mileage rates are needed, but there is no explicit guidance on when to prefer it over alternatives or any exclusions. The 'No authentication required' note provides some context but not full usage 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 must carry the transparency burden. It discloses the data source (skatteetaten.no) and that no authentication is required. However, it does not clarify whether the data is fetched live or cached, nor does it describe the response format (e.g., list vs. object, key-value pairs). These missing details are notable for an agent trying to anticipate 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?
The description is exactly two sentences, with the main action and resource first, supported by a clear scope. Every clause adds value: the source, the covered tax types, and the authentication status. There is no redundancy or filler.
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?
This is a simple zero-parameter tool, so the description does not need to explain complex parameters. However, there is no output schema, and the description does not mention what the returned data looks like (e.g., whether it returns a single object with multiple rates or an array). Given the lack of return type information, the description is not fully complete, but it covers the essential functional aspects.
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 is empty with 100% schema coverage. The description therefore does not need to explain any parameter syntax or defaults. The baseline for zero parameters is 4, and the description adds no unnecessary parameter information, so a score of 4 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 'Get' and names the exact resource ('Norwegian tax rates from skatteetaten.no'). It lists the covered categories (income tax, bracket tax, social security), clearly distinguishing it from sibling tools like get_trinnskatt_satser or get_trygdeavgift which focus on individual categories.
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 when to use this tool: when you need current Norwegian tax rates across multiple categories. It does not explicitly mention alternatives or exclusions, but the scope is well-defined. The statement 'No authentication required' gives practical usage guidance without needing to consult other 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?
With no annotations, the description carries the burden of disclosing behavioral traits. It includes the auth requirement, which is beneficial, but does not describe the output format, whether it returns all zones, or any rate update/recency details. This is a moderate level of transparency for a simple read-only 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?
The description is two sentences, front-loaded with the primary purpose and followed by the auth note. Every word contributes, with no redundancy or unnecessary 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?
Given the tool's simplicity (no parameters, no output schema), the description covers the essential elements: what it gets, the organizing dimension, and access requirements. It could be more explicit about returning rates for all zones, but this is inferable from the absence of parameters and the phrase 'rates by geographic zone.'
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 a baseline of 4 is appropriate. The description does not imply any parameter, and 'by geographic zone' accurately describes how the data is organized in the response rather than a filter input. No mismatch with the empty 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 retrieves employer social security contribution rates by geographic zone, using a specific verb 'Get' and a distinct resource. It differentiates from sibling tools like get_mva_satser and get_skattesatser by naming the exact contribution type.
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 useful context by noting 'No authentication required,' which clarifies that the tool can be used without credentials. However, it does not explicitly mention alternatives or when-not-to-use, though the purpose is specific enough for an agent to infer appropriate usage.
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. It adds a valuable behavioral disclosure: 'No authentication required.' It also explains the semantic meaning of the threshold. It does not describe output format or error behavior, but for a zero-parameter public lookup, 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 long, front-loaded with the action and definition, and contains no filler or redundant information. Every word 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, parameterless, read-only threshold lookup, the description is quite complete: it defines the term and notes the auth requirement. The only minor gap is the lack of output format details, but given the tool's simplicity and the absence of an output schema, this is not a serious omission.
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?
There are 0 parameters, so the schema already provides 100% coverage by default. The description adds no parameter semantics, but none are required for a tool with no inputs; baseline 4 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 clearly states the tool's purpose: 'Get the frikortgrense' and defines it as 'the income threshold below which no tax is withheld.' This specific verb+resource combination distinguishes it from sibling tools that retrieve tax rates or brackets.
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 does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions. It provides context by explaining the threshold's meaning and that no authentication is required, but usage guidance remains implied rather than explicit.
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 burden. The verb 'Get' implies a read-only operation, and 'valid VAT codes' adds semantic value. However, it does not disclose response format, authentication needs, or any edge cases. For a simple read-only lookup, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is concise and free of fluff. It effectively states the tool's purpose without unnecessary details.
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 zero-parameter complexity and no output schema, the description adequately states what is returned (a list of valid VAT codes) and the purpose (reporting). No additional clarification seems necessary for such a simple lookup tool, though specifying the source or format could further enhance completeness.
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% (vacuous). Baseline for 0 params is 4, and since there are no parameters to explain, the description need not provide additional parameter semantics.
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: 'Get the list of valid VAT codes (MVA-koder)'. The resource is specific ('valid VAT codes' for reporting) and distinguishes this from siblings like get_mva_satser (VAT rates) and validate_mva_melding (validation).
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 'for reporting' provides clear context for when to use this tool, but there is no explicit mention of alternatives or when-not-to-use scenarios. Given the many sibling tools, a brief exclusion (e.g., 'not for VAT rates') would improve to 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 full burden. It discloses that no authentication is required and that pages are public, which is useful. However, it omits details about response format, error behavior, or potential limitations, leaving some ambiguity for such a generic fetch 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?
The description is two sentences: the first states the core function, the second provides guidance and auth info. It is front-loaded and every sentence earns its place 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 parameter and no output schema, the description is sufficiently complete: it explains the scope, the path usage, the fallback nature, and the lack of authentication. It could mention return type, but that is not critical for the tool's purpose.
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 100% coverage for the single parameter, including an example. The description adds no extra meaning beyond 'by its path,' 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 clearly states the tool fetches public pages from skatteetaten.no by path, with a specific verb and resource. It also differentiates from siblings by positioning it as a fallback for topics not covered by specific tools.
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?
Explicitly provides usage guidance: 'Use this for topics not covered by specific tools.' This tells the agent when to select this tool over the many sibling tools, and implicitly when not to use it (when a specific tool exists).
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. It explicitly notes 'No authentication required', which is a useful behavioral disclosure. It also implies a read-only operation. However, it does not mention result structure, pagination, or any other behavioral details. For a zero-param index tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary purpose, and contains no redundant or irrelevant information. Every word serves a purpose.
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 (0 params, no output schema), and the description covers purpose, useful context, and auth requirements. It falls short of describing the exact format of the returned index (e.g., list of links, topics), but this is not critical for a discovery tool. Overall, it is complete enough for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description's meaning is essential. It explains what the tool does with no inputs, returning a full index. This adds context beyond the empty schema, warranting a baseline 4.
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 specifies the verb 'Get' and the resource 'full index of all rate pages on skatteetaten.no/satser/'. It also distinguishes this from sibling rate-specific tools by noting it is for 'discovering what topics are available', implying it returns a directory rather than actual rate 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 states 'useful for discovering what topics are available', which clearly indicates a use case: use this tool to explore the range of rate topics before querying specific rate tools. It does not explicitly name alternatives or exclusions, but the context is clear enough for a discovery tool.
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 of behavioral disclosure. It clarifies that the tool is a read-only lookup ('Get the list'), but it does not describe the exact format of the returned list, potential error scenarios, or any required authentication. The description adds useful context about 'valid' types but is minimal for a tool with no output 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?
The description is a single, front-loaded sentence that conveys the essential purpose without any filler. Every word contributes to the meaning, making it highly concise and well-structured.
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 tool has zero parameters and no output schema, the description does a good job of stating the return value ('list of valid oppgavetyper') and the domain ('third-party data reporting'). However, it omits details such as whether the list is sorted, whether it includes deprecated types, or any error conditions, which could be important for an agent invoking the tool. Still, for a simple lookup, the information 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?
The input schema has zero parameters, resulting in a baseline of 4. The description adds contextual meaning by explaining that 'oppgavetyper' are report types used in third-party data reporting, which is helpful for understanding the purpose even though there are no parameters to document.
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 a list of valid oppgavetyper (report types) specifically for third-party data reporting. The verb 'Get' and the resource identification distinguish it from sibling tools like get_skattesatser or get_mva_koder, which address different data categories.
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 context is clear: this tool is used to fetch valid oppgavetyper for third-party data reporting, which is implied to be a prerequisite for submitting such data. However, it does not explicitly state when not to use it or mention alternatives among the sibling tools, so it lacks explicit exclusion guidance.
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 for behavioral disclosure. It adds that no authentication is required and that data is returned for each bracket, which is useful for a public read operation. However, it does not describe the response format, any rate limits, or whether the data reflects the current year, which prevents a perfect score.
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 entire description is a single, front-loaded sentence that states exactly what the tool does and adds an accessibility note. No unnecessary words or repetition; every phrase 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 public lookup, the description covers the essential context: what data is returned (rates and thresholds), the scope (each bracket), and authentication requirements. It would be slightly more complete if it mentioned whether the rates are for the current tax year or if any versioning exists, but the simplicity of the tool makes this a minor 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?
The tool has 0 parameters and the input schema is empty, so there are no parameter semantics to explain. Per the baseline for zero-parameter tools, a score of 4 is appropriate; the description appropriately focuses on the tool's purpose rather than nonexistent 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 uses the specific verb 'Get' with a clearly defined resource: 'trinnskatt (bracket/step tax) rates and income thresholds for each bracket.' This clearly distinguishes it from sibling tools like get_skattesatser or get_mva_satser by naming the exact tax type and data returned.
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 only usage guidance is 'No authentication required,' which clarifies accessibility but does not provide explicit direction on when to choose this tool over alternatives. Among many sibling tax-rate tools, the description does not mention alternatives or exclusions, leaving the usage context implied by the tool name.
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 a key trait: 'No authentication required.' However, it doesn't mention whether the rates are current/historical, the return format, or any limitations. For a simple zero-parameter lookup, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences: the first states the purpose with helpful parenthetical examples, the second notes authentication requirements. Every word earns its place with no fluff, making it exemplary for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is extremely simple: zero parameters, no output schema. The description fully covers its purpose, scope (asset classes), and an important access detail (auth). Nothing essential is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, and with 0 parameters the baseline is 4. The description confirms no input is needed ('Get depreciation rates for different classes'), so there is nothing additional to explain.
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: 'Get depreciation rates (avskrivningssatser) for different classes of business assets.' It uses a specific verb ('get') with a specific resource ('depreciation rates') and provides examples of asset classes, distinguishing it from sibling tools like get_mva_satser and get_skattesatser.
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 offers clear context for when to use the tool: whenever depreciation rates for business assets are needed. It doesn't explicitly name alternatives or exclusions, but the purpose is so distinct that an agent would correctly select it over sibling rate tools. Lacks explicit 'when not to use' guidance, so a 4 is appropriate.
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. It discloses that no authentication is required and that the deduction is applied automatically, adding useful context beyond the tool name. It does not detail error handling or data freshness, but for a simple read-only lookup this is sufficient.
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 three short sentences, front-loaded with the primary purpose. Each sentence adds distinct value: what it retrieves, the automatic application, and the authentication requirement. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter lookup tool with no output schema, the description sufficiently covers the return content (rates and maximum amounts), operational context (automatic application), and access requirements (no authentication). Contextually complete for its simplicity.
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 schema is already complete. The description need not explain parameters, and the baseline for 0 parameters is 4.
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 retrieving standard employment deduction (minstefradrag) rates and maximum amounts. It uses a specific verb ('Get') and resource, and the English translation helps disambiguate from other deduction tools in the sibling list.
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 looking up deduction rates, especially since the deduction is 'applied automatically' to wage income. However, it does not explicitly state when to choose this tool over alternatives or provide any exclusions.
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 burden of disclosure. It adds a useful behavioral detail: 'No authentication required.' It also implies a read-only lookup via 'Get'. However, it does not describe return format or data scope, which would be even better.
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 a single, front-loaded sentence stating the purpose, followed by a brief auth note. No wasted words; every phrase adds 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 zero-parameter, no-output-schema lookup tool, the description covers the core purpose and authentication need. It lacks details on the response structure, but this is acceptable for a simple static rules/rates endpoint.
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 input schema has zero parameters, and the rubric gives a baseline of 4 for such cases. The description adds no parameter-specific information, but none is needed since there are no parameters to explain.
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 'Get' and clearly identifies the resource as 'rules and rates for the home office deduction'. It is distinct from sibling tools that handle other deductions (e.g., get_reisefradrag).
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 implicitly states when to use this tool (when home office deduction rules/rates are needed) and the tool name aligns with the resource. No explicit exclusions or alternatives are mentioned, but the context is clear given the sibling tool list.
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 full burden. It explicitly states 'No authentication required,' which is a useful behavioral trait. The read-only nature is implied by 'Get rates,' and there are no side effects to disclose. For a simple zero-parameter lookup, this is adequate.
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 a single sentence of 17 words, front-loaded with the core purpose ('Get corporate income tax rates'), followed by a meaningful qualifier ('No authentication required'). Every word earns its place, with no redundancy or 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?
Given the tool's complexity (zero parameters, no output schema, no annotations), the description covers the essential aspects: what it returns (rates), for whom (limited companies and other entities), and access requirements (no authentication). It stops short of specifying the format of the rates (e.g., percentage), but this is a minor gap for such a simple tool.
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 input schema has zero parameters, so the baseline is 4. The description correctly indicates that no parameters are needed, and since there are no parameters, no additional semantic information is required.
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 ('Get') and resource ('corporate income tax (selskapsskatt) rates'), clearly distinguishing it from sibling tools that handle other tax types (e.g., VAT, personal tax). The scope 'for limited companies and other entities' adds clarity about applicability.
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 conveys clear context: use this tool when you need corporate income tax rates for companies. It does not explicitly mention alternatives or exclusions, but for a parameterless getter, this is sufficient. The note about no authentication adds practical usage guidance.
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 full burden. It adds the behavioral context that 'No authentication required', which is valuable beyond the name. As a 'Get' operation, it implies read-only behavior, and the description gives sufficient transparency for a simple lookup, though it does not describe response format or edge cases.
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 a single sentence that front-loads the key information (what it gets, for which income types) and adds the auth note. Every word earns its place, with no redundancy or irrelevance.
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 no-parameter, read-only tool with no output schema, the description provides the essential context: purpose, scope, and authentication requirement. It is sufficiently complete for an agent to select and invoke the tool correctly, though it could optionally hint at the response format.
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 baseline is 4. The description mentions income types, which are data dimensions rather than parameters, but this still helps set expectations for the returned data. No parameter explanation is needed since the schema is empty.
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 'Get social security contribution (trygdeavgift) rates' with a specific verb and resource, and further specifies the scope by income type (wage, self-employed, pension). This distinguishes it from sibling tools like get_skattesatser and get_mva_satser.
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 the tool (when trygdeavgift rates are needed) and provides useful context about the income types covered. It does not explicitly mention alternatives or exclusions, but the scope is clear enough for an agent to select it appropriately among similar rate-lookup 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?
Since there are no annotations, the description carries full responsibility for behavioral transparency. It discloses key behavioral details: it returns VAT rates and categories, and does not require authentication. It does not describe output format or potential errors, but for a simple zero-parameter lookup, the disclosure is adequate.
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 a single, well-structured sentence that immediately states the purpose, lists the exact rates, and adds a practical note about authentication. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter tool with no output schema, the description is complete: it fully specifies what is returned (standard and reduced VAT rates with their categories) and the access requirement. No additional context is needed to understand or invoke the tool correctly.
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 input schema already reflects this with an empty properties object. The description does not need to explain parameters, and the baseline for 0-parameter tools is 4. The description adds context about the returned rates but not parameter semantics, which is appropriate here.
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 with a specific verb ('Get'), a specific resource ('Norwegian VAT rates'), and concrete values (25%, 15%, 12%) with categories. This distinguishes it from sibling tools like get_skattesatser (general tax rates) and get_mva_koder (VAT codes), making the purpose unambiguous.
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 that this tool is for obtaining Norwegian VAT rates and notes that no authentication is required, which is a useful usage guideline. However, it does not explicitly state when to use this tool versus alternatives or include exclusions, so it falls 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.

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:

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

Score Badge

Copy to your README.md:

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

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/bambinobino/mcp-skatteetaten'

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