adzuna-mcp

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.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.
Average 4.4/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![adzuna-mcp MCP server](https://glama.ai/mcp/servers/soheilfallah/adzuna-mcp/badges/card.svg)](https://glama.ai/mcp/servers/soheilfallah/adzuna-mcp)

Score Badge

Copy to your README.md:

[![adzuna-mcp MCP server](https://glama.ai/mcp/servers/soheilfallah/adzuna-mcp/badges/score.svg)](https://glama.ai/mcp/servers/soheilfallah/adzuna-mcp)

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