jopp

Search jobs in Switzerland

search_jobs

Read-onlyIdempotent

Search open jobs in Switzerland and Liechtenstein by keywords and filters. Only jobs whose advert is still online are returned. Lehrstellen are listed only with segment apprenticeships. Returns up to 20 jobs per page, newest first for filter-only searches; keyword searches rank by relevance, favouring recent adverts and mixing companies. Use get_job for a job's full description.

Input Schema

Name	Required	Description	Default
`role`	No	A role key from list_categories; requires its category.
`limit`	No
`query`	No	Keywords matched against job title, company and description, with German word forms (e.g. "Pflegefachfrau", "Software Engineer Python"). All words must match; use OR between alternatives, "quotes" for phrases and -word to exclude. Place names match only the text; use cantons to filter by location.
`cursor`	No	nextCursor of a previous search_jobs result; the other arguments are then ignored.
`cantons`	No	Two-letter canton codes (ZH, BE, VD, GE, …) or LI for Liechtenstein.
`segment`	No	jobs (default): regular jobs and internships. apprenticeships: only Lehrstellen (Swiss vocational apprenticeships, Berufslehre). A search lists one of the two, never both.	jobs
`category`	No	A category key from list_categories.
`workModes`	No
`seniorities`	No
`workloadMax`	No	Highest workload in percent of full time (10–100).
`workloadMin`	No	Lowest workload in percent of full time (10–100).
`salaryStated`	No	Only jobs whose advert states a salary.
`contractTypes`	No	Not for segment apprenticeships.
`advertLanguages`	No	Language the advert is written in.
`excludeAgencies`	No	Leave out recruitment agencies.
`requiredLanguages`	No	Only jobs that require all of these languages.
`publishedWithinDays`	No

Output Schema

Name	Required	Description
`total`	Yes	How many open jobs match.
`results`	Yes
`searchUrl`	Yes	The same search on jopp.ai.
`nextCursor`	Yes	Pass as cursor for the next page; null at the end.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 17, 2026

addedInput schema / properties / contractTypes / description
```
Added value: +"Not for segment apprenticeships."
```

changedInput schema / properties / contractTypes / items / enum

Previous value: -[
-  "permanent",
-  "temporary",
-  "internship",
-  "apprenticeship",
-  "freelance"
-]New value: +[
+  "permanent",
+  "temporary",
+  "internship",
+  "freelance"
+]

addedInput schema / properties / segment

Added value: +{
+  "default": "jobs",
+  "description": "jobs (default): regular jobs and internships. apprenticeships: only Lehrstellen (Swiss vocational apprenticeships, Berufslehre). A search lists one of the two, never both.",
+  "enum": [
+    "jobs",
+    "apprenticeships"
+  ],
+  "type": "string"
+}

Changed2 schema fields changedOct 12, 2026
- changedOutput schema / properties / results / items / properties / url / description
```
Previous value: -"The job on getjopp.app."New value: +"The job on jopp.ai."
```
- changedOutput schema / properties / searchUrl / description
```
Previous value: -"The same search on getjopp.app."New value: +"The same search on jopp.ai."
```
First observedOct 3, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real behavioural context beyond them: only still-online adverts are returned, results are capped at 20 per page, filter-only searches are newest-first while keyword searches are relevance-ranked with recency bias and company mixing. It stops short of describing pagination termination or any 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?

Four compact sentences, front-loaded with scope and the online-only constraint, then ranking behaviour, then the sibling hand-off. Every sentence carries distinct information with no filler.

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?

With an output schema present, return-shape explanation is unnecessary, and the description covers the non-obvious constraints an agent needs (online-only, segment exclusivity, page cap, ranking differences). For a 17-parameter tool it could have hinted at how cursor paging terminates, but coverage is strong overall.

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

Parameters3/5

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

Schema description coverage is 76% and the schema itself carries detailed semantics (query syntax, OR/quotes/exclusion, role-requires-category, cursor overriding other args). The description largely restates the segment constraint and the 20-per-page limit rather than adding new meaning, so the baseline 3 applies.

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

Purpose5/5

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

States a specific verb and resource (search open jobs) plus the geographic scope (Switzerland and Liechtenstein) and the filter/keyword duality. It also explicitly routes full-description lookups to the sibling get_job, so an agent can distinguish it from neighbours 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.

Usage Guidelines4/5

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

Gives clear context for when this tool applies (open adverts only, keyword vs filter mode) and names the alternative for detail retrieval ('Use get_job for a job's full description'). It does not, however, say when to prefer list_categories to discover role/category keys, which the schema requires as inputs.

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

All jopp tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?