Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@profesia-mcp find remote Python jobs in Bratislava paying at least 3000 EUR/month"
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.
An unofficial Model Context Protocol server for Profesia.sk, the largest Slovak job board. It lets an AI assistant (Claude Desktop, Claude Code, Cursor, …) search jobs, read full offers, bulk-collect results and prepare applications.
Not affiliated with, endorsed by, or sponsored by Profesia.sk / Alma Career. Profesia is a trademark of its owner. Use it in line with Profesia's terms of use and applicable law.
Tool | What it does |
| Search offers by keywords, location or category, minimum salary, remote/hybrid/on-site, with paging (20 per page). |
| Full offer by id or URL: title, company, location, salary (+ note), contract type, date posted, description and structured sections (requirements, languages, benefits, contact…). |
| How to apply: apply link(s), contact emails found in the offer, and the "selection process" text. |
| Open jobs of one employer ( |
| Bulk collection across several pages, optionally with full details (hard caps: 5 pages, 25 detail pages per call). |
| Valid |
This server does not submit applications and never touches credentials. Applying on Profesia goes through a logged-in account (or the employer's own site, or plain email), and automating that would mean handling your password and bypassing the site's protections. Instead, get_application_info returns the right link or email, so your assistant can read the offer, draft a tailored CV/cover letter or email, and you send it.
Related MCP server: trackly-cli
Once installed, ask your assistant something like:
"I'm a student who can work at most 20 hours a week. Find part-time Python / AI jobs in Bratislava that accept secondary-school students, and tell me how to apply."
It will call search_jobs (e.g. category="na-dohodu-brigady", which is Profesia's part-time / agreement-based section), read the best matches with get_job, check the education requirements, and use get_application_info to give you the apply link or email.
Requires Python 3.10+. With uv:
uvx --from git+https://github.com/kiko-siska/profesia-mcp profesia-mcpor from a clone: pip install . then run profesia-mcp.
claude mcp add profesia -- uvx --from git+https://github.com/kiko-siska/profesia-mcp profesia-mcpclaude_desktop_config.json){
"mcpServers": {
"profesia": {
"command": "uvx",
"args": ["--from", "git+https://github.com/kiko-siska/profesia-mcp", "profesia-mcp"]
}
}
}"Find remote Python jobs on Profesia paying at least 3000 EUR/month and summarise the top 5."
"Compare the requirements of these three offers and tell me which fits my CV."
"Read offer 5356737 and draft an email application for me in Slovak."
The server is intentionally conservative:
robots.txt is enforced in code (client.py): disallowed URLs (e.g. anything with count_days=, form=, ajax, print=1, send_cv.php, list_similar_offers.php) are never requested.
Rate limit: one request at a time, at least 1 s apart (PROFESIA_MCP_MIN_INTERVAL).
Cache: responses are cached for 10 minutes (PROFESIA_MCP_CACHE_TTL).
Honest User-Agent that identifies this project. If you fork it, set PROFESIA_MCP_USER_AGENT (and update the default in client.py).
Read-only: only GET requests to www.profesia.sk; no login, no form submission.
Please don't use scrape_jobs to mirror the site or republish its content. Offers belong to their employers and to Profesia.
It parses HTML, which can change without notice; the offline tests in tests/ (saved page fixtures for several different offer layouts, with personal contact details scrubbed) will tell you when a parser breaks.
Employers may use custom page designs. Core fields are filled for all layouts tested, but sections is only available for the standard layout, and some large employers' company pages (company_jobs) are custom-built and may return no jobs; use search_jobs with the company name instead.
Offer text is in Slovak, English or other languages, depending on the employer.
With a keyword search Profesia only offers relevance sorting. The tracking search_id is stripped from URLs.
python -m venv .venv && . .venv/bin/activate
pip install -e ".[dev]"
pytest # offline; uses saved HTML fixturesWorks with mcp 1.x (FastMCP) and 2.x (MCPServer).
MIT, see LICENSE.
List open jobs of one employer.
Args: company: Company page URL or path such as "https://www.profesia.sk/praca/pro-hr/C56404" or "pro-hr/C56404" (company slug + C-id; both appear in search_jobs / get_job results). page: Page number, starting at 1.
Note: some large employers use custom-designed pages; if no jobs are returned for them,
use search_jobs with the company name as query instead.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| company | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavior beyond that: some large employers use custom pages and may legitimately return an empty job list, which is a caveat an agent would otherwise misread as failure.
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 one-line purpose is front-loaded, followed by Args and a Note section that is scannable. The company example string is slightly long but is doing real disambiguation work, so little is wasted.
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?
With an output schema present, return values need no explanation, and both input parameters are fully described. The custom-page caveat covers the main edge case; only pagination depth/limits are left unstated, which is a minor gap for a two-parameter listing tool.
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 description coverage is 0%, so the description carries the full burden and does so well. It documents both `company` (accepts a full URL or a 'slug/C-id' path, with a concrete example and where those identifiers come from) and `page` (1-based start), leaving no ambiguity about accepted formats.
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?
Opens with a precise verb+resource+scope: 'List open jobs of one employer.' The agent can immediately tell this apart from get_job (single job) and search_jobs (query-based search) without opening any schema.
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?
Explicitly routes the agent to search_jobs as the fallback when a large employer with a custom-designed page returns no jobs, and points out that the company slug+C-id appear in search_jobs/get_job results. Clear context is given, though the primary 'when to prefer this over search_jobs' condition is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find out how to apply for a job, so the user (or you, drafting for them) can apply.
This tool does NOT submit anything and never handles credentials. It returns the apply link(s) (Profesia account login or the employer's own site), any contact emails found in the offer, and the offer's "selection process" text. Typical use: read the offer with get_job, draft a tailored cover letter/email, and hand it to the user to send.
Args: job: Offer id ("5356737", "O5356737") or a profesia.sk offer URL.
| Name | Required | Description | Default |
|---|---|---|---|
| job | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover readOnlyHint/openWorldHint; the description adds substantive traits beyond that — no submission, no credential handling, and the concrete shape of what comes back (apply links, contact emails, selection-process text). This removes the main ambiguity an agent would have about a job-application tool.
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?
Front-loaded and well-organized with a clear Args section; every sentence is useful. The opening clause is mildly redundant ('how to apply for a job, so the user can apply'), but nothing is wasted overall.
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 an output schema exists, the description need not explain return values — yet it still names the key returned artifacts, plus the non-submission guarantee and id-format rules. Nothing needed to call this tool correctly is missing.
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 0% and the single parameter is bare, so the description must carry it — and it does, documenting accepted id formats ('5356737', 'O5356737') and a profesia.sk URL as valid input.
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?
States a specific verb and resource ('returns the apply link(s), contact emails, and selection-process text') rather than restating the name. It immediately distinguishes itself from get_job/search_jobs by describing the distinct artifact it produces.
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?
Gives an explicit workflow: 'read the offer with get_job, draft a tailored cover letter/email, and hand it to the user to send.' It also states when NOT to reach for it ('does NOT submit anything and never handles credentials'), which is exactly the kind of exclusion an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full details of one job offer.
Args: job: Offer id ("5356737", "O5356737") or a profesia.sk offer URL.
Returns title, company, location, salary (+ note), contract type, date posted,
the full description, and sections (requirements, languages, benefits, contact...)
when the employer uses the standard layout.
| Name | Required | Description | Default |
|---|---|---|---|
| job | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuine behavioral context beyond that: the returned payload includes title, company, location, salary with note, contract type, date, full description, and a conditional `sections` block that appears 'when the employer uses the standard layout' — disclosing return-shape variability.
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?
Front-loaded one-line purpose, then clearly labeled Args and Returns sections. Every line carries information (accepted id forms, return fields, conditional sections) with no filler.
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?
For a single-parameter read tool with annotations covering safety and an output schema present, the description supplies the missing pieces: accepted id syntax and the conditional nature of `sections`. Nothing needed to call it correctly is absent.
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 description coverage is 0% and the lone 'job' parameter is entirely undocumented in the schema, yet the description specifies accepted forms: bare offer id '5356737', prefixed 'O5356737', or a profesia.sk offer URL. This is exactly the compensation needed for a 0%-coverage parameter.
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?
States a specific verb and resource: 'Get the full details of one job offer.' This implicitly separates it from the list-oriented siblings (search_jobs, company_jobs) by scoping to a single offer, though no sibling is named explicitly.
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?
Usage is implied rather than stated: it is obviously the lookup-by-id companion to search_jobs, but the description never says when to prefer this tool over searching or listing, nor any prerequisites or rate considerations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List job position/category slugs usable as category in search_jobs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the useful behavioral fact that the returned values are slugs intended for reuse as a filter argument, not display labels. No contradictions.
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?
A single sentence with no filler; the resource comes first and the intended downstream use is attached immediately. Every clause earns its place.
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?
For a parameterless lookup whose output schema defines the return shape, the description supplies everything needed: what it returns and how to use it. Nothing an agent needs to call it correctly is missing.
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?
The tool takes zero parameters, so the baseline is 4. The description does add value by naming the consumer parameter (`category` in search_jobs) that the returned slugs are valid for, which is information the empty schema cannot convey.
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?
States a specific verb and resource ('List job position/category slugs') and names exactly what the output is meant to feed ('category in search_jobs'), which separates it cleanly from siblings like search_jobs, list_locations, and company_jobs.
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 makes the usage context explicit by tying the slugs to the `category` parameter of search_jobs, implying this is a prerequisite lookup before searching. It stops short of an explicit when/when-not or naming an alternative source of categories, so it is clear but not fully prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List location slugs (regions and cities) usable as location in search_jobs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and scope profile is covered. The description adds the useful note that values are slugs of regions and cities, but says nothing about ordering, pagination, or freshness of the list — enough for a 3 given annotations carry the heavier burden.
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?
A single front-loaded sentence with no filler; the resource is named first and the downstream usage second. Every clause earns its place.
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?
For a trivial zero-parameter lookup with an output schema present, the description need not explain return structure. It says what the tool yields and how the values are consumed, which is everything an agent needs to call it correctly.
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?
The tool takes zero parameters, so per the baseline this starts at 4. The description goes slightly beyond by explaining what the returned values mean (slugs usable as `location`), which is the only semantic information a zero-arg tool can carry.
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?
States a specific verb (List) and resource (location slugs), and clarifies the domain as regions and cities. It also distinguishes itself from siblings by naming the exact consuming parameter (`location` in search_jobs), so an agent can tell what this tool exists for without opening a schema.
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 reference to `location` in search_jobs gives clear implied context: call this to obtain valid values before invoking search_jobs. It stops short of an explicit when/when-not or naming alternatives, but the routing intent is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Collect many search results at once (optionally with full details for each).
Same filters as search_jobs. Requests are rate-limited (about 1/second), so large jobs are slow on purpose; hard caps: 5 pages and 25 detail pages per call.
Args:
max_pages: Result pages to fetch (1-5, 20 offers per page).
include_details: Also fetch the full offer page for the first max_details jobs.
max_details: How many offers to fetch details for (1-25).
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| remote | No | ||
| category | No | ||
| location | No | ||
| max_pages | No | ||
| salary_min | No | ||
| max_details | No | ||
| salary_period | No | m | |
| include_details | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly and openWorld, so the bar is lower, and the description adds genuine operational detail: ~1 request/second rate limiting, intentional slowness on large jobs, and hard caps of 5 pages and 25 detail pages. It does not describe how partial failures or truncation are reported.
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?
Front-loads the one-line purpose, then operational constraints, then a clean Args block. Every sentence carries information; the Args repetition of values also present in the schema is the only mild redundancy.
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?
With an output schema present, return values need no explanation, and the description covers the behaviorally risky aspects (rate limits, caps, detail fetching). The remaining incompleteness is the undocumented filter parameters, largely papered over by the search_jobs reference.
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 0% and six of nine parameters (query, remote, category, location, salary_min, salary_period) are documented only implicitly via 'same filters as search_jobs'. The three documented parameters get useful semantics (1-5 pages at 20 offers each, 1-25 detail pages), which partly compensates but leaves a substantial gap.
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?
States a specific verb and resource ('Collect many search results at once') with the optional details qualifier, and references the sibling search_jobs to anchor the filter set. It distinguishes itself as the bulk/aggregating variant, though it never explicitly contrasts with search_jobs beyond 'same filters'.
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?
'Same filters as search_jobs' tells the agent this is an alternative route and implies shared semantics, and the rate-limit/cap notes give clear operational context for when this tool is viable. No explicit when-not-to-use statement, but the bulk framing makes the intended use case obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Profesia.sk job offers (20 per page).
Args:
query: Free-text keywords, e.g. "python developer".
location: Location slug from list_locations, e.g. "bratislava", "kosice", "bratislavsky-kraj".
category: Job category slug from list_job_categories, e.g. "java-programator-programatorka".
Only one of location / category can be used; put the other in query.
salary_min: Minimum salary (EUR) - per month when salary_period="m", per hour when "h".
salary_period: "m" monthly or "h" hourly.
remote: "onsite" (workplace only), "remote" (home only) or "hybrid" (partly from home).
page: Page number, starting at 1.
Returns jobs (id, title, employer, location, salary, labels, posted, url) and has_next. Pass a job id or url to get_job for the full description.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| query | No | ||
| remote | No | ||
| category | No | ||
| location | No | ||
| salary_min | No | ||
| salary_period | No | m |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context beyond annotations: 20 results per page, pagination support via page, a has_next indicator, and the shape of returned job fields.
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 front-loaded with the tool purpose, followed by a clean Args section and a brief return/next-step note. Every sentence adds actionable information with no redundant restatement of the name or schema.
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?
For a seven-parameter, zero-description-coverage search tool, the definition is complete enough to invoke correctly. It covers pagination, filtering constraints, slug sourcing, salary units, remote modes, and where to go for job details, despite an output schema also being present.
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 description coverage is 0%, so the description carries the full burden and does so thoroughly. It documents all seven parameters with examples, slug sources, units, enum meanings, defaults, and the mutual-exclusion rule between location and category.
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?
States a specific verb and resource: search Profesia.sk job offers, with the page size disclosed. It clearly separates itself from get_job by noting that detailed descriptions require that sibling, and it references list_locations and list_job_categories for slug inputs.
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?
Gives strong contextual guidance: location and category must come from list_locations and list_job_categories, only one of location/category can be used, and get_job should be used for full descriptions. It does not explicitly state when to prefer search_jobs over scrape_jobs or company_jobs, but the primary routing guidance is clear.
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.
v0.1.0company_jobsget_application_infoget_joblist_job_categorieslist_locationsscrape_jobssearch_jobsScored across 7 tools
Most tools have clearly distinct purposes: search_jobs finds listings, get_job fetches one offer, get_application_info explains how to apply, company_jobs lists an employer's openings, and the list_* tools provide filter slugs. search_jobs and scrape_jobs overlap in filtering, but scrape_jobs is clearly distinguished as a bulk/detail-collection tool with rate limits and caps.
The set mostly follows a consistent verb_noun snake_case pattern: get_job, search_jobs, get_application_info, list_locations, scrape_jobs, list_job_categories. company_jobs is a minor deviation because it omits the verb and breaks the list_* pattern used by the other listing tools.
Seven tools is well-scoped for a job-search server: search, detail, application guidance, company listings, bulk scraping, and two reference-list tools. Each tool earns its place without obvious redundancy or thin coverage.
The surface covers the core job-discovery lifecycle: find jobs, inspect details, identify filter options, explore employer listings, and learn how to apply. Minor gaps exist, such as no dedicated salary/statistics or saved-search/alert tooling, but agents can work around these for the stated purpose.
Public MCP server for discovering open jobs. Search, filter, and get application links.
GetJobzi MCP server for job search, application tracking, and career forecasting.
Read-only MCP server for public WeJob jobs, formations, and companies.
