skatt-mcp is a local MCP server that enables Claude to answer Norwegian tax questions with actual calculations (not just general explanations) for the 2025 tax year. It covers income, wealth, stocks, funds, real estate, and crypto.
Look up tax rates: Retrieve all Norwegian tax rates, brackets, deductions, and discounts for a given income year.
Calculate income tax: Compute ordinary income tax, bracket tax (trinnskatt), and national insurance contributions for wages, pension, or business income — with optional deductions for mortgage interest, commuting, childcare, union dues, and BSU savings.
Calculate wealth tax: Apply correct valuation discounts per asset class (primary home, secondary home, cabin, stocks/funds, ASK, bank deposits, crypto) with proportional debt allocation.
Calculate stock gains/losses: FIFO-based realized gains/losses per ticker with the ×1.72 adjustment factor and 22% tax, including per-sale breakdown and remaining lot summary.
Calculate shareholder exemption deduction (skjermingsfradrag): Compute the risk-free return deduction on dividends for personally held shares, with carry-forward of unused deductions.
Calculate equity savings account (ASK) tax: Model tax consequences for no-activity, partial withdrawal, and full account closure scenarios.
Calculate mutual fund tax: FIFO per ISIN, splitting equity/bond portions and applying the ×1.72 adjustment only on the equity portion, with shareholder exemption handling.
Calculate real estate gain/loss: Taxable gain or deductible loss from selling primary residences (tax-free conditions), secondary homes, or holiday properties.
Calculate crypto gains/losses: FIFO per currency, taxed at a flat 22% with no adjustment or exemption deduction.
Import Nordnet transactions: Parse a Nordnet CSV export into a canonical transaction format with per-security classification hints.
Full Nordnet tax settlement: Generate a complete tax settlement from a Nordnet export, automatically routing stocks and funds through the appropriate calculation engine.
Look up Norwegian law paragraphs: Fetch and cite full paragraph text from Norwegian tax law (e.g., skatteloven) via Lovdata, with local caching.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@skatt-mcp hva blir formuesskatten min for 2025?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
En lokal MCP-server som lar Claude svare på norske skattespørsmål med faktiske beregninger i stedet for generelle forklaringer — f.eks. «hvor mye skatt skylder jeg på denne aksjegevinsten?» eller «hva blir formuesskatten min for 2025?».
Tolv verktøy dekker inntekt, formue, aksjer, aksjesparekonto (ASK), verdipapirfond, bolig, krypto, Lovdata-paragrafoppslag, Nordnet-import og et samlet skatteoppgjør.
Dette er ikke skatterådgivning. Verktøyet er et personlig hjelpemiddel for å estimere
norsk skatt, og kan inneholde feil, forenklinger eller utdaterte satser. Alle tall må
verifiseres mot Skatteetaten og din egen skattemelding før
de brukes til noe. Satsene gjelder inntektsåret 2025 (se src/data/satser/2025.json for
kilder og hentedato). Bruk skjer på eget ansvar.
Related MCP server: plaid-mcp-server
Skatteberegningene kjører 100 % lokalt over stdio. Tallene og transaksjonene dine sendes aldri over nettverket og forlater aldri maskinen din — det er ingen telemetri, ingen innlogging og ingen tredjepartstjeneste involvert.
Den eneste nettverkstrafikken i hele serveren er at lookup_paragraf kan laste ned
offentlig lovtekst fra Lovdatas åpne bulk-arkiv og cache den
lokalt i data/lovdata-cache/ (gitignored). Ingen personlige data inngår i det oppslaget —
det henter bare paragraftekst fra skatteloven.
Ekte Nordnet-eksporter holdes utenfor repoet: *.csv er gitignored (med unntak for de
syntetiske filene i test-fixtures/), slik at faktiske finansdata aldri kan bli committet ved
et uhell.
git clone https://github.com/ValiantEvers/skatt-mcp.git
cd skatt-mcp
npm install
npm run build # kompilerer TypeScript → dist/Bekreft at serveren svarer (lister opp alle verktøyene):
echo '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}' | node dist/server.jsPå Windows kjør denne i
cmd.exe, ikke PowerShell — PowerShell tolker{}som blokksyntaks i en echo-pipe.
Åpne config-fila:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Legg til serveren med en absolutt sti til dist/server.js (config-fila ekspanderer ikke
~ eller miljøvariabler):
{
"mcpServers": {
"skatt-mcp": {
"command": "node",
"args": ["/Users/<DITT-BRUKERNAVN>/projects/skatt-mcp/dist/server.js"]
}
}
}På Windows oppgir du den tilsvarende absolutte stien til dist\server.js under din egen
brukermappe. Tips: kjør pwd (macOS/Linux) eller cd (Windows) i prosjektmappa for å få
den fulle stien.
Start Claude Desktop på nytt. Du skal nå se verktøy-ikonet (🔨) og skatt-mcp-verktøyene i
listen.
Kjør fra prosjektroten:
# macOS / Linux
claude mcp add skatt-mcp -- node "$(pwd)/dist/server.js":: Windows (cmd.exe)
claude mcp add skatt-mcp -- node %CD%\dist\server.jsEtter endringer i
src/: kjørnpm run buildpå nytt, og start Claude Desktop på nytt for at endringene plukkes opp.
Verktøy | Hva det gjør |
| Alminnelig inntektsskatt + trinnskatt + trygdeavgift for et gitt år |
| Slår opp gjeldende skattesatser (trinn, fradrag, rabatter) for året |
| Formuesskatt med verdsettingsrabatter per formuesklasse |
| Gevinst/tap på aksjer med FIFO og oppjustering ×1,72 |
| Skjermingsfradrag på aksjeutbytte/-gevinst |
| Skatt på aksjesparekonto (ASK), inkl. skjerming |
| Verdipapirfond med FIFO per ISIN og aksjedel/rentedel-splitt |
| Gevinst ved salg av primær-, sekundær- eller fritidsbolig |
| Gevinst/tap på kryptovaluta med FIFO |
| Parser en Nordnet CSV-eksport → kanonisk transaksjons-array |
| Fullt skatteoppgjør fra en Nordnet-eksport (auto-ruter aksjer/fond per ISIN) |
| Henter og siterer en paragraf fra skatteloven (via Lovdata) |
Alle kalkulatorene avslutter svaret med en Relevante paragrafer:-blokk slik at tallene kan
spores tilbake til lovhjemmel.
Du: Jeg solgte 100 Equinor-aksjer i 2025 som jeg kjøpte i 2021 for 200 kr stykket. Salgskursen var 280 kr. Hva skylder jeg?
Claude kaller calculate_aksjegevinst med transaksjonene dine og svarer med faktiske tall,
omtrent slik (illustrative tall):
Equinor — rapporteringsår 2025
Salg 2025: 100 @ 280 → salgssum 28 000, kostbase 20 000, gevinst 8 000
Oppjustert (×1,72): 13 760
Implisert skatt (22 %): 3 027
Relevante paragrafer:
lov/1999-03-26-14/§10-31 (Skatteplikt for gevinst og fradragsrett for tap)
...Har du hele Nordnet-eksporten? Da kan Claude bruke beregn_skatteoppgjoer_nordnet, som
parser eksporten, grupperer per ISIN og automatisk ruter rene aksjer til aksje-FIFO og
verdipapirfond til fond-motoren — og returnerer ett samlet skatteoppgjør.
TypeScript ESM (NodeNext), stdio-transport via @modelcontextprotocol/sdk.
Delt FIFO-motor — src/lib/fifo.ts er en domene-nøytral FIFO-implementasjon som
gjenbrukes av aksjer, verdipapirfond og krypto. Salgsresultatene kan inkludere per-lot
«delsalg»-breakdown for korrekt snittsaksjeandel i fond.
Zod-validering — alle verktøyenes input valideres med Zod (ingen Pydantic; dette er et rent TypeScript-prosjekt).
Satser fra data, ikke hardkodet — alle skattesatser ligger i
src/data/satser/2025.json med en _meta-blokk som dokumenterer kilde og hentedato.
Tre-lags Lovdata-cache — lookup_paragraf laster Lovdatas åpne tar.bz2-arkiv, pakker
ut lov-XML og cacher ferdig-parsede paragrafer som JSON, alt under data/lovdata-cache/.
Fond-klassifisering — src/data/fond-klassifisering.json mapper ISIN → fondstype
(aksjefond / rentefond / kombinasjonsfond) og valgfri aksjeandel_per_år. Repoet
leveres med en liten seed av alminnelige fond. Legg til dine egne ved å føye til en
oppføring med ISIN-en som nøkkel:
"NO0010xxxxxx": {
"navn": "Mitt fond",
"type": "aksjefond"
}For kombinasjonsfond oppgir du "aksjeandel_per_år": { "2024": 0.55, "2025": 0.57 }.
Se CLAUDE.md for kodekonvensjoner og STATUS.md for full
arkitekturhistorikk, beslutninger og edge cases.
npm test # bygger og kjører hele den committede testpakken
npm run typecheck # ren type-sjekk uten å skrive filerTestpakken kjører parser-enhetstester, en MD5-frosset identitetstest for fond-motoren, en
grensetest for aksjeandel-klassifiseringen (§ 10-20 (2), 27 sjekker), det samlede
skatteoppgjøret og en ende-til-ende-test mot syntetiske fixturer (test-fixtures/).
Ingen ekte data kreves.
DNB-parser — støtte for et andre meglerformat. Mønsteret er etablert via Nordnet-parseren, så dette bør bli vesentlig mindre arbeid.
Validering mot ekte 2025-skattemelding — sammenlign verktøyets tall mot et ferdigstilt skattemeldingsutkast fra Skatteetaten for å avdekke eventuelle hull.
MIT © Valiant Evers
Tar en Nordnet transaksjons-eksport (filsti ELLER innlimt rå CSV-tekst), parser den, grupperer per ISIN og ruter automatisk: rene aksjer kjøres gjennom aksje-FIFO (oppjustering ×1,72), verdipapirfond gjennom fond-motoren (per-lot snittsaksjeandel, skjerming, oppjustering kun på aksjedel). Returnerer ett samlet skatteoppgjør for realiserte gevinster/tap i rapporteringsåret. ISIN-er som mangler i fond-klassifisering.json rapporteres som handlingsbare advarsler. Utbytte beregnes IKKE her — bruk calculate_skjermingsfradrag for det.
| Name | Required | Description | Default |
|---|---|---|---|
| csv_filsti | No | Absolutt sti til Nordnet CSV-eksport (UTF-16 LE TSV) | |
| csv_tekst | No | Rå CSV-tekst limt inn direkte (alternativ til csv_filsti) | |
| rapporteringsaar | No | ||
| inngangs_carry_per_isin | No | Valgfri skjerming-carry inn til rapporteringsåret per fond-ISIN |
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.
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.
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.
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.
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.
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.
Beregner skatt for verdipapirfond med transaksjons-array som input. FIFO per ISIN. Bruker fond-klassifisering.json for type og aksjeandel. Oppjustering ×1,72 kun på aksjedel av gevinst (per § 10-20 (6)). Skjerming-grunnlag = lot.kostbase × aksjeandel_kjøpsår (per § 10-20 (4)). Inngangs-carry per ISIN aksepteres for kontinuitet over år.
| Name | Required | Description | Default |
|---|---|---|---|
| transaksjoner | Yes | ||
| inngangs_carry_per_isin | No | Valgfri carry inn til rapporteringsåret per ISIN (default: ingen) | |
| rapporteringsaar | No |
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.
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.
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.
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.
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.
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.
Beregner realisert aksjegevinst og -tap per ticker med FIFO-metoden. Multi-ticker støttes — beregnes separat per ticker. Inkluderer aksjeoppjustering og implisert skatt (22 %). Viser per-salg-breakdown, aggregerte totaler og gjenstående lots.
| Name | Required | Description | Default |
|---|---|---|---|
| transaksjoner | Yes | Liste over alle transaksjoner. Multi-ticker støttes. | |
| rapporteringsaar | No | Rapporteringsår. Salg utenfor dette året påvirker FIFO-historikk, men ikke rapporterte totaler. |
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.
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.
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.
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.
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.
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.
Beregner skattekonsekvenser for en aksjesparekonto (ASK) for ett rapporteringsår. Håndterer tre scenarier: ingen aktivitet (skjerming akkumuleres, skatt utsatt), uttak i året (skatt på gevinst over skjerming), og avslutning av kontoen. Viser skjermingsberegning, skatteoppgjør og ny state for neste år.
| Name | Required | Description | Default |
|---|---|---|---|
| innskudd_start_aar | Yes | Total innskuddssaldo ved 1.1 i rapporteringsåret (det som kan tas ut skattefritt ved start av året) | |
| innskudd_i_aaret | No | Sum nye innskudd lagt til ASK i løpet av året | |
| uttak_i_aaret | No | Sum uttak fra ASK i året. Utbytte som blir stående på kontoen regnes ikke som uttak. | |
| laveste_innskuddssaldo | No | Laveste innskuddssaldo i året (fra bankens årsoppgave). Approksimeres som max(0, innskudd_start_aar − uttak_i_aaret) hvis utelatt. | |
| akkumulert_ubrukt_skjerming | No | Akkumulert ubrukt skjerming overført fra tidligere år | |
| markedsverdi_31_12 | Yes | Markedsverdi av aksjer/fond på ASK per 31.12 | |
| avslutter_kontoen | No | Hvis true: kontoen tømmes — all urealisert gevinst eller tap realiseres i rapporteringsåret | |
| rapporteringsaar | No |
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.
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.
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.
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.
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.
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.
Beregner skattepliktig gevinst eller fradragsberettiget tap ved salg av bolig. Håndterer primærbolig (skattefri ved ≥ 1 år eiertid og ≥ 1 år botid siste 2 år), sekundærbolig (alltid skattepliktig), og fritidsbolig (skattefri ved ≥ 5 år eiertid og ≥ 5 år brukstid siste 8 år). Skattesats 22 % alminnelig inntekt — ingen oppjustering for bolig. Asymmetri: skattefritt salg gir hverken gevinst-skatt eller tap-fradrag.
| Name | Required | Description | Default |
|---|---|---|---|
| boligtype | Yes | Type bolig som selges | |
| kjoepspris | Yes | Inngangsverdi inkl. dokumentavgift og kjøpsomkostninger | |
| salgspris | Yes | Salgssum etter meglerprovisjon og salgsomkostninger | |
| paakostninger | No | Dokumenterte påkostninger som øker boligens verdi | |
| kjoepsdato | Yes | Dato boligen ble kjøpt (YYYY-MM-DD) | |
| salgsdato | Yes | Dato boligen ble solgt (YYYY-MM-DD) | |
| innflyttingsdato | No | Dato eier flyttet inn. Kun relevant for primærbolig og fritidsbolig. Settes til kjøpsdato hvis utelatt. | |
| fraflyttingsdato | No | Dato eier flyttet ut. Kun relevant for primærbolig og fritidsbolig. Settes til salgsdato hvis utelatt. | |
| rapporteringsaar | No |
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.
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.
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.
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.
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.
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.
Beregner formuesskatt med korrekt skattemessig verdsetting per formuesposttype og proporsjonal gjeldsfordeling. Viser per-post-breakdown og alle mellomregninger.
| Name | Required | Description | Default |
|---|---|---|---|
| formuesposter | Yes | Liste over alle formuesposter med markedsverdi | |
| total_gjeld | No | Sum av all gjeld | |
| ektefeller | No | Hvis true, dobles bunnfradraget | |
| aar | No |
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.
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.
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.
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.
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.
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.
Beregner alminnelig inntektsskatt, trinnskatt og trygdeavgift. Støtter lønn, pensjon og næringsinntekt. Inkluderer valgfrie fradrag: gjeldsrenter, reisefradrag, foreldrefradrag, fagforeningskontingent og BSU. Viser alle mellomregninger.
| Name | Required | Description | Default |
|---|---|---|---|
| bruttoinntekt | Yes | Brutto årsinntekt i NOK | |
| inntektstype | No | lønn | |
| aar | No | ||
| gjeldsrenter | No | Sum betalte gjeldsrenter | |
| reisefradrag_km | No | Avstand til jobb én vei i km | |
| reisefradrag_dager | No | Antall arbeidsdager (default 230) | |
| foreldrefradrag_antall_barn | No | Antall barn under 12 år | |
| foreldrefradrag_dokumenterte_kostnader | No | Dokumenterte pass- og omsorgsutgifter | |
| fagforeningskontingent | No | ||
| andre_fradrag | No | Catch-all for øvrige fradrag i alminnelig inntekt | |
| bsu_innskudd | No | Innskudd på BSU dette året (maks 27 500) |
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.
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.
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.
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.
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.
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.
Beregner realisert kryptogevinst og -tap per valuta med FIFO-metoden. Multi-valuta støttes — beregnes separat per valuta. FIFO-grupperingen er per valuta uavhengig av kilde-børs/konto. Ingen oppjustering, ingen skjermingsfradrag — krypto skattlegges flat 22 % på netto. Tap er fradragsberettiget. Viser per-salg-breakdown, aggregerte totaler og gjenstående lots.
| Name | Required | Description | Default |
|---|---|---|---|
| transaksjoner | Yes | Liste over alle transaksjoner. Multi-valuta støttes. | |
| rapporteringsaar | No | Rapporteringsår. Salg utenfor dette året påvirker FIFO-historikk, men ikke rapporterte totaler. |
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.
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.
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.
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.
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.
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.
Beregner skjermingsfradrag for utbytte på personlig-eide aksjer. Multi-ticker støttes. Viser årets skjerming, brukt/ubrukt mot utbytte, ny akkumulert ubrukt (carry-forward) og skattepliktig utbytte per ticker.
| Name | Required | Description | Default |
|---|---|---|---|
| innehav | Yes | Aksjebeholdning per 31.12. Tomt array = ingen skjerming. | |
| utbytter | No | Utbytter mottatt i rapporteringsåret. | |
| rapporteringsaar | No |
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.
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.
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.
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.
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.
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.
Leser en Nordnet transaksjons-eksport (UTF-16 LE TSV) og returnerer kanonisk transaksjons-array klar for calculate_aksjegevinst, sammen med klassifiseringshint per verdipapir og rapport over hoppet-over rader. Bare KJØPT/SALG/INNLEGG OVERFØRING blir oversatt til transaksjoner — alle andre rad-typer havner i hoppet_over med begrunnelse.
| Name | Required | Description | Default |
|---|---|---|---|
| filsti | Yes | Absolutt sti til Nordnet CSV-eksport |
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.
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.
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.
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.
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.
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.
Henter full tekst for en norsk lovparagraf fra Lovdata sitt offentlige datasett (NLOD 2.0-lisens). Cacher lokalt — første kall laster ned skatteloven (~5 sek), påfølgende kall er øyeblikkelige. Alle gjeldende norske lover er tilgjengelige. Eksempler: 'lov/1999-03-26-14/§5-1' (inntektsregel), 'lov/1999-03-26-14/§9-3' (boligsalg skattefritak), 'lov/1999-03-26-14/§10-12' (skjermingsfradrag), 'lov/1999-03-26-14/§10-31' (aksjegevinst).
| Name | Required | Description | Default |
|---|---|---|---|
| refID | Yes | Lovdata referanse-ID på formatet 'lov/{lov-id}/§{paragraf}'. Skatteloven er lov/1999-03-26-14. Eksempel: 'lov/1999-03-26-14/§9-3' |
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.
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.
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.
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.
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.
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.
Returnerer alle skattesatser og grenser for et gitt inntektsår. Nyttig for å inspisere hvilke satser som brukes i beregningene.
| Name | Required | Description | Default |
|---|---|---|---|
| aar | Yes | Inntektsår (kun 2025 støttet ennå) |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.0.1beregn_skatteoppgjoer_nordnetcalculate_aksjefondcalculate_aksjegevinstcalculate_askcalculate_boliggevinstcalculate_formuesskattcalculate_inntektsskattcalculate_kryptogevinstcalculate_skjermingsfradragimport_transaksjoner_nordnetlookup_paragraflookup_satserScored across 12 tools
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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
MCP server giving Claude AI access to 22+ NYC public-record databases for real estate due diligence
Cloudflare Workers MCP server: ai-budget-planner
An MCP server that gives your AI access to the source code and docs of all public github repos
