skatt-mcp

Server Quality Checklist

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

Latest release: v0.0.1
Disambiguation4/5
Most tools have distinct purposes (e.g., calculate_aksjegevinst vs. calculate_kryptogevinst), but there is overlap between the high-level beregn_skatteoppgjoer_nordnet (which combines import and calculation for Nordnet) and the separate import_transaksjoner_nordnet + calculate_* tools. Descriptions are detailed enough to differentiate, though.
Naming Consistency3/5
Tool names mix Norwegian (beregn, import, lookup) and English (calculate) verbs, and nouns are a mix of Norwegian and English. However, the pattern is consistently verb_noun, making it readable despite language inconsistency.
Tool Count5/5
12 tools is well-scoped for a tax calculation server covering various asset types, imports, lookups, and specific tax calculations. Each tool earns its place without being overwhelming or insufficient.
Completeness4/5
The toolset covers major Norwegian tax domains (shares, funds, crypto, housing, ASK, wealth, income, skjermingsfradrag) with import from Nordnet and legal lookups. Minor gaps include no single aggregation tool for combined tax return and lack of imports from other brokers.
Average 4.2/5 across 12 of 12 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 13 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It mentions multi-ticker and outputs but does not explicitly state that the tool is read-only or has no side effects. This is a gap for a calculation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second lists outputs. Front-loaded, no fluff. Every sentence 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 medium-complexity calculation tool with no output schema, the description adequately lists the returned values (årets skjerming, used/unused, carry-forward, taxable dividend per ticker). However, it lacks details on algorithm assumptions or prerequisites beyond what schema provides.
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 67%, with many fields already described. The description does not add significant semantics beyond the schema, but it helps contextualize inputs by linking to outputs. 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 it calculates 'skjermingsfradrag' for dividends on personally-owned shares, specifying multi-ticker support and listing outputs. This distinguishes it from sibling tools like calculate_aksjegevinst (capital gains) or calculate_formuesskatt (wealth 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 description provides context (dividends on personally-owned shares) but does not explicitly state when to use this tool versus alternatives or any exclusions. Usage is implied but not guided.
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 key behaviors: FIFO per ISIN, use of fund classification file, specific tax rules (upjustering factor 1.72, skjermingsgrunnlag formula), and acceptance of inngangs-carry for continuity. It does not mention destructive actions or auth needs, but as a calculation tool, 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?
Two sentences packed with essential information. Every phrase adds value: tax calculation, FIFO, classification file, tax rules, carry. No unnecessary 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?
Given the complexity (3 parameters, nested objects, no output schema), the description effectively explains the tax logic and parameter roles. It could mention prerequisites like needing the classification file or output format, but it is largely complete for a calculation 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?
Schema description coverage is 33%, so the description must compensate. It adds meaning by explaining the role of 'transaksjoner' (transaction array), FIFO per ISIN, and 'inngangs_carry_per_isin' for continuity. However, it does not detail each parameter's syntax or constraints beyond what the schema 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 tool calculates tax for mutual funds using a transaction array and FIFO per ISIN. It distinguishes itself from sibling tools like calculate_aksjegevinst (stock gains) and calculate_kryptogevinst (crypto gains) by specifying 'verdipapirfond'.
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 does not explicitly state when to use this tool versus alternatives. It mentions using 'fond-klassifisering.json' but provides no guidance on when this tool is appropriate compared to sibling tools like calculate_aksjegevinst or calculate_skjermingsfradrag.
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 that it returns data, without mentioning whether it is read-only, has side effects, or requires authentication. For a simple lookup, this is a 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?
Two sentences: one for function, one for use case. No unnecessary words, well-structured for quick understanding.
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?
As a simple lookup tool with one parameter and no nested objects, the description is mostly complete. It could mention the output format, but given the lack of output schema, the current info is sufficient for an agent to decide to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter description. The description adds the context 'for a given income year' which reinforces the schema, but does not provide additional syntactic details. 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 verb 'Returnerer' and resource 'alle skattesatser og grenser for et gitt inntektsår', making its purpose specific. It distinguishes from sibling tools like calculate_inntektsskatt or lookup_paragraf by focusing on rates and limits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a use case hint: 'Nyttig for å inspisere hvilke satser som brukes i beregningene.' This helps the agent know when to use it, though it does not explicitly exclude alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds valuable context: it reveals the tool uses correct tax valuation per asset type, proportional debt allocation, and shows intermediate calculations. This goes beyond basic purpose, though it could mention any limitations or 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?
Two sentences, front-loaded with the core function, no filler. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately conveys what the tool returns (per-post breakdown and intermediate calculations). It is sufficient for an agent to understand the tool's output, though edge cases are not covered.
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 high (75%), so the baseline is 3. The description does not add extra meaning beyond what the schema provides for parameters; it mentions per-asset-type valuation but that is already implied by the enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it calculates wealth tax with correct tax valuation per asset type and proportional debt allocation, and shows per-item breakdown and intermediate calculations. This distinguishes it from sibling tools like calculate_inntektsskatt or calculate_aksjegevinst.
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 when-to-use or when-not-to-use instructions are provided. The description implies it's for wealth tax calculation, but lacks guidance on alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behaviors: FIFO method, stock adjustment, implicit tax (22%), per-sale breakdown, aggregated totals, and remaining lots. No destructive behavior is mentioned, but for a calculation tool 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 two sentences, front-loaded with the main purpose, and includes essential details without fluff. Every sentence adds value.
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?
Given the tool has two parameters (one required) and no output schema, the description sufficiently explains what the tool calculates and what outputs are produced (per-sale breakdown, totals, remaining lots). No gaps identified.
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 descriptions for both parameters. The description adds minimal new meaning beyond the schema (e.g., 'multi-ticker støttes' is already in schema). 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 states it calculates realized stock gains/losses per ticker using FIFO. It distinguishes from sibling tools (e.g., calculate_boliggevinst, calculate_kryptogevinst) by specifying it's for stocks and mentioning multi-ticker and tax details.
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 stock gain calculation with FIFO but does not explicitly say when to use this tool over alternatives or provide exclusions. Sibling tool names give context, but no direct 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 exist, so the description carries full burden. It explains the tool's behavior for three scenarios and what outputs it provides (skjermingsberegning, skatteoppgjør, new state). It does not mention side effects, but as a calculation tool, this is sufficient. Could state that it does not modify data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that efficiently conveys purpose and scenarios. While slightly verbose, it is front-loaded and all sentences contribute useful information. Could be tightened without losing content.
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 no output schema, the description lists what outputs are produced (skjermingsberegning, skatteoppgjør, new state). It covers the three scenarios adequately. The parameter details are well-covered in the schema. Missing explicit return format, but acceptable for a calculation 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?
Schema description coverage is 88%, so baseline is 3. The description adds overall context but does not enhance individual parameter meanings beyond the schema's own descriptions. No new parameter details are introduced.
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 specifies a clear verb ('Beregner') and resource ('skattekonsekvenser for en aksjesparekonto'). It distinguishes from sibling tools by explicitly stating it handles ASK-specific scenarios (ingen aktivitet, uttak, avslutning), which none of the sibling tools cover directly.
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 outlines when to use the tool: for calculating tax consequences of an ASK account with three distinct scenarios. It does not explicitly state when not to use it or provide alternatives, but context signals (sibling tools) imply usage boundaries. Lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: it calculates multiple tax components, supports various income types and deductions, and shows all intermediate calculations. This is comprehensive for a calculation tool, leaving no ambiguity about what the tool does.
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 (three sentences) and front-loaded with the main purpose. Every sentence adds value: first states what it calculates, second lists supported types, third lists deductions and mentions intermediate calculations. No redundant information.
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 11 parameters, no output schema, and no annotations. The description covers the main behavior and inputs but lacks details about the return format (beyond mentioning between calculations), constraints like the year limitation (only 2025), or error handling. For a complex tool, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 73%, so the schema already documents most parameters. The description groups deductions together but adds little semantic value beyond the schema. For example, 'andre_fradrag' and 'bsu_innskudd' are already described in the schema. The marginal benefit is low, resulting in an average score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it calculates three specific types of income tax (alminnelig inntektsskatt, trinnskatt, trygdeavgift) and specifies supported income types (lønn, pensjon, næring). This is a distinct tool compared to sibling tools like calculate_boliggevinst or calculate_formuesskatt, ensuring unambiguous purpose.
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 lists supported income types and optional deductions, providing clear context for when to use the tool. It does not explicitly mention when not to use it or alternative tools, but the context from sibling tools suggests it is for Norwegian income tax calculation. The guidance is strong but lacks explicit 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, the description carries full burden. It discloses key behaviors: parsing CSV, grouping by ISIN, automatic routing to stock or fund engines, and return of aggregated tax settlement. It also states what it does not do (dividends). However, it does not explicitly state that the tool is read-only (no data modification) or detail error handling or performance characteristics.
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 a single paragraph of about 4 sentences, covering main action, routing logic, exclusions, and warnings. It front-loads the primary purpose. While effective and not verbose, it could be improved with bullet points or clearer structure for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides a good overview of input and processing but is vague on output structure ('ett samlet skatteoppgjør'). It omits the inngangs_carry_per_isin parameter entirely. The tool is complex with 4 parameters and automatic routing, so more detail on output and the carry parameter would improve 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 description adds meaning beyond the input schema for the main parameters: it explains that csv_filsti and csv_tekst are alternative input methods. The rapporteringsaar parameter is implied in 'rapporteringsåret' but its format, default, and range are not described. The inngangs_carry_per_isin parameter is not mentioned at all. Since schema coverage is high (all parameters have descriptions in the schema), the baseline is 3; the description adds value for the two key input options, earning a 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 states the tool's purpose: takes a Nordnet transaction export, parses, groups by ISIN, and routes to appropriate calculation engines (stocks FIFO, funds) to return a complete tax settlement for realized gains/losses. It explicitly distinguishes from sibling tools by noting that dividends are not calculated here and directing users to calculate_skjermingsfradrag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when and how to use the tool: it specifies the input format (CSV file path or inline raw CSV text), explains the automatic routing logic, and states exclusions (dividends) with a direct reference to the alternative tool. It also mentions that missing ISINs in fund classification are reported as actionable warnings.
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 file encoding (UTF-16 LE TSV), exactly which row types are translated, and that other rows are skipped with reasons. It does not mention authentication or rate limits, but for a file import tool these details are reasonable.
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, no redundancy. The first sentence states the core action and output, the second clarifies processing rules. Every sentence adds value.
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?
Given the simple 1-parameter input and no output schema, the description covers what the tool returns (canonical transaction array, classification hints, skip report) and its relationship to calculate_aksjegevinst. This is complete for a preparatory import 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 single parameter 'filsti' is fully described in the schema with 'Absolutt sti til Nordnet CSV-eksport'. The tool description additionally specifies the exact encoding (UTF-16 LE TSV) which is crucial for correct usage, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a Nordnet CSV export and returns a canonical transaction array for use with calculate_aksjegevinst. It also specifies which row types are processed (KJØPT/SALG/INNLEGG OVERFØRING) and which are skipped, making its purpose distinct from sibling calculation 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 explicitly states it is for Nordnet CSV imports and serves as a preparation step for calculate_aksjegevinst. It implies no alternative usage but does not include explicit when-not-to-use guidance. However, sibling tools are all calculators, so the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses tax rate (22%), asymmetry (no gain/loss for tax-free sales), and that no inflation adjustment is applied. However, it does not describe the return value format or potential errors, which are important for a calculation 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 three sentences, each serving a distinct purpose: what the tool does, conditions for taxability, and tax rate/asymmetry. It is front-loaded with the main action and efficiently includes all critical information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no output schema), the description covers the core tax rules and parameter usage. It lacks specifics about the output structure (e.g., what the function returns) and does not mention any prerequisites or side effects, but this is partially mitigated by the high schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (89%). The description adds meaning by explaining how parameters like dates are used (ownership/use periods) and the tax rules. It provides context beyond the schema, such as which parameters are relevant for which property types (e.g., innflyttingsdato for primærbolig/fritidsbolig).
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 calculates taxable gain or deductible loss from sale of residential property, covering primary, secondary, and holiday homes. It includes specific tax rules and rate, distinguishing it from sibling tools which likely handle other financial calculations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit conditions for tax-free sales (e.g., primary home: owned ≥1 year, lived ≥1 year in last 2 years; holiday home: owned ≥5 years, used ≥5 years in last 8 years) and notes asymmetry. This helps the agent determine when to use this tool for different property types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and thoroughly discloses behavior: FIFO method, per-currency grouping, no adjustments, flat 22% tax, loss deductibility, and output details (per-sale breakdown, totals, remaining lots). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of 4 sentences, front-loaded with the main purpose. Every sentence adds essential information (method, multi-currency, tax rules, output) with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity and lack of output schema, the description provides a good overview of outputs and tax implications. It does not explicitly contrast with siblings, but the tool's purpose is clear enough for an agent to select 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?
Schema description coverage is 100% (baseline 3), but the description adds value: it explains that rapporteringsaar defaults to 2025 and affects FIFO history but not reported totals, and that transaksjoner supports multi-currency. This goes beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it calculates realized crypto gain/loss per currency using FIFO, which is a specific verb+resource. It distinguishes from sibling tools like calculate_aksjegevinst (stocks) and calculate_boliggevinst (housing) by focusing on krypto and FIFO method.
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 usage for crypto transactions but does not explicitly list when not to use or mention alternatives. However, sibling tools are for other asset types, making the context clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses caching behavior (first call slow, subsequent instant), data source (NLOD 2.0-license), and that all current Norwegian laws are available.
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?
Description is concise (4 sentences) and front-loaded with purpose. Examples add value but occupy space; could be slightly more structured but 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?
No output schema, but description implies it returns full text. Could mention return format or limitations (e.g., only current versions), but for a simple param it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description adds extra meaning by explaining the refID format with multiple examples, showing how to construct different paragraph 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?
Description clearly states it retrieves full text of a Norwegian law paragraph from Lovdata. Examples differentiate from sibling calculation 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?
Explicitly describes when to use (retrieve law text) and implies not for calculations. Could benefit from explicit 'when not to use' but context makes it clear.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ValiantEvers/skatt-mcp'

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