Job & Stay

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

Annotations already cover the read-only, idempotent, closed-world safety profile, and the description adds genuinely non-obvious context: applying is free and goes directly to the employer, and the original ad source is included. It stops short of describing error behavior for unknown ids.

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 dense sentence that front-loads the key action and qualifying id before enumerating returns; nothing is wasted, though the return-field list makes it run on.

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 compensates by enumerating returned fields (pay, housing, meals, duration, apply link, source), which is exactly what an agent needs for a read tool. The unexplained 'language' parameter is the one remaining hole.

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. It gives a useful id format example ('f26') but never explains what the 'language' enum controls, and its list of link languages (10 codes) does not match the 18-value enum, which could mislead an agent.

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 one job listing by id'), scopes it to a single record with an example id format ('f26'), and enumerates the returned content, making it clearly distinct from search_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?

Usage is only implied by the 'by id' phrasing; the description never says when to prefer this over search_jobs or how it relates to apply_job/salary_info, and lists no exclusions.

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

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, and the description adds provenance (source and date) plus data composition (statutory/collective minimums plus median of current listings). It does not discuss rate limits, authentication, or result formatting, but those gaps are smaller given the annotations.

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 purpose is front-loaded, followed by a concrete usage trigger and activity vocabulary. It is compact but repeats some activity and country examples already present in the schema, so it is slightly less tight than a 5.

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 lookup with two parameters and no output schema, the description covers what data is returned, where the minimum ranges come from, and what the median component represents. It leaves gaps around optional activity behavior and exact output/currency format, but the agent has enough to invoke it in the main use case.

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 country and activity parameters are already documented. The description still adds useful domain semantics: activity is free text in many languages and covers kitchen, service, reception, housekeeping, and mountain hut rather than a fixed enum. It also reinforces the European-country scope beyond the country parameter's ISO/name examples.

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 resource: verified minimum pay ranges from collective agreements and statutory minimum wages, plus median pay of current Job & Stay listings. It makes the hospitality/European-country scope explicit, which clearly separates it from apply_job, get_job, and search_jobs. It does not name a sibling as an alternative, so it falls just short of 5.

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 an explicit trigger phrase ('Use when someone asks ...') and lists example roles and countries. It does not state when not to use the tool or name alternatives, so it meets the clear-context level but not full when/when-not guidance.

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

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. Beyond that, the description adds real value: it discloses that the search is free with no agency, that results include pay, housing type and cost, meals, couples, languages, duration, an apply link and a source, and that English-workable jobs are ranked first for non-supported languages. That return-shape and ranking behavior is not derivable from the 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?

The first two sentences are well front-loaded, but the remainder is a long multilingual keyword dump ('Job mit Unterkunft, Saisonjob, Personalzimmer...' across 13 languages) that is largely SEO-style padding and bloats the context. Much of it duplicates the schema's own examples and enum coverage, so most sentences after the first third do not earn their 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 an 11-parameter, zero-required search tool with no output schema, the description is largely sufficient: it explains what is searchable, that all filters are optional, and what each result contains. The gaps are minor – the contract and min_net_per_month_eur parameters are never mentioned, and there is no note on result volume beyond the limit parameter.

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 82%, so the baseline is 3; the description lifts this slightly by telling the agent to pass the user's raw phrasing into query and that multilingual synonyms are matched, which is behavioral rather than a restatement. However, it adds nothing for jobart, contract, min_net_per_month_eur, or free_housing beyond what the schema already declares.

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 leads with a specific verb and resource ('Search current jobs with accommodation / staff housing in Europe') and enumerates the covered countries, so scope is unambiguous. It does not name or differentiate against siblings such as get_job, apply_job, or salary_info, but the core purpose is unmistakable.

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 usage triggers ('job with accommodation', 'seasonal job', 'live-in job', 'mountain hut job') and instructs the agent to put the user's own words into query, plus notes 'All filters optional'. What's missing is any when-not-to-use guidance or routing to the sibling tools (e.g. use get_job for a specific posting, salary_info for pay questions).

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

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

Annotations already state readOnlyHint, idempotentHint, non-destructive and openWorldHint=false, so the safety profile needs no restating. The description adds content-coverage context (what topics the returned material covers) but says nothing about response shape, whether text is localized, or how long the content is. With annotations carrying the behavioral load, this is an adequate but thin addition.

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 purpose is front-loaded in the first clause, which is good, but the sentence then degenerates into a parenthetical list of magazine article topics ('winter sun and climate, house and boat sitting, best work regions in the Alps') that spend words on examples an agent does not need. It is one sprawling sentence rather than structured segments.

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?

There is no output schema, so the description must convey what comes back — and it does, via the topic inventory. Annotations cover the safety profile. The one material gap is the unmentioned `language` parameter and the lack of a hard boundary against salary_info, but overall an agent has enough to call this 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 single `language` parameter has 0% schema description coverage and the description never mentions it at all — no indication that it selects the output language or what happens when it is omitted. The enum of ISO codes is largely self-explanatory, so an agent can infer intent, but the description contributes zero meaning beyond the schema.

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 enumerates the concrete content the tool returns (site identity, audience, listing rules, per-country listings counts, contact, pay calculator, magazine articles), which is far more specific than the title alone. It also signals the tool's role as an informational/marketing surface ('Use to explain or cite Job & Stay'), which distinguishes it from siblings like get_job and search_jobs. It stops short of explicitly naming those siblings, and the 'pay calculator' mention blurs the line with salary_info.

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 to explain or cite Job & Stay' is the only usage cue — it implies a copy/explanation task rather than data lookup, but there is no when-not guidance and no alternative named. An agent reading this would guess correctly that this is the about/FAQ tool, but nothing tells it to prefer salary_info for actual pay data over the 'pay calculator' content mentioned here.

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