Open physiotherapy jobs in Germany from practice careers pages, with 60-second apply links.
Scored across 3 tools
Each tool has a clearly distinct role: search_jobs finds positions, get_job retrieves one posting, and get_employer retrieves an employer with its open positions. The descriptions explicitly connect them by telling agents to use IDs from search_jobs, leaving little room for misselection.
All names follow a consistent snake_case verb_noun pattern: search_jobs, get_job, get_employer. The convention is predictable and readable throughout.
Three tools are well-scoped for a focused job-search server: search, job detail, and employer detail. Each earns its place without redundant operations, and the surface stays simple for agents to navigate.
The core read-only workflow is covered: search jobs, view a job, and view an employer. Minor gaps exist around in-server application submission or broader employer discovery, but the application link and optional unfiltered search let agents work around these.
Everything about one employer as schema.org JSON-LD: the employer, its page and all open positions. Use employer_slug from search_jobs.
| Name | Required | Description | Default |
|---|---|---|---|
| employer_slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds what the payload actually contains (employer record, page, open positions) and its serialization as schema.org JSON-LD. That is meaningful behavioral context beyond the annotations, though pagination or failure behavior remains unstated.
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?
Two short sentences with zero padding; the payload scope is front-loaded and the parameter-provenance hint follows. 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?
With no output schema, the description correctly takes on the job of describing return contents and format, which it does well for a simple single-parameter lookup. It stops short of covering large-result handling (e.g., whether all open positions are returned in one payload).
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 single parameter carries no inline documentation. The description partially compensates by identifying employer_slug as coming from search_jobs, but adds no format, casing, or validation 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?
The description names a specific verb and resource ('Everything about one employer') and enumerates the returned scope: the employer, its page, and all open positions. It implicitly distinguishes itself from get_job by being employer-centric, though it never explicitly contrasts with that sibling.
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?
'Use employer_slug from search_jobs' establishes a clear prerequisite workflow (find slug via search, then fetch), which is real usage guidance. However, there is no instruction about when to prefer get_job instead, or what to do if the slug is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One position as schema.org JobPosting with tasks, requirements, benefits and the application link. Use employer_slug and job_id from search_jobs.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| employer_slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that the payload is shaped as a schema.org JobPosting with specific sections, which is useful given there's no output schema, but it says nothing about failure behavior, missing fields, or response size.
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?
Two short sentences with the return content first and the input sourcing second; nothing is padded and no sentence is redundant.
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 simple read-only tool with two required identifiers and no output schema, the description covers the resource, the return structure, and how to obtain the inputs. Only edge cases such as invalid ids or partial postings are unaddressed, which is a minor gap at this complexity.
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%, so the schema documents nothing about the two required parameters. The description compensates partially by stating both come from search_jobs, establishing they are identifiers produced by another tool, but it gives no format, casing, or validity constraints for either value.
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 states a specific retrieval of 'one position as schema.org JobPosting' and enumerates the returned content (tasks, requirements, benefits, application link), which clearly distinguishes it from the plural search_jobs and from get_employer. It doesn't explicitly name those siblings, but the singular-vs-search framing makes the distinction inferable.
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?
'Use employer_slug and job_id from search_jobs' tells the agent this is a follow-up call whose inputs come from a prior search, which is real when-to-use guidance. There are no exclusions or error-case guidance (e.g., what happens for a nonexistent job), so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search open positions. All filters are optional and combined with AND. Returns title, employer, location, hours, salary if published, and links to the job page and the 60-second application (no CV needed).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | Words from the job title or employer, German or English, e.g. 'Physiotherapeut' or 'physiotherapist' | |
| location | No | City or part of the address, e.g. 'Düsseldorf' | |
| employment_type | No | OTHER = apprenticeship |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that: it enumerates exactly which fields come back, flags that salary only appears "if published," and notes the application link is a 60-second process needing no CV — details an agent could not infer from structured 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?
Three tight sentences: what it does, how filters behave, then what comes back. The return information is front-loaded where an agent needs it and there is no filler or repetition of the 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?
With no output schema, the description properly takes on the job of describing return fields and their conditionality, and it covers the filter-combination semantics. Minor gaps remain around result limits and ordering, which matter for a search tool capped at 50 results.
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 75% and the three documented parameters already carry examples and the OTHER=apprenticeship mapping. The description contributes the AND-combination semantics of the filters, which is a meaningful addition, but says nothing about limit or pagination behavior, so it does not fully compensate for the one undocumented 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?
"Search open positions" gives a specific verb and resource, and the return summary makes clear it is a search/list operation rather than a single-record lookup. It does not explicitly name get_job or get_employer as the alternatives for retrieving one specific posting, so the sibling distinction is only implied.
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?
"All filters are optional and combined with AND" is genuinely useful guidance about how to compose a query, and it implies the tool works with any subset of filters. However, there is no statement about when to use this versus get_job/get_employer, nor any note on result-set behavior when filters are broad.
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.
get_employerget_jobsearch_jobsPhysiotherapy, occupational and speech therapy jobs in Germany, with one-minute application links.
Jobs, salaries, net pay and labour-market data for Germany from the JobJump job board.
Jobs in Germany, Austria and Switzerland matched to your resume.
Jobs from 10,000+ company career sites, Germany's Arbeitsagentur, Wellfound startups; EU suppliers.
Add one secure layer between your agents and this server.