How do I use adzuna-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@adzuna-mcp show salary distribution for software engineer in London" 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.

adzuna-mcp

by soheilfallah

Overview Schema Related Servers Score Discussions

Python

adzuna-mcp

⚠️ Moved. This server now lives in the job-hunt monorepo at job-hunt/connectors/adzuna-mcp. This standalone repo is archived (read-only) and kept only for existing links. Get the current version, docs, and setup there.

A local stdio MCP server wrapping the Adzuna API. Built to sit alongside a listings source like Indeed: Indeed finds ads, Adzuna adds the salary and market data that listings boards don't expose — distributions, trends, regional vacancy counts and employer leaderboards.

Tools

Tool	What it gives you
`adzuna_search_jobs`	Job ads with salary range, contract type, category, `redirect_url`
`adzuna_list_categories`	Valid `category` tags (call before filtering by category)
`adzuna_salary_histogram`	Salary distribution for a role/location — is £45k ambitious or low?
`adzuna_salary_history`	Month-by-month average salary trend
`adzuna_regional_breakdown`	Vacancy counts by sub-region; also how you discover `location0/1/2` values
`adzuna_top_companies`	Top 5 employers by vacancy count + their average salary
`adzuna_estimate_salary`	Predicted salary for a title + description (Adzuna Jobsworth) — price a role that states no salary

All tools are read-only and take country (default gb) and response_format (markdown for compact reading, json for programmatic use).

Related MCP server: mcp-adzuna

Using it with `/cv-tailor`

The intended loop when tailoring a CV to a target role:

Find live ads. adzuna_search_jobs with what_phrase (exact role), where + distance, and max_days_old to skip stale posts. Sort fresh-first with sort_by=date.
```
adzuna_search_jobs(what_phrase="audio visual technician", where="london",
                   distance=20, max_days_old=30, sort_by="date")
```
Read the full JD. Each result gives only a snippet — fetch its redirect_url for the complete description, then feed that into /cv-tailor as the job spec.
Heads-up: Adzuna's …/jobs/details/<id> page is JavaScript-rendered, so a plain HTTP fetch returns an empty shell. Read it with a JS-capable fetch (Claude-in-Chrome), or follow the …/jobs/land/ad/<id> redirect variant, which forwards to the employer's ATS where the full JD is usually server-rendered. This is Adzuna's frontend behaviour, not a server bug.
Price a role with no stated salary. Many ads omit pay. adzuna_estimate_salary(title, description) returns Adzuna's predicted figure so you can set expectations before applying.
Sanity-check your target £. adzuna_salary_histogram(what=...) shows where a figure sits in the live market; adzuna_salary_history shows whether pay is trending up or down.
Build an outreach list. adzuna_top_companies(what=...) surfaces who is hiring at volume for the role — feed a canonical_name back into adzuna_search_jobs company to see their ads.

Cowork//cv-tailor sessions read and write files under C:\Users\flhso\Claude (coworkUserFilesPath), so drop JDs and CV drafts there to keep them in view.

The one real limitation

Adzuna returns only a snippet of each job description. Every search result carries a redirect_url. To get a full JD you fetch that URL yourself. This is why the pairing with a crawler matters: Adzuna is a fast, filterable, salary-aware index; the full text lives behind the redirect.

Setup

Register at https://developer.adzuna.com/signup for a free app_id / app_key. (Note: this is a separate account from a normal adzuna.co.uk jobseeker login.)
Install:

cd adzuna-mcp
uv venv && uv pip install mcp httpx python-dotenv
# or: python -m venv .venv && .venv/bin/pip install mcp httpx python-dotenv

For local runs (and the mcp-inspector verify step below), copy .env.example to .env and fill in your app_id / app_key — server.py loads it automatically. Real env vars still win over .env, so the .mcp.json env block below keeps working.

Wire it into Claude Code — .mcp.json in your project, or claude mcp add:

{
  "mcpServers": {
    "adzuna": {
      "command": "python",
      "args": ["D:\\soh-workspace\\projects\\adzuna-mcp\\server.py"],
      "env": {
        "ADZUNA_APP_ID": "your_app_id",
        "ADZUNA_APP_KEY": "your_app_key"
      }
    }
  }
}

Use the absolute path to the venv's python (.venv\Scripts\python.exe on Windows) if the dependencies aren't on your global interpreter.

Verify before wiring it up:

npx @modelcontextprotocol/inspector python server.py

Country support

gb us at au br ca de fr in nz pl za — annual salaries, local currency. The server accepts any two-letter code and lets Adzuna's 404 tell you if one isn't served, so the list staying accurate isn't a hard dependency.

Rate limits

Adzuna's default free/trial limits (per their Terms of Service) are 25 hits/min, 250/day, 1000/week, 2500/month. The server surfaces a 429 with a clear message. Prefer fewer, wider queries over many narrow ones; adzuna_salary_histogram answers "what does this pay?" in one call where a paginated search would take several.

Trial-tier data also can't be republished or aggregated into ongoing work beyond the 14-day evaluation without a licence — fine for personal job-hunt research, worth knowing before you build anything public on it.

Notes

Keyword semantics matter. what ANDs its words — every word must appear, so what="plant science research assistant agronomist" matches almost nothing. Use what_or to match ANY of several terms in one call, what_phrase for an exact phrase, or title_only to restrict to the job title. There is no cross-field OR, so for genuinely different role titles run one search per variant (or list them in a single what_or).
location0/1/2 are exact strings, not free text. Get them from adzuna_regional_breakdown — the area array on each result is literally the values to pass back in.
where="United Kingdom" narrows to almost nothing — use a city + distance, or omit where and rely on location0/1/2.
where + distance is the free-text alternative and is usually easier.
salary_is_predicted: 1 means Adzuna estimated the figure; the ad didn't state it. Don't quote predicted numbers as if the employer published them.
Not implemented: version. A small addition if wanted.

Available Tools

7 tools

adzuna_estimate_salaryA

Read-onlyIdempotent

Estimate an annual salary for a role from its title and description (Adzuna Jobsworth).

Unlike the histogram/history tools (which summarise live ads), this predicts a single figure for a specific role you describe — useful for pricing a CV target or sanity-checking a job ad that states no salary. Feed it a job title plus the ad body or a skills summary.

Args: params (JobsworthInput): Validated parameters containing: - country (str): ISO code, default 'gb' - title (str): the job title to price - description (str): role/skills text; the full JD works well - response_format (ResponseFormat): 'markdown' or 'json'

Returns: str: Markdown with the estimated annual salary, or JSON with key salary (float, local currency). The salary key is absent when Adzuna cannot produce an estimate. On failure, an 'Error: ...' string explaining the cause.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

The description goes beyond annotations by explaining the tool's predictive behavior (single figure, Adzuna Jobsworth), output formats (markdown/json), and error handling. Annotations already declare readOnlyHint/idempotentHint, so the description adds useful behavioral context without contradiction.

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 with clear sections (purpose, usage, args, returns) and no unnecessary words. It is concise yet comprehensive, earning its place with every sentence.

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

Completeness5/5

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

Given the simple input/output structure, the description covers input parameters, output format, error behavior, and comparison to siblings. It provides sufficient context for an AI agent to invoke the tool correctly without additional explanation.

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?

The description includes an Args section that briefly explains each parameter (title, country, description, response_format), but the schema already provides detailed descriptions for these. Since schema description coverage is reported as 0% (though the schema itself contains descriptions), the description adds limited extra value beyond restating schema information.

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: 'Estimate an annual salary for a role from its title and description.' It also distinguishes itself from sibling tools by contrasting with histogram/history tools that summarize live ads, making the unique value proposition explicit.

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 specifies when to use this tool ('pricing a CV target or sanity-checking a job ad that states no salary') and explicitly identifies alternatives ('Unlike the histogram/history tools'), providing clear usage guidance.

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

adzuna_list_categoriesA

Read-onlyIdempotent

List the job categories Adzuna applies in a given country.

Call this before using the category filter on other tools — tags are country-specific and must match exactly (e.g. 'it-jobs', 'scientific-qa-jobs').

Args: params (CategoriesInput): Validated parameters containing: - country (str): ISO code, default 'gb' - response_format (ResponseFormat): 'markdown' or 'json'

Returns: str: Markdown table of tag/label pairs, or JSON with key results (list of objects with tag (str) and label (str)). On failure, an 'Error: ...' string explaining the cause.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

The description adds context beyond annotations by explaining the exact matching requirement for tags, the return format (Markdown table or JSON), and error behavior. Since annotations already indicate readOnlyHint and idempotentHint, the description supplements with useful behavioral details.

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

Conciseness5/5

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

The description is concise (8 sentences) and well-structured, with the purpose stated first followed by a usage guideline, then parameter list and return format. Every sentence adds value with no redundancy or irrelevant information.

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

Completeness5/5

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

Given the tool's simplicity (listing categories), the description covers input parameters, usage context, output format, and error handling. It is fully complete for an agent to understand and invoke the tool correctly, especially with the presence of an output schema.

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?

The description restates the parameter meanings already present in the input schema (country as ISO code, response_format as markdown or json). It does not add new semantic depth beyond what the schema provides, so a baseline score of 3 is appropriate given the high schema description coverage.

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?

Clearly states 'List the job categories Adzuna applies in a given country.' It specifies the verb 'list' and the resource 'job categories', and distinguishes itself from sibling tools by indicating it is a prerequisite for using the 'category' filter elsewhere.

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

Usage Guidelines4/5

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

Explicitly says 'Call this before using the `category` filter on other tools' and explains that tags are country-specific and must match exactly. This provides strong when-to-use context, though it does not explicitly mention when not to use it or provide alternative tools.

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

adzuna_regional_breakdownA

Read-onlyIdempotent

Get the number of live vacancies in the sub-regions of a location.

Doubles as the discovery tool for location filters: the area array on each result holds the exact strings to pass as location0/location1/location2 elsewhere. Call with no location to see a country's top-level regions.

Args: params (GeodataInput): Validated parameters containing: - country (str): ISO code, default 'gb' - location0/1/2 (Optional[str]): area whose children to list - category (Optional[str]): category tag to limit counts - response_format (ResponseFormat): 'markdown' or 'json'

Returns: str: Markdown table of sub-region, vacancy count and area path, or JSON with key locations (list of objects with count (int) and location {display_name (str), area (list[str])}). On failure, an 'Error: ...' string explaining the cause.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's burden is lower. It adds useful behavior context, such as returning both markdown and JSON formats and error handling. However, it could mention potential empty results or rate limits.

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 with a clear overview, usage note, Args block, and Returns section. Every sentence is informative and concise, with 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?

Given that the tool has an output schema (though not shown), the description still adequately explains the return format (markdown or JSON with locations list and error strings). Combined with annotations and schema, it is fully complete.

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?

Despite schema description coverage being reported as 0%, the description's Args block provides detailed parameter explanations, including defaults and usage (e.g., country format, location hierarchy). This adds significant value beyond the schema's own descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'number of live vacancies in sub-regions of a location.' It distinguishes from sibling tools like adzuna_search_jobs or adzuna_salary_histogram by focusing on regional breakdowns.

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 explicitly tells when to use the tool: as a discovery tool for location filters. It gives guidance on calling with no location to see top-level regions and explains how the 'area' array can be used in other tools.

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

adzuna_salary_histogramA

Read-onlyIdempotent

Get the current distribution of advertised salaries for a role and/or location.

Each key is the LOWER bound of an annual salary band in local currency; each value is the number of live vacancies in that band. Use it to sanity-check a salary expectation or to see where a target figure sits in the market.

Args: params (HistogramInput): Validated parameters containing: - country (str): ISO code, default 'gb' - what (Optional[str]): role keywords - location0/1/2 (Optional[str]): hierarchical location filter - category (Optional[str]): category tag - response_format (ResponseFormat): 'markdown' or 'json'

Returns: str: Markdown table of salary band vs vacancy count, or JSON with key histogram (dict mapping salary-band lower bound (str) to vacancy count). Band order is not guaranteed by the API; this tool sorts it. On failure, an 'Error: ...' string explaining the cause.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds value by noting that the API does not guarantee band order but this tool sorts it, and by explaining the error handling ('On failure, an Error... string'). This provides important behavioral details beyond annotations.

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

Conciseness5/5

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

The description is concise and well-structured: a one-line summary, followed by a clear explanation of the output, a bulleted Args section, and a return format description. It is front-loaded with the purpose and every sentence adds value. No redundant or vague statements.

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 purpose, parameters, output formats, error handling, and a notable sorting behavior. It mentions the response format options (markdown and JSON) and explains the histogram structure. Given that an output schema exists, it is not necessary to detail the return structure further. However, it could be more explicit about the supported country codes and the category parameter's source (adzuna_list_categories), which are only in the schema.

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

Parameters4/5

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

Schema description coverage is 0% for the tool's single `params` parameter, but the description compensates by listing each nested field (country, what, location0/1/2, category, response_format) with brief explanations. While the schema itself has good inline descriptions, the description organizes them clearly and reinforces the semantics. A slight gap is not providing examples of valid inputs, but overall adds meaningful value.

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 'Get' and the resource 'distribution of advertised salaries for a role and/or location'. It explains the output structure (salary band lower bound to vacancy count). The title from annotations ('Get salary distribution') aligns with this. Among siblings, it distinguishes itself from adzuna_salary_history (historical trends) and adzuna_estimate_salary (single estimate) by focusing on current distribution.

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

Usage Guidelines4/5

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

The description provides explicit use cases: 'Use it to sanity-check a salary expectation or to see where a target figure sits in the market.' This gives clear context for when to use the tool. However, it does not mention alternative sibling tools or explicitly state when not to use it, which would improve clarity further.

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

adzuna_salary_historyA

Read-onlyIdempotent

Get the average advertised salary month by month for a role, category and/or location.

Shows whether pay for a role is trending up or down over time.

Args: params (HistoryInput): Validated parameters containing: - country (str): ISO code, default 'gb' - what (Optional[str]): role keywords - location0/1/2 (Optional[str]): hierarchical location filter - category (Optional[str]): category tag - months (Optional[int]): months of history to return - response_format (ResponseFormat): 'markdown' or 'json'

Returns: str: Markdown table of month vs average salary, or JSON with key month (dict mapping 'YYYY-MM' (str) to average annual salary (float)). Month order is not guaranteed by the API; this tool sorts it. On failure, an 'Error: ...' string explaining the cause.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior4/5

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 valuable behavioral details: month sorting correction, error handling, and return format specifics, which go beyond annotations.

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

Conciseness4/5

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

The description is well-structured with a clear purpose statement followed by parameter documentation. It is informative without being overly verbose, though some redundancy exists (e.g., repeating 'month' multiple times).

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?

Covers input parameters, output format, error behavior, and sorting. Given the presence of a detailed schema and annotations, the description provides sufficient context, missing only a brief example or use case.

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

Parameters4/5

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

The description enumerates all parameters from the schema and explains their purpose (e.g., 'what' for role keywords, 'months' for history length). This adds meaning beyond the schema's own descriptions, especially for ResponseFormat.

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 retrieves monthly average advertised salaries for a role, category, or location. It uses a specific verb ('Get') and resource, and the added detail about trending distinguishes it from sibling tools like adzuna_salary_histogram.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives such as adzuna_salary_histogram or adzuna_regional_breakdown. The description only explains what the tool does without providing comparative context.

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

adzuna_search_jobsA

Read-onlyIdempotent

Search Adzuna's job advertisement database with keyword, location, salary and contract filters.

Returns ads including title, employer, location, salary range (annual, local currency), contract type, category, posting date and a redirect_url. Adzuna only returns a SNIPPET of each description — fetch the redirect_url to read the full ad.

Args: params (SearchJobsInput): Validated search parameters. Key fields: - country (str): ISO code, default 'gb' - what / what_or / what_and / what_phrase / what_exclude / title_only (Optional[str]): keyword filters - where (Optional[str]) + distance (Optional[int]): free-text location and radius in km - location0/1/2 (Optional[str]): hierarchical location filter - category (Optional[str]): tag from adzuna_list_categories - salary_min / salary_max (Optional[int]): annual salary bounds - full_time / part_time / permanent / contract (Optional[bool]): contract filters - max_days_old (Optional[int]), sort_by (Optional[SortBy]), page, results_per_page - response_format (ResponseFormat): 'markdown' or 'json'

Returns: str: Markdown summary of matching ads, or JSON with keys count (int, total matches), mean (float, mean salary) and results (list of job objects each containing id, title, description, created, redirect_url, salary_min, salary_max, salary_is_predicted, contract_type, contract_time, latitude, longitude, company{display_name}, location{display_name, area[]}, category{label, tag}). On failure, an 'Error: ...' string explaining the cause.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations declare readOnlyHint and idempotentHint, which the description aligns with. The description adds behavioral details: returns only a snippet of descriptions, requiring fetching the redirect_url for full ads, and mentions error handling (returns 'Error: ...' string).

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

Conciseness4/5

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

The description is well-structured with a concise intro, bullet-point parameter list, and return value explanation. It is comprehensive but slightly lengthy; however, every sentence serves a purpose.

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

Completeness5/5

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

Given the tool's complexity (many optional filters, output schema exists), the description is complete. It covers input parameters, output format, failure mode, and a key behavioral note (snippet vs. full ad). No gaps found.

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

Parameters4/5

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

The description provides an Args section that explains each parameter's purpose, adding context beyond the schema descriptions. Though a few parameters like sort_direction and salary_include_unknown are omitted, the coverage is high and adds value (e.g., explaining keyword AND/OR semantics).

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 searches Adzuna's job advertisement database with filters, and lists the fields returned. It distinguishes from sibling tools like adzuna_list_categories and adzuna_salary_histogram by its specific search function.

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

Usage Guidelines3/5

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

The description does not explicitly state when to use this tool versus alternatives, nor when not to use it. It implicitly references adzuna_list_categories for category selection but lacks direct usage guidance.

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

adzuna_top_companiesA

Read-onlyIdempotent

Get a leaderboard of the employers with the most open vacancies for a search.

Useful for building a cold-outreach target list: it surfaces who is hiring at volume for a role and roughly what they pay, which a plain job search does not.

Args: params (TopCompaniesInput): Validated parameters containing: - country (str): ISO code, default 'gb' - what (Optional[str]): role keywords - location0/1/2 (Optional[str]): hierarchical location filter - category (Optional[str]): category tag - response_format (ResponseFormat): 'markdown' or 'json'

Returns: str: Markdown table of employer, vacancy count and average salary, or JSON with key leaderboard (list of objects with canonical_name (str), count (int) and average_salary (float)). Feed canonical_name back into adzuna_search_jobs company to list that employer's ads. On failure, an 'Error: ...' string explaining the cause.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint. Description adds return format details (markdown vs JSON) and error handling, which are useful behavioral traits.

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?

Well-structured with purpose, use case, parameter list, and return description. Every sentence adds value, no fluff, and appropriately sized.

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?

The description fully explains how to use the tool, including return formats and how to feed results into adzuna_search_jobs. No obvious gaps.

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?

Despite schema coverage reported as 0%, the description provides a detailed Args section explaining each parameter and its purpose, adding significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool returns a leaderboard of employers with most open vacancies. Verbs and resource are specific, and it distinguishes from plain job search.

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 a concrete use case (cold-outreach target list) and hints at when to use over general search. Lacks explicit when-not-to-use or comparison to sibling tools, but sufficient for context.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: searching jobs, listing categories, salary histogram, salary history, regional breakdown, top companies, and salary estimation. No overlapping functionality, and descriptions are sufficiently detailed to differentiate them.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case, prefixed with 'adzuna_'. The naming is predictable and clear, aiding agent understanding.

Tool Count5/5

With 7 tools, the server is well-scoped for a job search API. Each tool serves a necessary function without redundancy, fitting within the ideal 3-15 range.

Completeness4/5

The tool set covers core functionalities like job search, category listing, salary analysis, regional data, and top companies. A minor gap is the lack of a dedicated tool to fetch a single job by ID, but the search tool provides sufficient detail via redirect_url.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

india-jobs-mcp
com.themineworks
Aggregated India job-market data: 9 job boards, LinkedIn sourcing, AmbitionBox employer snapshots.
Open Data Research & Data Search
1
HasData Indeed
com.hasdata
Indeed job listings by keyword and location, and full postings, as structured JSON.
Search Open Data
11
hirejack-mcp
io.github.TVLSS
Tech job market intelligence: jobs, companies, salaries, skill velocity, hiring trends.
Research & Data Search
3
reapx jobs - listings from Greenhouse, Workable, Reed and more
dev.reapx
Scrape job listings from Greenhouse, Workable, Reed, RemoteOK and other boards. Pay per row.
Web Scraping Browser Automation
1

Related MCP Servers

Adzuna Jobs MCP Server
Search Research & Data
folathecoder
A
license
A
quality
D
maintenance
Provides AI assistants with access to the Adzuna Job Search API to search millions of job listings, analyze salary data, and research top employers across 12 countries with comprehensive filtering options.
Updated 8 months ago (2026-01-12 08:10 UTC)
7
15
MIT
mcp-adzuna
Search Research & Data
pipeworx-io
A
license
Not graded
quality
C
maintenance
Provides access to Adzuna's global job-board aggregation, enabling job search, salary analysis, and regional stats via natural language queries.
Updated 8 days ago (2026-08-26 17:34 UTC)
18
MIT
mcp-lightcast
Search Research & Data AI & Machine Learning
lawwu
A
license
Not graded
quality
D
maintenance
Integrates with Lightcast APIs to search job titles, extract skills from text, and access career data for analysis.
Updated a year ago (2025-08-22 05:09 UTC)
5
MIT
JobLens MCP
Search Research & Data
rohith-jpg
A
license
A
quality
C
maintenance
Provides job search, local resume parsing, and resume-to-job matching via official APIs and local file processing.
Updated a month ago (2026-07-21 05:08 UTC)
5
MIT

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/soheilfallah/adzuna-mcp'

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

adzuna-mcp

Tools

Using it with /cv-tailor

The one real limitation

Setup

Country support

Rate limits

Notes

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Using it with `/cv-tailor`