This server provides AI assistants with access to Swedish public government data through the Apiverket API, covering 139 endpoints across 16 categories.
Discover endpoints (govdata_discover): Search and browse available API endpoints by keyword or category without making API calls — useful for finding the right endpoint before querying.
Query government data (govdata_query): Call any discovered endpoint with path_params and query_params to retrieve structured JSON data across domains like weather, transport, jobs, company info, and more.
Inspect account & usage (govdata_account): Check API key mode (sandbox/live), tier, daily usage, company-search/lookup quotas, and upgrade-relevant limits.
Error handling & pagination: Receive structured recovery guidance on failures (e.g., 429 rate limit errors) and truncated large responses with pagination instructions.
Automated workflow guidance: Predefined discovery workflows support data families including transport, weather, geography, municipalities, jobs, government, culture, education, tourism, environment, and company data.
Data domains include:
🌦️ Weather & Climate: forecasts, warnings, air quality, observations
🚆 Transport: train departures, transit stops, transport statistics
🏛️ Government & Parliament: documents, members, committees, SFS/SOU legislation
👮 Police & Safety: events and stations by location
💼 Jobs: search, taxonomy, concepts, autocomplete
🏙️ Geography & Municipalities: population, KPIs, geometry, county/municipality codes
🏢 Company Data: search by name, look up by organisation number
⚡ Economy & Finance: exchange rates, electricity prices
🌱 Environment: EV charger locations, environmental data
🎓 Education, Culture, Tourism, and more
An MCP (Model Context Protocol) server that gives AI assistants access to Swedish public data through the Apiverket API. It works with Claude Code, Claude Desktop, Cursor, VS Code, Gemini CLI-style MCP clients, and other MCP-compatible tools.
Tool | Purpose |
| Search and browse supported Apiverket endpoints before choosing a path |
| Call a discovered endpoint and return structured JSON or recovery guidance |
| Inspect sanitized key mode, tier, daily usage, company-search/company-lookup quota, and upgrade-relevant limits |
Agents should call govdata_discover before govdata_query instead of guessing /v1 paths. After a 429 or when a user asks about limits, agents should call govdata_account.
Related MCP server: Kolada MCP Server
Discover: call govdata_discover with the user's topic, not a guessed path.
Check context: call govdata_account for quota, tier, and production-readiness questions.
Query: call govdata_query only with a supported endpoint returned by discovery.
Recover: if a request fails, use the structured recovery guidance before retrying.
Discovery includes family workflows for transport, weather, geography, municipalities, jobs, government, culture, education, tourism, environment, and company data. These workflows explain search/list/detail patterns, required codes, coordinates, date formats, pagination, and common recovery steps.
{
"mcpServers": {
"apiverket": {
"command": "npx",
"args": ["-y", "apiverket-mcp-server"],
"env": {
"GOVDATA_API_URL": "https://apiverket.se",
"GOVDATA_API_KEY": "sk_test_demo"
}
}
}
}{
"servers": {
"apiverket": {
"command": "npx",
"args": ["-y", "apiverket-mcp-server"],
"env": {
"GOVDATA_API_URL": "https://apiverket.se",
"GOVDATA_API_KEY": "sk_test_demo"
}
}
}
}{
"mcpServers": {
"apiverket": {
"command": "npx",
"args": ["-y", "apiverket-mcp-server"],
"env": {
"GOVDATA_API_URL": "https://apiverket.se",
"GOVDATA_API_KEY": "sk_test_demo"
}
}
}
}Variable | Default | Description |
|
| Apiverket API base URL |
|
| Sandbox key by default. Use a |
sk_test_demo is for setup and safe sandbox responses. It is useful for checking that your MCP client is wired correctly, but production workflows should use a live key. Free live keys are good for exploration; upgrade when daily API or company-search limits block a real workflow.
Company search and company lookup have different jobs:
Use govdata_discover(query: "company") to find the supported company endpoints.
Use /v1/companies/search when the user only has a company name or uncertain organisation number.
Cache the returned org_number.
Use /v1/companies/{orgNumber} for repeated enrichment and automation.
If company search returns 429, stop retrying until reset_at; use lookup when org numbers are already known.
Company search and live company lookup have separate daily quota context by tier. govdata_account shows the configured key tier, remaining company-search quota, remaining company-lookup quota, reset time, and available upgrade tiers. Apiverket does not expose company board, officer, owner, or UBO subresource paths through the company API.
Family | Good first query | Agent workflow |
Transport |
| Use station codes for |
Weather |
| Use city endpoints for simple weather, warnings for national alerts, and station/lat/lon flows for air quality or observations. |
Geography & municipalities |
| Find official municipality/county/place codes first; search KPIs before municipality KPI detail calls; request geometry only when needed. |
Jobs |
| Use |
Government & safety |
| Choose calendar, documents, members, committees, SFS, SOU, police events, or police stations based on the question. |
Culture, education & environment |
| Search first, then reuse returned IDs/codes for detail endpoints; ensure |
# Discover endpoints
govdata_discover(query: "electricity prices")
govdata_discover(category: "Weather & Climate")
govdata_discover(query: "train departures")
govdata_discover(query: "municipality KPI")
govdata_discover(query: "jobs taxonomy")
# Query data after discovery
govdata_query(endpoint: "/v1/weather/{city}", path_params: {city: "stockholm"})
govdata_query(endpoint: "/v1/transport/trains/{station}", path_params: {station: "Cst"})
govdata_query(endpoint: "/v1/jobs/search", query_params: {q: "developer", limit: 5})
govdata_query(endpoint: "/v1/taxonomy/types")
govdata_query(endpoint: "/v1/companies/search", query_params: {q: "volvo", limit: 10})
govdata_query(endpoint: "/v1/companies/{orgNumber}", path_params: {orgNumber: "5560125790"})
# Inspect tier and quota state
govdata_account()git clone https://github.com/vinvuk/apiverket-mcp.git
cd apiverket-mcp
npm install
npm run buildThe MCP server runs locally over stdio.
govdata_discover searches the built-in endpoint catalog without an API call.
govdata_query calls Apiverket with the configured API key.
Structured API errors are turned into recovery guidance for agents.
Large responses are truncated with pagination guidance.
Node.js >= 18
An Apiverket API key, or sk_test_demo for sandbox setup
MIT
Search and browse available Swedish government data endpoints in the Apiverket API.
Use this tool to find the right endpoint before calling govdata_query. The API covers 139 endpoints across 16 categories including weather, transport, economy, health, environment, parliament, police, education, and more.
Args:
query (string, optional): Keyword to search across endpoint names, descriptions, and paths
category (string, optional): Filter by category name
When called with no arguments, returns all available categories with endpoint counts.
Examples:
Find weather endpoints: query="weather"
Browse transport category: category="Transport"
Find pension info: query="pension"
List all categories: (no arguments)
Returns: Matching endpoints with their paths, parameters, and descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search keyword to find relevant endpoints (e.g. 'weather', 'train', 'population', 'pension'). Leave empty to list all categories. | |
| category | No | Filter by category name (e.g. 'Weather & Climate', 'Economy & Finance'). Use without query to browse a category. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent. The description adds detail about return values (paths, parameters, descriptions) and behavior with no arguments (returns categories). This supplements the annotations without contradicting them.
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 well-structured with clear sections (Args, Examples, Returns). It is concise, uses bullet points for readability, and every sentence serves a purpose. No unnecessary repetition or fluff.
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 simplicity (2 optional parameters, no output schema, simple behavior), the description is fully complete. It covers all inputs, explains behavior comprehensively, and describes return values. No gaps remain.
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%, so baseline is 3. The description adds value by explaining parameter usage (e.g., 'Use without query to browse a category'), providing examples, and clarifying constraints (maxLength hinted in schema). This extra context justifies a score above baseline.
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: 'Search and browse available Swedish government data endpoints'. It specifies the verb (search and browse), resource (endpoints), and distinctively positions it as a discovery tool complementary to the sibling govdata_query.
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 'Use this tool to find the right endpoint before calling govdata_query', providing clear context. It includes examples for different use cases and explains behavior with no arguments. However, it does not explicitly mention scenarios where this tool should not be used, leaving a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call any Apiverket API endpoint to retrieve Swedish government data.
Use govdata_discover first to find the right endpoint path and required parameters. Then call this tool with the endpoint path and any path/query parameters.
Args:
endpoint (string, required): The API path (e.g. "/v1/weather/{city}")
path_params (object, optional): Values for path parameters like {city}, {code}, {id}
query_params (object, optional): Query string parameters (q, limit, offset, lat, lon, etc.)
Examples:
Current weather in Stockholm: endpoint="/v1/weather/{city}", path_params={"city": "stockholm"}
Search jobs: endpoint="/v1/jobs/search", query_params={"q": "developer", "limit": 5}
Train departures from Stockholm Central: endpoint="/v1/transport/trains/{station}", path_params={"station": "Cst"}
Exchange rates: endpoint="/v1/rates"
Population by municipality: endpoint="/v1/population/{municipalityCode}", path_params={"municipalityCode": "0180"}
Police events in Stockholm: endpoint="/v1/police/events", query_params={"location": "Stockholm", "limit": 10}
Find EV chargers near a location: endpoint="/v1/infrastructure/ev-chargers", query_params={"lat": 59.33, "lon": 18.07}
Returns: The API response as JSON, containing a "meta" envelope with request info and a "data" object with the actual data.
Error handling:
Returns clear error messages if the API is unreachable, the endpoint doesn't exist, or parameters are invalid
Large responses are automatically truncated with pagination guidance
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint | Yes | API endpoint path from the discover tool (e.g. '/v1/weather/{city}', '/v1/rates', '/v1/police/events') | |
| path_params | No | Path parameter values to substitute in the endpoint URL. Example: { "city": "stockholm" } for /v1/weather/{city} | |
| query_params | No | Query string parameters. Example: { "q": "developer", "limit": 5 } for search endpoints |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by explaining the return format ('meta envelope with data'), error handling (clear messages, automatic truncation with pagination guidance), and that large responses are truncated. No contradiction with annotations.
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 well-structured with clear sections (Args, Examples, Returns, Error handling). It is appropriately sized—every sentence provides necessary information without redundancy. Examples are concrete and diverse.
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?
Despite no output schema, the description explains the return structure and error behavior. It covers all 3 parameters thoroughly, references the sibling tool, and gives ample examples. The tool's complexity is well-addressed.
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%. The description enhances understanding with examples showing how path_params substitute in the URL and query_params are for query strings. It also explains what types of parameters are expected ('string' for path_params; 'string, number, boolean' for query_params), adding meaning 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 'Call any Apiverket API endpoint to retrieve Swedish government data.' It specifies the verb 'Call' and the resource 'any endpoint'. It distinguishes from the sibling tool 'govdata_discover' by directing users to use discover first for finding endpoints, then query for calling them.
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 says 'Use govdata_discover first to find the right endpoint path and required parameters. Then call this tool...' This provides clear when-to-use guidance and names the alternative tool.
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. Dates show when Glama detected each change.
v1.0.0govdata_discovergovdata_queryThe two tools serve clearly distinct purposes: govdata_discover for exploring available endpoints and govdata_query for retrieving data. No functional overlap exists.
Both tools follow a consistent govdata_verb pattern using snake_case, making their purpose predictable.
With only 2 tools for a domain covering 139 endpoints across 16 categories, the count is minimal but appropriate for the discover-query pattern. However, it may feel thin for the broad scope.
The pair covers the complete lifecycle: discovery then retrieval. For a read-only government data API, this is sufficient. Minor gaps like built-in pagination handling are mitigated by error messages.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Swedish open data for Claude and other AI assistants - verified, with sources.
Agent-native API for Finnish public company data via YTJ. Pay-per-call $0.01 USDC over x402.
Swedish B2B intelligence: insolvency risk, BRF health & procurement signals from govt registries.
Nordic company intelligence: look up companies, AI summaries, scores and signals via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/vinvuk/apiverket-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
