JobCrawls
Server Details
Search jobs in Finland and calculate net salary. Read-only, no login. English, Finnish, Swedish.
- Status
- Healthy
- Uptime
- 100.0% over 24 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- ChatGPT
- –
- Claude
- –
TDQS
Scored across 4 tools
Each tool targets a clearly distinct purpose: searching listings (search_jobs), retrieving one listing's full text (get_job_details), discovering valid filter facets (list_job_filters) and an unrelated salary calculator (calculate_net_salary_finland). Descriptions explicitly cross-reference each other (filter values come from list_job_filters, full text from get_job_details), so an agent can route queries unambiguously.
All four names follow a consistent snake_case verb_noun pattern: search_jobs, get_job_details, list_job_filters, calculate_net_salary_finland. Verb choice matches the operation type (search/get/list/calculate) with no mixing of conventions.
Four tools is lean but adequate for a read-only job aggregator: search, detail, filter discovery and one auxiliary calculator. It is slightly on the thin side (no company or saved-search tools), but each tool earns its place with no redundancy.
The core job-search workflow is fully covered end to end: discover facets, search, then fetch full details, plus a salary-net calculator that complements the domain. Minor gaps exist (no company/employer lookup, related-jobs, or saved-search operations), but agents can work around them.
Available Tools
4 toolscalculate_net_salary_finlandCalculate net salary in Finland (gross to net, employer cost)ARead-onlyIdempotentInspect
Gross-to-net salary calculator for Finland, from the JobCrawls tax iceberg calculator. Example queries: "what is 4000 gross net in Finland", "paljonko jää käteen 4200 euron bruttopalkasta Helsingissä", "vad blir nettolönen på 3800 brutto i Helsingfors". Inputs: a gross salary (EUR per month by default, or per year), or a target net to solve the gross it takes, and optionally the municipality, employer size, age, dependent children, commuting costs and investment income. Church membership and union fees are not inputs. The linked page is in the language detected from "municipality" when locale is omitted, else English, or in the given locale. Returns monthly and annual breakdowns: employee pension and unemployment contributions, state, municipal, church and Yle taxes, net pay, employer contributions and the true cost of employment, plus the effective tax rate, the assumptions used and a link to the same scenario on jobcrawls.com. Uses the current tax year's official Finnish parameters; an estimate, not tax advice. Reuse: figures may be quoted with a visible link to the jobcrawls.com page in the result (or "JobCrawls (jobcrawls.com)" where a link is impossible); each result repeats this in dataUse.
| Name | Required | Description | Default |
|---|---|---|---|
| age | No | Age in years, affects pension and unemployment contributions. | |
| net | No | Target net pay in euros (same period): the tool solves the gross salary that leaves this in hand. Either gross or net is required. | |
| gross | No | Gross salary in euros, per month unless period is "year". Either gross or net is required. | |
| locale | No | Language of the user's message (fi for Finnish, sv for Swedish, en for English or any other language), including when job titles or place names in it are English. Language of the result notes, the inline card and the linked page. When omitted, detected from "municipality" if it is given in Finnish or Swedish form; otherwise defaults to en. | |
| period | No | Period of every money amount given. Default month. | |
| dividends | No | Listed-company dividends in the same period (capital income). | |
| includeVat | No | Also subtract the VAT paid when the net is spent (an estimate). Default false. | |
| capitalGains | No | Capital gains net of acquisition cost in the same period. | |
| employerSize | No | Employer payroll size for the unemployment-insurance rate (large = payroll above about EUR 2.5 million). Omit for a blended average. | |
| municipality | No | Finnish municipality, by its Finnish or Swedish name, e.g. "Helsinki", "Helsingfors" or "Espoo". Omit for the national-average municipal tax rate. | |
| commutingCosts | No | Commuting costs in the same period; deductible above the own-liability share, capped. | |
| isSoleGuardian | No | Single parent with dependent children (child deduction). | |
| dependentChildren | No | Number of dependent children, affects the child tax deduction. | |
| unlistedDividends | No | Dividends from the person's own unlisted company in the same period (8% yield rule). | |
| unlistedNetAssets | No | Mathematical value of the person's shares in that company, EUR (a stock, not per period). |
Output Schema
| Name | Required | Description |
|---|---|---|
| input | Yes | The inputs the calculation used, after defaults. |
| rates | Yes | |
| annual | Yes | Breakdown per year, EUR. |
| locale | Yes | |
| method | Yes | |
| monthly | Yes | Breakdown per month, EUR. |
| pageUrl | Yes | The same scenario on jobcrawls.com, where church tax and union fees can be set privately. |
| taxYear | Yes | |
| currency | Yes | |
| assumptions | Yes | |
| investments | Yes | Capital income breakdown, or null when no investment income was given. |
| destinations | Yes | Where the taxes and contributions go, EUR per year. |
| icebergSvgUrl | Yes | Image illustrating the breakdown. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds real value beyond that: it discloses the estimate caveat ('an estimate, not tax advice'), that parameters are the current tax year's official figures, the return contents (breakdowns, assumptions), and reuse/licensing terms repeated in dataUse.
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 with purpose, then examples, inputs, outputs, and terms in a logical order. It is long but dense, and the length is justified by 15 parameters and a licensing requirement; a few clauses (e.g. the reuse sentence) could be tightened.
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 complex 15-parameter calculator with an output schema, the description covers purpose, inputs, defaults, return contents, assumptions, and legal reuse terms. Nothing an agent needs to invoke 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?
Schema coverage is 100%, so the baseline is 3 and the schema carries most burden. The description still adds meaning: it summarizes the key inputs, flags the per-month-by-default or per-year period behavior, and explicitly states what is NOT an input (church membership, union fees), which the schema cannot express.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('Gross-to-net salary calculator for Finland') and immediately scopes the domain, so an agent can distinguish it from the sibling job-search tools without any schema inspection. Example queries reinforce the exact intent in three languages.
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?
It gives concrete example queries and clarifies that the tool accepts a gross salary OR a target net to solve for gross, which is clear usage context. It also notes scope exclusions ('church membership and union fees are not inputs'), but it never explicitly states when to avoid the tool or name an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_job_detailsGet full job listing detailsARead-onlyIdempotentInspect
Returns the complete details of one JobCrawls listing by its id (the id field of a search_jobs result): full description, requirements, responsibilities, benefits, salary, company, location, application deadline and a direct link to the posting. Listings sourced from Job Market Finland (Työmarkkinatori) have isTyomarkkinatori: true and include a dataSource attribution required by Job Market Finland's terms of use. Reuse: figures may be quoted with a visible link to the jobcrawls.com page in the result (or "JobCrawls (jobcrawls.com)" where a link is impossible); each result repeats this in dataUse.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | The listing id (the `id` field returned by search_jobs). Required. | |
| locale | No | Language of the user's message (fi for Finnish, sv for Swedish, en for English or any other language), including when job titles or place names in it are English. Language to return the listing content in: en = English, fi = Finnish, sv = Swedish, normally the locale of the search the id came from. This call has no query text to detect language from, so it defaults to en when omitted. If the listing is not available in that language the connector falls back to whichever language it exists in. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | Direct link to the individual posting on jobcrawls.com (or the source posting). |
| field | Yes | |
| title | Yes | |
| locale | Yes | Language index the listing was found in. |
| salary | Yes | Advertised salary range, or null when the listing states none. |
| skills | Yes | |
| company | Yes | |
| jobType | Yes | |
| logoUrl | Yes | |
| benefits | Yes | |
| isActive | Yes | |
| location | Yes | One location, or several for multi-location listings. |
| roleLevel | Yes | |
| brandColor | Yes | |
| companyUrl | Yes | |
| dataSource | No | Present only when isTyomarkkinatori is true. Attribution required alongside the listing by Job Market Finland's terms of use. |
| postedDate | Yes | YYYY-MM-DD. |
| remoteness | Yes | |
| description | Yes | |
| marketSalary | Yes | What the role pays in the market (gross EUR per month, the JobCrawls salary pages figures), only next to an employer-stated salary; null otherwise. |
| requirements | Yes | |
| employerGrade | Yes | JobCrawls Employer Score as a letter grade (A best), or null when the employer is not scored. |
| educationLevel | Yes | |
| responsibilities | Yes | |
| salaryIsEstimate | Yes | True when `salary` is a JobCrawls market-based estimate rather than stated by the employer. |
| isTyomarkkinatori | Yes | True when the listing is sourced from Job Market Finland (Työmarkkinatori). |
| languagesRequired | Yes | |
| applicationDeadline | Yes | YYYY-MM-DD, or null when none is stated. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds genuinely non-structured behavior: Job Market Finland data carries isTyomarkkinatori plus a mandatory dataSource attribution, results repeat reuse terms in dataUse, and locale falls back to another language when the listing is unavailable. It does not mention error behavior for a bad/expired id, which is the remaining gap.
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?
Purpose and id source are front-loaded in the first clause, and the licensing/attribution sentences earn their place because they impose an obligation on the agent. The enumerated field list (description, requirements, responsibilities, benefits, salary, ...) partially duplicates the output schema, which is the only real padding.
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?
An output schema exists so return values need not be explained, and the description nonetheless covers the two things structured data cannot convey: the source of the required id and the attribution/reuse obligations attached to the results. Only edge-case behavior (invalid id, listing removed) is absent, which is minor for a read-only lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are fully documented in the schema, so the baseline is 3. The description only restates that jobId is a search_jobs `id` and echoes the locale fallback rule already present in the schema; it adds no format or constraint detail beyond that.
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 ('Returns the complete details of one JobCrawls listing by its id') and immediately disambiguates from the sibling search_jobs by stating the id comes from that tool's results. An agent can distinguish this detail-fetch tool from calculate_net_salary_finland, list_job_filters and search_jobs 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?
States the precondition for calling it (you need an id, which is 'the `id` field of a search_jobs result'), which effectively routes the agent through search_jobs first, and the locale guidance ('normally the locale of the search the id came from') tells the agent how to fill the optional argument. It stops short of an explicit when-not/exclusion statement, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_job_filtersList available job filters and valuesARead-onlyIdempotentInspect
Returns the facet attributes jobs can be filtered by (for example field, location, job type, seniority level, skills and languages), with the values currently present in active listings and how many listings have each value. The values are the exact strings search_jobs accepts in its filters parameter for the same locale. An optional query scopes the values to matching listings. Values are in the language of that query when locale is omitted, or in the given locale. Reuse: figures may be quoted with a visible link to the jobcrawls.com page in the result (or "JobCrawls (jobcrawls.com)" where a link is impossible); each result repeats this in dataUse.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Optional free-text query to scope the facet values to a subset of listings (e.g. only the facets present in "nurse" jobs). Leave empty for the whole active index. | |
| locale | No | Language of the user's message (fi for Finnish, sv for Swedish, en for English or any other language), including when job titles or place names in it are English. Language index whose facet values to return: en = English, fi = Finnish, sv = Swedish. When omitted, the language of "query" (detected from it) is used. Values are localized and match search_jobs "filters" verbatim under the same locale. |
Output Schema
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| facets | Yes | Values to pass verbatim in search_jobs "filters" with the same locale. |
| locale | Yes | |
| booleanFilters | Yes | Boolean search_jobs parameters and what they do. |
| numericFilters | Yes | Numeric search_jobs parameters and what they do. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: values are localized and will differ by locale, omitting locale derives language from `query`, and there is a reuse/attribution obligation mirrored in each result's dataUse field. It stops short of describing pagination or volume of returned facets.
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 core purpose is front-loaded in the first sentence, followed by the search_jobs linkage and locale rules. It is slightly long, with the reuse/attribution sentence carrying administrative rather than selection-relevant weight, but every sentence is informative and none is redundant 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?
With an output schema present, the description need not spell out return values, and it still notes that counts and dataUse appear in results. Together with the schema and read-only annotations, an agent has enough to select and call it correctly; only minor gaps remain around result volume and facet ordering.
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 100%, so both parameters are already documented in-schema, giving a baseline of 3. The description reinforces the query-scoping and localization behavior (query language as fallback for locale) but mostly restates what the schema's own parameter descriptions already say, adding no new syntax or format detail.
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?
Specific verb+resource: returns the facet attributes jobs can be filtered by, with concrete examples (field, location, job type, seniority, skills, languages) and value counts. It explicitly ties itself to the sibling tool by stating the values are the exact strings search_jobs accepts in its `filters` parameter, so an agent can distinguish it from search_jobs without opening either 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 description makes the usage context clear: this supplies the valid filter values that search_jobs consumes, and the optional `query` scopes values to a subset of listings. It states the locale/query-language interaction for choosing what to pass, but never explicitly frames a when-not-to-use case or a recommended call order relative to search_jobs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_jobsSearch Finnish job listingsARead-onlyIdempotentInspect
Searches active job listings on JobCrawls, an aggregator of jobs in Finland. The index covers jobs located in Finland plus remote roles open to Finland, and has no listings for other countries. Example queries: "find nurse jobs in Tampere", "onko Helsingissä avoimia etätyöpaikkoja ohjelmistokehittäjälle", "finns det lediga jobb som sjukskötare i Åbo". Inputs: a free-text query, facet filters (field, location, job type, seniority, skills, languages, industry, education and more), a remote-only flag, a salary floor, sort order and paging. Results, filter values and job text are in the language of the query when locale is omitted, or in the given locale. Output: a paginated list, each result with title, company, location, remoteness, salary range when known and a direct link to the posting. Valid filter values come from list_job_filters; the full text of a result comes from get_job_details. Listings sourced from Job Market Finland (Työmarkkinatori) have isTyomarkkinatori: true and include a dataSource attribution required by Job Market Finland's terms of use. Reuse: figures may be quoted with a visible link to the jobcrawls.com page in the result (or "JobCrawls (jobcrawls.com)" where a link is impossible); each result repeats this in dataUse.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, starting at 1. Default: 1. | |
| sort | No | Ordering: relevance (default), date (newest first), or salary (highest minimum first). | |
| limit | No | Results per page (1–20). Default: 10. | |
| query | No | Free-text search across job title, description, skills, company, and location. Example: "senior software engineer". Leave empty to browse the newest listings. | |
| locale | No | Language of the user's message (fi for Finnish, sv for Swedish, en for English or any other language), including when job titles or place names in it are English. Language index to search: en = English, fi = Finnish, sv = Swedish. When omitted, results, filter values and job text come back in the language of "query" (detected from it); pass locale explicitly to override. Listing content AND filter values are localized per language, so filter values from list_job_filters match only under the same locale. "fi" has the broadest coverage of jobs in Finland. | |
| filters | No | Facet filters keyed by attribute, each an array of allowed values (values within one attribute are OR-combined; different attributes are AND-combined). Allowed keys: field, normalisedTitle, normalisedRoleLevel, location, companyIndustry, companyId, jobType, requiredLanguages, optionalLanguages, benefits, skillsAndTechnologies, educationLevel, peopleManagementTier, remoteness, regionTags. Values are case-sensitive and language-specific: they match only in the locale index list_job_filters returned them for (for example field is "Software Engineering" in en but its Finnish equivalent in fi). Example (en): { "field": ["Software Engineering"], "location": ["Helsinki, Finland"] }. regionTags takes the `placeId` of an entry in a previous result's `regions` (a Finnish region). | |
| minSalary | No | Only listings whose minimum salary is at least this amount (listing currency, usually EUR). | |
| titleOnly | No | Match `query` against job titles only, not descriptions or skills, which counts ads that are for a role ("product manager" ads, not ads that mention products and managers). Default: false. | |
| remoteOnly | No | Shortcut for only fully remote positions (remoteness = Remote). | |
| includeFacets | No | When true, also return the facet values and counts for the current result set, plus `regions` (job counts per Finnish region). Default: false. | |
| excludeFilters | No | Negative facet filters keyed by attribute, same shape as `filters` but EXCLUDES listings matching any of the given values instead of requiring them, for jobs that do not have a given attribute value. Allowed keys: field, normalisedTitle, normalisedRoleLevel, location, companyIndustry, companyId, jobType, requiredLanguages, optionalLanguages, benefits, skillsAndTechnologies, educationLevel, peopleManagementTier, remoteness, regionTags. Same locale rules as `filters` apply. Example (en): { "requiredLanguages": ["Finnish"] } returns jobs that do not require Finnish. A key present in both `filters` and `excludeFilters` is invalid. |
Output Schema
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| query | Yes | The free-text query used, or null when browsing without one. |
| facets | No | Present only when includeFacets was true. |
| locale | Yes | Language index that was searched. |
| hasMore | Yes | True when a further page exists. |
| regions | No | Present only when includeFacets was true: job counts per Finnish region (maakunta), largest first. Pass `placeId` in filters.regionTags to narrow to one region. |
| results | Yes | |
| pageSize | Yes | |
| returned | Yes | Number of results in this page. |
| totalFound | Yes | Total matching active listings. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, but the description adds genuinely new behavioral context: geographic coverage limits, the isTyomarkkinatori flag with its required dataSource attribution, the dataUse reuse terms, and localized output/filter-value coupling. These are obligations an agent could not infer from annotations or schema.
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?
Purpose and scope are front-loaded and every section (inputs, output, sourcing, reuse) carries information. It is a dense single paragraph, though, and the three multilingual example queries plus the reuse-terms sentence add bulk that could be trimmed without loss.
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 complex 11-parameter, nested-object search tool, the description covers scope, localization, filtering entry point, output shape (even though an output schema exists) and licensing obligations. 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?
Schema description coverage is 100%, so the schema already documents all 11 parameters, including filters, excludeFilters, locale and regionTags. The description only summarizes the input groups at a high level, adding no syntax or format detail beyond what the schema states, so baseline 3 is appropriate.
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 (searches active job listings) plus the exact scope: jobs in Finland plus remote roles open to Finland, with no other countries. It also differentiates itself from siblings by naming list_job_filters and get_job_details, so an agent can place it precisely.
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?
Routes the agent explicitly: valid filter values come from list_job_filters and full result text from get_job_details. It also clarifies locale-driven behavior (omit locale to match query language) and supplies concrete example queries in three languages, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- Changed
get_job_details2 fields changed- changed
Output schema / properties / marketSalary / anyOfPrevious value: -[ - { - "additionalProperties": true, - "properties": { - "currency": { - "type": "string" - }, - "median": { - "type": "number" - }, - "p25": { - "type": "number" - }, - "p75": { - "type": "number" - }, - "period": { - "type": "string" - }, - "sampleSize": { - "description": "Number of comparable postings the band is based on.", - "type": "number" - } - }, - "required": [ - "p25", - "median", - "p75", - "sampleSize", - "currency", - "period" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": true, + "properties": { + "currency": { + "type": "string" + }, + "median": { + "type": "number" + }, + "p25": { + "type": "number" + }, + "p75": { + "type": "number" + }, + "period": { + "type": "string" + }, + "sampleSize": { + "description": "Number of comparable postings the band is based on (with source statistics_finland: the ads behind the place and level differences).", + "type": "number" + }, + "source": { + "description": "statistics_finland: Statistics Finland earnings for the occupation raised to today, moved by job-ad differences (the JobCrawls salary pages figures). job_ads: stated pay in job ads.", + "enum": [ + "statistics_finland", + "job_ads" + ], + "type": "string" + } + }, + "required": [ + "p25", + "median", + "p75", + "sampleSize", + "currency", + "period" + ], + "type": "object" + }, + { + "type": "null" + } +] - changed
Output schema / properties / marketSalary / descriptionPrevious value: -"Market salary band (gross EUR per month) for comparable jobs, only next to an employer-stated salary; null otherwise."New value: +"What the role pays in the market (gross EUR per month, the JobCrawls salary pages figures), only next to an employer-stated salary; null otherwise."
- Changed
search_jobs2 fields changed- changed
Output schema / properties / results / items / properties / marketSalary / anyOfPrevious value: -[ - { - "additionalProperties": true, - "properties": { - "currency": { - "type": "string" - }, - "median": { - "type": "number" - }, - "p25": { - "type": "number" - }, - "p75": { - "type": "number" - }, - "period": { - "type": "string" - }, - "sampleSize": { - "description": "Number of comparable postings the band is based on.", - "type": "number" - } - }, - "required": [ - "p25", - "median", - "p75", - "sampleSize", - "currency", - "period" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": true, + "properties": { + "currency": { + "type": "string" + }, + "median": { + "type": "number" + }, + "p25": { + "type": "number" + }, + "p75": { + "type": "number" + }, + "period": { + "type": "string" + }, + "sampleSize": { + "description": "Number of comparable postings the band is based on (with source statistics_finland: the ads behind the place and level differences).", + "type": "number" + }, + "source": { + "description": "statistics_finland: Statistics Finland earnings for the occupation raised to today, moved by job-ad differences (the JobCrawls salary pages figures). job_ads: stated pay in job ads.", + "enum": [ + "statistics_finland", + "job_ads" + ], + "type": "string" + } + }, + "required": [ + "p25", + "median", + "p75", + "sampleSize", + "currency", + "period" + ], + "type": "object" + }, + { + "type": "null" + } +] - changed
Output schema / properties / results / items / properties / marketSalary / descriptionPrevious value: -"Market salary band (gross EUR per month) for comparable jobs, only next to an employer-stated salary; null otherwise."New value: +"What the role pays in the market (gross EUR per month, the JobCrawls salary pages figures), only next to an employer-stated salary; null otherwise."
1 tool update
- Changed
calculate_net_salary_finland1 field changed- changed
Input schema / properties / municipality / descriptionPrevious value: -"Finnish municipality name, e.g. \"Helsinki\" or \"Espoo\". Omit for the national-average municipal tax rate."New value: +"Finnish municipality, by its Finnish or Swedish name, e.g. \"Helsinki\", \"Helsingfors\" or \"Espoo\". Omit for the national-average municipal tax rate."
4 tool updates
- Changed
calculate_net_salary_finland3 fields changed- changed
Input schema / properties / gross / descriptionPrevious value: -"Gross salary in euros, per month unless period is \"year\". Give either gross or net."New value: +"Gross salary in euros, per month unless period is \"year\". Either gross or net is required." - changed
Input schema / properties / locale / descriptionPrevious value: -"Set this to the language of the user's message (fi for Finnish, sv for Swedish, en for English or any other language), even when the job titles or place names in it are English. Language of the result notes, the inline card and the linked page. When omitted, detected from \"municipality\" if it is given in Finnish or Swedish form; otherwise defaults to en."New value: +"Language of the user's message (fi for Finnish, sv for Swedish, en for English or any other language), including when job titles or place names in it are English. Language of the result notes, the inline card and the linked page. When omitted, detected from \"municipality\" if it is given in Finnish or Swedish form; otherwise defaults to en." - changed
Input schema / properties / net / descriptionPrevious value: -"Target net pay in euros (same period): the tool solves the gross salary that leaves this in hand. Give either gross or net."New value: +"Target net pay in euros (same period): the tool solves the gross salary that leaves this in hand. Either gross or net is required."
- Changed
get_job_details3 fields changed- changed
Input schema / properties / locale / descriptionPrevious value: -"Set this to the language of the user's message (fi for Finnish, sv for Swedish, en for English or any other language), even when the job titles or place names in it are English. Language to return the listing content in: en = English, fi = Finnish, sv = Swedish. Pass the same locale you searched in; this call has no query text to detect language from, so it defaults to en when omitted. If the listing is not available in that language the connector falls back to whichever language it exists in."New value: +"Language of the user's message (fi for Finnish, sv for Swedish, en for English or any other language), including when job titles or place names in it are English. Language to return the listing content in: en = English, fi = Finnish, sv = Swedish, normally the locale of the search the id came from. This call has no query text to detect language from, so it defaults to en when omitted. If the listing is not available in that language the connector falls back to whichever language it exists in." - changed
Output schema / properties / dataSource / descriptionPrevious value: -"Present only when isTyomarkkinatori is true. Attribution that MUST be shown alongside the listing, per Job Market Finland's terms of use."New value: +"Present only when isTyomarkkinatori is true. Attribution required alongside the listing by Job Market Finland's terms of use." - changed
Output schema / properties / salaryIsEstimate / descriptionPrevious value: -"True when `salary` is a JobCrawls market-based estimate rather than stated by the employer. Say so when presenting it."New value: +"True when `salary` is a JobCrawls market-based estimate rather than stated by the employer."
- Changed
list_job_filters1 field changed- changed
Input schema / properties / locale / descriptionPrevious value: -"Set this to the language of the user's message (fi for Finnish, sv for Swedish, en for English or any other language), even when the job titles or place names in it are English. Language index whose facet values to return: en = English, fi = Finnish, sv = Swedish. When omitted, the language of \"query\" (detected from it) is used; pass locale explicitly to override. Values are localized: use the SAME locale you will pass to search_jobs, then feed the returned values back into search_jobs \"filters\" verbatim."New value: +"Language of the user's message (fi for Finnish, sv for Swedish, en for English or any other language), including when job titles or place names in it are English. Language index whose facet values to return: en = English, fi = Finnish, sv = Swedish. When omitted, the language of \"query\" (detected from it) is used. Values are localized and match search_jobs \"filters\" verbatim under the same locale."
- Changed
search_jobs7 fields changed- changed
Input schema / properties / excludeFilters / descriptionPrevious value: -"Negative facet filters keyed by attribute, same shape as `filters` but EXCLUDES listings matching any of the given values instead of requiring them. Use this to ask for jobs that do NOT have a given attribute value. Allowed keys: field, normalisedTitle, normalisedRoleLevel, location, companyIndustry, companyId, jobType, requiredLanguages, optionalLanguages, benefits, skillsAndTechnologies, educationLevel, peopleManagementTier, remoteness, regionTags. Same locale rules as `filters` apply. Example (en): { \"requiredLanguages\": [\"Finnish\"] } returns jobs that do not require Finnish. A key present in both `filters` and `excludeFilters` is invalid."New value: +"Negative facet filters keyed by attribute, same shape as `filters` but EXCLUDES listings matching any of the given values instead of requiring them, for jobs that do not have a given attribute value. Allowed keys: field, normalisedTitle, normalisedRoleLevel, location, companyIndustry, companyId, jobType, requiredLanguages, optionalLanguages, benefits, skillsAndTechnologies, educationLevel, peopleManagementTier, remoteness, regionTags. Same locale rules as `filters` apply. Example (en): { \"requiredLanguages\": [\"Finnish\"] } returns jobs that do not require Finnish. A key present in both `filters` and `excludeFilters` is invalid." - changed
Input schema / properties / filters / descriptionPrevious value: -"Facet filters keyed by attribute, each an array of allowed values (values within one attribute are OR-combined; different attributes are AND-combined). Allowed keys: field, normalisedTitle, normalisedRoleLevel, location, companyIndustry, companyId, jobType, requiredLanguages, optionalLanguages, benefits, skillsAndTechnologies, educationLevel, peopleManagementTier, remoteness, regionTags. Values are case-sensitive, LANGUAGE-SPECIFIC, and must match the chosen locale index — call list_job_filters with the same locale first to discover the exact values (e.g. field is \"Software Engineering\" in en but its Finnish equivalent in fi). Example (en): { \"field\": [\"Software Engineering\"], \"location\": [\"Helsinki, Finland\"] }. regionTags takes the `placeId` of an entry in a previous result's `regions` (a Finnish region)."New value: +"Facet filters keyed by attribute, each an array of allowed values (values within one attribute are OR-combined; different attributes are AND-combined). Allowed keys: field, normalisedTitle, normalisedRoleLevel, location, companyIndustry, companyId, jobType, requiredLanguages, optionalLanguages, benefits, skillsAndTechnologies, educationLevel, peopleManagementTier, remoteness, regionTags. Values are case-sensitive and language-specific: they match only in the locale index list_job_filters returned them for (for example field is \"Software Engineering\" in en but its Finnish equivalent in fi). Example (en): { \"field\": [\"Software Engineering\"], \"location\": [\"Helsinki, Finland\"] }. regionTags takes the `placeId` of an entry in a previous result's `regions` (a Finnish region)." - changed
Input schema / properties / includeFacets / descriptionPrevious value: -"When true, also return the facet values and counts for the current result set, plus `regions` (job counts per Finnish region), so you can refine the search. Default: false."New value: +"When true, also return the facet values and counts for the current result set, plus `regions` (job counts per Finnish region). Default: false." - changed
Input schema / properties / locale / descriptionPrevious value: -"Set this to the language of the user's message (fi for Finnish, sv for Swedish, en for English or any other language), even when the job titles or place names in it are English. Language index to search: en = English, fi = Finnish, sv = Swedish. When omitted, results, filter values and job text come back in the language of \"query\" (detected from it); pass locale explicitly to override. Listing content AND filter values are localized per language, so keep this consistent with the locale used for list_job_filters. Prefer \"fi\" for the broadest coverage of jobs in Finland."New value: +"Language of the user's message (fi for Finnish, sv for Swedish, en for English or any other language), including when job titles or place names in it are English. Language index to search: en = English, fi = Finnish, sv = Swedish. When omitted, results, filter values and job text come back in the language of \"query\" (detected from it); pass locale explicitly to override. Listing content AND filter values are localized per language, so filter values from list_job_filters match only under the same locale. \"fi\" has the broadest coverage of jobs in Finland." - changed
Input schema / properties / titleOnly / descriptionPrevious value: -"Match `query` against job titles only, not descriptions or skills. Use it to count ads that are for a role (\"product manager\" ads, not ads that mention products and managers). Default: false."New value: +"Match `query` against job titles only, not descriptions or skills, which counts ads that are for a role (\"product manager\" ads, not ads that mention products and managers). Default: false." - changed
Output schema / properties / results / items / properties / dataSource / descriptionPrevious value: -"Present only when isTyomarkkinatori is true. Attribution that MUST be shown alongside the listing, per Job Market Finland's terms of use."New value: +"Present only when isTyomarkkinatori is true. Attribution required alongside the listing by Job Market Finland's terms of use." - changed
Output schema / properties / results / items / properties / salaryIsEstimate / descriptionPrevious value: -"True when `salary` is a JobCrawls market-based estimate rather than stated by the employer. Say so when presenting it."New value: +"True when `salary` is a JobCrawls market-based estimate rather than stated by the employer."
1 tool update
- Changed
search_jobs1 field changed- added
Input schema / properties / titleOnlyAdded value: +{ + "description": "Match `query` against job titles only, not descriptions or skills. Use it to count ads that are for a role (\"product manager\" ads, not ads that mention products and managers). Default: false.", + "type": "boolean" +}
4 tool updates
- First observed
calculate_net_salary_finland - First observed
get_job_details - First observed
list_job_filters - First observed
search_jobs
Publisher details
- Operator
- TechTactics Oy · Publisher source
- Operator website
- https://www.jobcrawls.com
- Vendor relationship
- First-party
- Documentation
- https://www.jobcrawls.com/connector
- Trust center
- Not available
- Restrictions
- Not applicable
Related MCP Connectors
Search active job listings, salaries and employers in Norway (kollegia.no). Read-only, no login.
Read-only European tax, salary and benefit calculators with official sources and unknowns.
Search live job openings in many countries and languages, and read a full job ad.
Search 1.2M+ open jobs from 22k companies, read full listings and look up employers.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceSearch Statistics Finland's StatFin database (3,000+ tables), inspect table variables, and query clean flattened statistics on population, economy, labour and regions.7 npmMIT
- AlicenseNot gradedqualityDmaintenanceProvides access to the Finnish company registry (PRH/YTJ) to search for businesses and retrieve detailed information using Business IDs. It enables users to perform industry-specific searches and track recent company registrations through official government open data.6 npmMIT
- FlicenseNot gradedqualityDmaintenanceEnables querying real disclosed salary data across 20 regions, with tools to search jobs, retrieve salary statistics, and find similar roles.-
- AlicenseNot gradedqualityFmaintenanceVerified job search: every listing is opened and confirmed live and accepting applicants within the last 72 hours, and re-verified on a rolling clock, so agents can recommend jobs without ghost-job or dead-link risk. Read-only, no auth.MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.