Skip to main content
Glama
smlhus1

trafikkmeldinger-mcp

by smlhus1
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

trafikkmeldinger-mcp

MCP-server for norsk veitrafikk — vegarbeid, stengte veier og omkjøringer fra Statens vegvesen, filtrert på ruta di og når du faktisk kjører. Og hvor mange biler som faktisk kjører der, time for time, så «når bør jeg dra» slutter å være gjetting.

Ingen API-nøkkel. Endepunktet er åpent — klon, bygg, kjør.

Hvorfor ikke bare slå opp på vegvesen.no?

Fordi nettsida og appen svarer på «hva er stengt nå». Det er sjelden spørsmålet ditt når du planlegger en tur.

Et konkret eksempel. En kveldstur nordover E6 gjennom Øyer 10. august 2026:

E6 Øyertunnelen i Øyer
  isActiveNow: false          ← klokka er 12, tunnelen er åpen
  stengt 20:00–06:00 mandag–torsdag, 10.–14. august

Kjører du forbi klokka 21, er veien stengt. Men meldingen rapporterer isActiveNow: false midt på dagen, så et filter på «aktiv nå» dropper den — og det er den mest inngripende meldingen på hele turen.

Vegvesenet publiserer heldigvis gjentakelsene som strukturerte data, ikke bare som prosa. Denne serveren tolker dem, slik at du kan spørre om et framtidig tidspunkt.

Related MCP server: trafikverket-mcp

Tre feller denne serveren lukker

1. Fylkesveier lagres med kategoribokstav. Det alle skriver som «fv. 27» eller bare «27» ligger som F27. Et filter på strengen "27" gir null treff — og null treff ser nøyaktig ut som «ingen vegarbeid på strekningen». Det er den farligste feilen denne serveren kan gjøre, så et bart tall utvides til alle fire veiklassene (E27, R27, F27, K27) framfor å gjette.

2. Kommune ligger ikke der du tror. Feltet location.municipalities er tomt på nesten alle meldinger — 2 av 1 293 målt 10. august 2026. Kommunen står i locationDescriptionDetails. Et geografisk filter bygget på det strukturerte-utseende feltet alene mister nesten alt.

3. De to Vegvesen-API-ene skriver veinummer ulikt. Et tellepunkt oppgir veien sin som RV19, EV6, KV2620. En trafikkmelding skriver R19, E6, K2620. Samme etat, to konvensjoner — og filtrerer du tellepunkter med meldingenes skrivemåte, får du null treff. Serveren oversetter til én skrivemåte i roadOfPoint, slik at resten av koden bare ser den ene.

Alle tre er dekket av tester, så en regresjon gir rødt bygg.

Installasjon

Krever Node 20 eller nyere.

git clone https://github.com/smlhus1/trafikkmeldinger-mcp.git
cd trafikkmeldinger-mcp
npm install
npm run build

Legg den til i Claude Code:

claude mcp add trafikkmeldinger -- node /full/sti/til/trafikkmeldinger-mcp/dist/src/index.js

Eller i .mcp.json:

{
  "mcpServers": {
    "trafikkmeldinger": {
      "command": "node",
      "args": ["/full/sti/til/trafikkmeldinger-mcp/dist/src/index.js"]
    }
  }
}

Verktøy

langs_ruta

Trafikkmeldinger for en konkret biltur. Definer strekningen med fylker eller kommuner, og gjerne når du kjører.

{
  "fylker": ["Akershus", "Innlandet"],
  "vei": ["E6", "fv27"],
  "avreise": "2026-08-10T16:00:00+02:00",
  "ankomst": "2026-08-10T22:00:00+02:00"
}

Bruk fylker når du er usikker. Kommuner er mer presist, men utelater du én, forsvinner meldingene der uten et ord — og fylke kombinert med veinummer treffer nesten like presist. Feil skal helle mot å vise for mye, ikke for lite.

Skriv æ, ø og å. Stedsnavn sammenlignes eksakt (store og små bokstaver spiller ingen rolle, men bokstavene gjør det): Sør-Fron treffer, Sor-Fron gir null treff — og null treff ser nøyaktig ut som en rein vei. Samme gjelder fylker.

Svaret skiller det som treffer deg fra det som bare er registrert på strekningen:

{
  "reisevindu": { "avreise": "...", "ankomst": "..." },
  "antallPaaRuta": 19,
  "antallSomTrefferDeg": 13,
  "antallVist": 3,
  "avkortet": "Viser 3 av 13. Øk «maksAntall» eller snevre inn filteret.",
  "merknad": "19 meldinger er registrert på strekningen; 13 av dem gjelder i reisevinduet ditt.",
  "meldinger": [ /* verst først */ ],
  "ikkeIReisevinduet": [ /* med når de faktisk gjelder */ ]
}

Alle tallene oppgis med vilje. Ser du bare ett av dem, kan du ikke skille «rein vei» fra «feil tidsfilter» fra «lista ble kappet».

Svarformat per melding

{
  "sted": "E6 Strandløkken - Strandlykkja, Stange, Innlandet, retning mot Gardermoen",
  "melding": "Vegarbeid, vegen er stengt. Omkjøring er skiltet.",
  "veier": ["E6"],
  "virkning": "large",          // none | small | large | very_large | unknown
  "vegstatus": "RoadClosed",    // RoadOpen | Regulation | RoadClosed
  "gjelderNaa": false,
  "gjelderPaaReisen": true,     // kun når du har oppgitt et reisevindu
  "naarGjelderDen": "...",      // kun når den IKKE gjelder på reisen din
  "antattSlutt": "2026-08-14T06:00:00+02:00",
  "nesteEndring": "RoadClosed fra 2026-08-10T20:00:00+02:00",
  "omkjoeringSkiltet": true,
  "iTunnel": true,
  "kommuner": ["Stange"]
}

Felter utelates når de ikke bærer informasjon. naarGjelderDen følger for eksempel bare med når meldingen ikke treffer reisen din — da er «når gjelder den da» hele poenget; treffer den deg, sier melding allerede det du trenger.

trafikkmeldinger

Generelt oppslag på vei, kommune, fylke og hvor mye det påvirker trafikken. Veinummer kan skrives slik folk snakker: E6, fv27, riksveg 3, eller bare 27.

Uten tidspunkt får du alt som er registrert, også nattarbeid som ikke er aktivt akkurat nå. Oppgi tidspunkt (ISO) for å se kun det som faktisk gjelder da — gjentakelsesreglene tolkes, så en tunnel stengt 20:00–06:00 dukker opp for kl. 21 og ikke for kl. 12.

naar_bor_jeg_kjore

Typisk trafikkmengde time for time på en gitt ukedag — svarer på når du bør dra, ikke på hva som skjer akkurat nå.

{ "vei": ["E6"], "kommune": ["Moss"], "ukedag": "torsdag", "uker": 4 }

Dataene kommer fra tellepunkter: sløyfer og radar i asfalten som teller hver eneste bil som passerer. Det er en måling, ikke et estimat — men den vet bare noe om selve punktet, ingenting om veien mellom punktene.

{
  "ukedag": "torsdag",
  "antallPunkterFunnet": 1,
  "punkter": [{
    "punkt": "Storebaug",
    "vei": "E6",
    "sted": "Moss, Østfold",
    "typiskPerTime": { "06": 1398, "07": 1947, /* ... */ "15": 4709, /* ... */ "22": 1132 },
    "toppTime": { "time": 15, "biler": 4709 },
    "roligsteDagtid": { "time": 6, "biler": 1398 },
    "ukerBakTallene": 4
  }]
}

Tre valg verdt å vite om:

  • Median, ikke gjennomsnitt. Én stengt vei, én helligdag eller én festival flytter et gjennomsnitt med hundrevis av biler, og da beskriver tallet en uke som aldri skjer.

  • Timer med under 90 % dekning forkastes, ikke skaleres. En halvdød sensor rapporterer omtrent halve trafikken — det ser ut som en stille vei, og det er den farligste løgnen denne serveren kan fortelle.

  • ukerBakTallene står i svaret. En median av to uker er en median av to tall. Det skal du få vite, ikke gjette.

doctor

Kaller begge de ekte endepunktene og rapporterer svartid, antall meldinger, hvor mange som har gjentakelsesregler, og hvor mange tellepunkter som svarer. Bruk den når noe oppfører seg rart.

Utvikling

npm test      # enhetstester mot fast fikstur — ingen nettverk
npm run smoke # mot ekte API + serveren som prosess (krever nett)
npm run bench # måler hva rutefilteret koster på en lang tur (krever nett)

Enhetstestene bruker en frosset fikstur slik at et rødt bygg alltid betyr «koden er feil», ikke «wifi-en er nede». Røyktesten snakker MCP over stdio til en spawnet server — en test som bare importerer moduler finner aldri ut om kommandoen i det hele tatt starter.

Om datakildene

Begge er fra Statens vegvesen, og ingen av dem krever nøkkel eller registrering.

Trafikkmeldinger: traffic-info.atlas.vegvesen.no/traffic-information/messages — det samme endepunktet som Vegvesenets egen trafikk-app bruker. Krever headeren X-System-ID.

Tellepunkter: trafikkdata-api.atlas.vegvesen.no — et GraphQL-API over ~5 900 punkter som teller kjøretøy (10 000+ hvis du tar med sykkeltellere og punkter som er ute av drift; serveren filtrerer bort begge).

Fire ting som er lette å snuble i om du kaller endepunktene selv:

  • Accept: application/json gir 406. Innholdstypen er application/vnd.svv.v1+geo+json, og innholdsforhandlingen er streng.

  • Uten X-System-ID får du 400 med en feilmelding som ikke nevner headeren.

  • GraphQL-sider er maks 100. first: 101 feiler med «An unknown error occurred» — det er et tak, ikke en anbefaling, så paginering er obligatorisk og ikke en optimalisering.

  • Datex-feeden er ikke lenger åpen. datex-server-get-v3-1.atlas.vegvesen.no svarer 401 og krever registrering.

Bruk av dataene er underlagt Vegvesenets vilkår: https://www.vegvesen.no/om-oss/om-organisasjonen/apne-data/

Dette prosjektet er ikke tilknyttet eller støttet av Statens vegvesen.

Lisens

MIT — se LICENSE.

Available Tools

3 tools
doctorSvarer Vegvesenet akkurat nå?A

Kaller det ekte endepunktet og rapporterer om det svarer, hvor lang tid det tok og hvor mange meldinger som ble hentet. Bruk denne når et av de andre verktøyene oppfører seg rart, eller for å se om API-et har endret kontrakt.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.7/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses that it makes a real endpoint call, reports whether it responds, latency, and message count. It does not mention side effects or permissions, but for a health-check tool this is largely 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 concise sentences front-load the core function and then provide usage guidance. Every word adds value, no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter diagnostic tool, the description covers what it does, why to use it, and what it returns (response status, time, message count). No output schema is needed because the description already summarizes the output. It is complete for its low complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, and the schema is empty, so there is nothing missing.

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 (calls the real endpoint) and resource (the actual API), and reports response time and message count. It distinguishes itself from siblings by framing itself as a diagnostic tool for when other tools misbehave.

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

Usage Guidelines5/5

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

Explicitly states when to use this tool: when other tools behave strangely or to check for API contract changes. This gives clear usage context and references the sibling tools as the reason for using the doctor tool.

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

langs_rutaHva møter jeg på denne bilturen?A

Trafikkmeldinger for en konkret biltur, filtrert på både strekning og når du kjører. Definer strekningen med «fylker» ELLER «kommuner» (minst én av dem), og helst «vei». Er du usikker på hvilke kommuner ruta går gjennom, bruk fylker — en glemt kommune fjerner meldingene der uten å si fra, mens fylke + vei treffer nesten like presist. Oppgi «avreise» og «ankomst» for å skille det som faktisk treffer deg fra alt som er registrert på strekningen — nattestengte tunneler og arbeid som bare gjelder hverdager blir da vurdert mot reisetidspunktet ditt, ikke mot «akkurat nå». Svaret er sortert med det mest inngripende først.

ParametersJSON Schema
NameRequiredDescriptionDefault
veiNoBegrens til disse veiene, f.eks. ["E6", "fv27"]. Utelat for alle veier på strekningen.
fylkerNoFylkene ruta går gjennom, f.eks. ["Østfold", "Akershus", "Oslo", "Innlandet"]. Tryggest når du ikke kjenner kommunene.
ankomstNoISO-tidspunkt for når du er framme. Standard: 6 timer etter avreise.
avreiseNoISO-tidspunkt for når du starter. Standard: nå.
kommunerNoKommunene ruta går gjennom, f.eks. ["Eidsvoll", "Stange", "Ringebu"]. Mer presist enn fylker, men utelater du én, mister du meldingene der.
maksAntallNoStandard 50.
minsteVirkningNoUtelat bagateller. Standard: ta med alt.

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It discloses important behavioral traits: a forgotten municipality silently removes messages ('en glemt kommune fjerner meldingene der uten å si fra'), time-based evaluation against travel time rather than 'right now', and sorting with the most disruptive first. These go beyond the schema and help set expectations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a clear purpose sentence, followed by practical instructions and caveats. Every sentence earns its place, and bold text highlights the most critical advice. Despite being a bit long, it is dense with useful information and not redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's core functionality, key parameter choices, and behavioral caveats. The absence of an output schema is partially mitigated by mentioning sorting, but it does not describe the return format or error handling. Given the tool's complexity (7 params), it is reasonably complete, though a bit more detail on output would elevate it.

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?

Although schema coverage is 100%, the description adds significant meaning beyond the field descriptions. It explains the trade-off between 'fylker' and 'kommuner', recommends including 'vei', and clarifies how 'avreise'/'ankomst' affect filtering. This helps the agent choose appropriate values, which is more than the schema alone 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's purpose: 'Trafikkmeldinger for en konkret biltur' (traffic messages for a specific car trip). It specifies filtering by route and time, and distinguishes itself from the sibling 'trafikkmeldinger' by being route- and time-specific. The sorting behavior is also mentioned.

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?

Provides clear usage context: define route with counties or municipalities, prefer roads, specify departure/arrival for time-filtering. Gives practical guidance like 'Er du usikker på hvilke kommuner ruta går gjennom, bruk fylker'. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of a 5.

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

trafikkmeldingerTrafikkmeldinger for et område eller en veiA

Henter vegarbeid, stengte veier, ulykker og andre trafikkmeldinger fra Statens vegvesen, med filter på vei, kommune, fylke og hvor mye det påvirker trafikken. Veinummer kan skrives slik folk snakker: «E6», «fv27», «riksveg 3» eller bare «27». Uten «tidspunkt» får du alt som er registrert, også nattarbeid som ikke er aktivt akkurat nå — oppgi «tidspunkt» for å se kun det som faktisk gjelder da. Skal du planlegge en biltur, bruk heller verktøyet «langs_ruta».

ParametersJSON Schema
NameRequiredDescriptionDefault
veiNoVeinummer, f.eks. ["E6", "fv27"]. Bare tall matcher alle veiklasser.
fylkeNoFylkesnavn, f.eks. ["Innlandet"].
kommuneNoKommunenavn, f.eks. ["Ringebu", "Øyer"].
tidspunktNoISO-tidspunkt. Filtrerer til meldinger som faktisk gjelder da.
maksAntallNoStandard 40.
minsteVirkningNoUtelat alt som påvirker trafikken mindre enn dette. «large» = merkbar forsinkelse.

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well by disclosing the key behavioral nuance around 'tidspunkt' – that without it you get all registered messages, not just currently active ones. It also explains flexible road number formatting ('E6', 'fv27', 'riksveg 3', '27'). It doesn't mention return format or pagination, but the described behavior is sufficient for safe usage.

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 adding critical information: main purpose, parameter tips, and an explicit alternative. No fluff or repetition; every sentence earns its place. It is front-loaded with the core function and structured for quick scanning.

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 query tool with 6 optional parameters and no output schema, the description covers the main use case, filter dimensions, a key behavioral nuance, and an alternative tool. It doesn't describe return fields or sorting, but the provided information is enough for correct invocation in most scenarios. Slightly incomplete regarding expected output, but strong overall.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds value by explaining road number syntax in plain language ('Veinummer kan skrives slik folk snakker') and clarifying the meaning of the 'tidspunkt' parameter (active vs. all registered). This goes beyond the schema's terse descriptions, 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 opens with a specific verb 'Henter' and the resource 'vegarbeid, stengte veier, ulykker og andre trafikkmeldinger fra Statens vegvesen', making the tool's function unmistakable. It also distinguishes itself from the sibling 'langs_ruta' by explicitly directing trip planners to that alternative, ensuring clear differentiation.

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

Usage Guidelines5/5

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

The description provides explicit usage context: when to use the tool (querying traffic messages for an area/road), and when not to (use 'langs_ruta' for trip planning). It also gives parameter-level advice, such as the effect of omitting 'tidspunkt' (all registered messages including inactive night work) versus providing it (only relevant messages). This is clear, actionable guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.1.0
    • First observeddoctor
    • First observedlangs_ruta
    • First observedtrafikkmeldinger
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clear, distinct purpose: doctor checks API health, trafikkmeldinger performs general queries, and langs_ruta provides route-specific, time-aware queries. The descriptions explicitly cross-reference when to use langs_ruta, eliminating ambiguity.

Naming Consistency2/5

Tool names mix languages (English 'doctor' vs Norwegian 'trafikkmeldinger' and 'langs_ruta') and conventions (underscore in 'langs_ruta' vs no underscore elsewhere). No consistent verb_noun pattern is present.

Tool Count4/5

Three tools is a reasonable, focused set for a traffic information server, covering general search, route planning, and health monitoring. It is slightly minimal but each tool earns its place.

Completeness4/5

The domain is read-only traffic messages, and the two query tools cover both general filtering and route-specific timing. No major gaps are apparent, though a tool for fetching a single message by ID could be a minor addition.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • aria-mcp-trafik-dk

    kimhjort
    A
    license
    A
    quality
    C
    maintenance
    Provides access to real-time Danish road traffic events, roadworks, and queues via public data from Vejdirektoratet, enabling AI assistants to check road conditions without any API keys.
    3
    MIT

  • trafikverket-mcp

    hniska
    F
    license
    A
    quality
    D
    maintenance
    Provides real-time access to Swedish road weather, traffic cameras, road conditions, and traffic flow data from Trafikverket (Swedish Transport Administration). Enables users to query weather stations, cameras, traffic situations, and flow data through natural language.
    10
    -

  • mcp-entur

    pipeworx-io
    A
    license
    Not graded
    quality
    B
    maintenance
    Provides access to Norway's nationwide public transport data (all modes) via the Entur API, enabling queries about routes, stops, and departures through natural language.
    3 npm
    MIT