Skip to main content
Glama
Sign In
Arbetsförmedlingen MCP

Arbetsförmedlingen MCP

by iwsen
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Search jobs

search_jobs
Read-onlyIdempotent

Search for job opportunities across Sweden. Filter results by skills, location, occupation, and work model. Use plain language to query the Platsbanken job database.

Instructions

Search jobs in Platsbanken (Arbetsförmedlingen). All filters are optional and combined with AND. Places, occupations and skills can be given as plain names — they are matched to the taxonomy automatically. Returns short cards; use get_job for the full ad text.

Input Schema

NameRequiredDescriptionDefault
qNoFree text: job title, technology, employer, e.g. "python" or "sjuksköterska"
sortNoSort order: relevance, publication date or application deadlinerelevance
limitNoHow many jobs to return (1–2100; more than 100 takes several consecutive API requests)
skillNoSkills. Names ("Python") or concept ids from the taxonomy
offsetNoPagination offset (0–2000, API ceiling)
regionNoRegions (län). Names ("Stockholms län") or concept ids from the taxonomy
remoteNotrue — jobs where remote work is likely
larlingNotrue — apprenticeships (lärling)
traineeNotrue — traineeships (trainee)
employerNoEmployer name or organization number (digits only)
latitudeNoLatitude for radius search
longitudeNoLongitude for radius search
radius_kmNoRadius in km (requires latitude and longitude)
occupationNoOccupations. Names ("Systemutvecklare") or concept ids from the taxonomy
municipalityNoMunicipalities. Names ("Göteborg") or concept ids from the taxonomy
open_for_allNotrue — "Öppen för alla" ads
employment_typeNoEmployment type. Names ("Vanlig anställning") or concept ids from the taxonomy
published_afterNoISO date or datetime (YYYY-MM-DD / YYYY-MM-DDTHH:MM:SS), or a number of minutes ago
workplace_modelNoWorkplace model. Names ("Distans") or concept ids from the taxonomy
worktime_extentNoWorking hours. Names ("Heltid") or concept ids from the taxonomy
occupation_fieldNoOccupation fields. Names ("Data/IT") or concept ids from the taxonomy
published_beforeNoISO date or datetime
description_charsNoHow many characters of the description to include in the card (0 — no description)
experience_not_requiredNotrue — only jobs with no experience requirement
driving_license_requiredNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover read-only/idempotent/open-world safety, so the bar is lower; the description still adds useful behavior: results are short cards rather than full ads, plain names are auto-resolved against the taxonomy, and it flags that a limit above 100 triggers several consecutive API requests. It does not describe pagination interplay or result shape in detail, but that is largely covered elsewhere.

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?

Four compact sentences, front-loaded with what the tool is and what it returns, with no filler. Every sentence carries a distinct piece of information.

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 25-parameter tool with no output schema, the description covers the essentials: source, filter combination semantics, return format ('short cards'), and where to get full detail. The only gap is a slightly vague notion of what a 'card' contains, which an agent must learn by calling it.

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

Parameters3/5

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

Schema description coverage is 96%, so the schema already documents nearly every parameter, establishing a baseline of 3. The description adds the AND-combination rule for filters and the name-to-taxonomy matching behavior, which is genuinely beyond the schema, but nothing else about the 25 parameters is elaborated.

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?

States a specific verb and resource ('Search jobs in Platsbanken (Arbetsförmedlingen)') and explicitly separates itself from the sibling get_job ('use get_job for the full ad text'). An agent can distinguish it from search_taxonomy, suggest, and job_stats from the description alone.

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?

Explains that all filters are optional and AND-combined, and names the alternative (get_job) with the condition that selects it (needing full ad text). Lacks explicit 'when not to use' guidance for the other siblings, but the usage context is clear.

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

Deploy Server

Other Tools