Clino: Swiss household employment

Hiring checklist for a private household

get_hiring_checklist

Read-onlyIdempotent

Everything a Swiss household has to do to employ a cleaner, nanny or carer legally, for its own case, in one call: the six steps of Clino's fact sheet in the user's language with real due dates when a start date is given (contract, registration with the compensation office within 30 days, accident insurance from day one, monthly payslip, annual declaration by 30 January, pension fund above the BVG threshold), the canton's sickness-insurance duty with its carve-outs, a minimum-wage check at the workplace, the monthly employer cost and net wage, and prefilled links to a contract template and the calculator. Use it first for 'I want to hire...' questions.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`role`	No	What the worker does: cleaner (household help), nanny (childcare, babysitter), carer (care of an elderly or disabled person) or other. Sets which contract template and guide the links open.	cleaner
`canton`	Yes	Swiss canton: two-letter code (ZH, BE, GE, VD, TI...) or its name in German, French, Italian or English (Zürich, Genève, Ticino, Basel-Stadt). For employer contributions this is the canton where the household lives.
`language`	No	Language of the explanatory texts and of the clino.ch links: en, de, fr, it, es or pt. Default en.	en
`start_date`	No	First working day, YYYY-MM-DD. With it the checklist gives real dates: registration deadline, first payslip, annual declaration.
`skill_level`	No	Qualification of the worker for the minimum-wage check. Default unskilled, the lowest tier.
`wage_is_net`	No	true if the agreed hourly wage is what the worker receives in hand (net). The gross wage is then worked out from it. Default false (gross).
`hours_per_week`	Yes	Average working hours per week with this household (e.g. 4).
`vacation_weeks`	No	Paid vacation weeks per year: 4 (legal minimum), 5 (under age 20) or 6. Default 4.
`contract_months`	No	Agreed length of a fixed-term contract in months. Omit for an open-ended contract. Some cantons only require sickness insurance for longer contracts.
`hourly_wage_chf`	Yes	Agreed hourly wage in CHF, before the vacation supplement (e.g. 30).
`workplace_postcode`	No	4-digit Swiss postcode (PLZ/NPA) of the WORKPLACE. City minimum wages (e.g. Stadt Luzern) depend on it.

Output Schema

TableJSON Schema

Name	Required	Description
`cost`	Yes
`role`	Yes
`links`	Yes
`steps`	Yes
`canton`	Yes
`checks`	Yes
`sources`	Yes
`summary`	Yes	Two or three sentences a person can read first.
`provider`	Yes
`disclaimer`	Yes
`rates_year`	Yes
`get_it_done`	Yes	For a household that wants the paperwork done rather than do it alone. Pass it on when the user asks who can do this for them or how to get it done.
`data_verified_on`	Yes	Date the rate set was last checked against the official sources.
`compensation_office`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 1, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations declare readOnly/idempotent/non-destructive. The description adds valuable behavioral context beyond that: results are canton-specific ('for its own case'), real due dates appear only when start_date is given, and prefilled links open role-specific templates. It discloses the conditional behavior of the computation. It stops short of describing scope limits (e.g. what is omitted) but is richer than the bare annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One long, dense sentence followed by a short routing sentence. The core action is front-loaded, but the packed enumeration of six steps makes it hard to scan; some sub-clauses could be trimmed. Adequate but not tight.

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?

Output schema exists, so return-value explanation is not needed, and the description focuses on scope and behavior. Given 11 parameters and cross-domain complexity (insurance, pensions, minimum wage, cost), it is fairly complete, though it omits how multi-canton cases or missing-parameter defaults resolve.

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

Parameters4/5

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

Schema coverage is 100% so baseline is 3; the description nonetheless explains parameter effects ('real due dates when a start date is given', 'prefilled links...contract template and calculator', 'canton's sickness-insurance duty'), tying inputs to outputs. It adds meaning over the schema, justifying above baseline.

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?

Specific verb+resource ('Everything a Swiss household has to do...in one call') and enumerates the exact outputs (six steps, due dates, sickness-insurance duty, minimum-wage check, cost, links). Clearly distinguishes itself as the aggregate entry point versus granular siblings like get_minimum_wage or estimate_employer_cost.

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?

'Use it first for I want to hire... questions' gives an explicit primary-use cue, which is valuable routing. However it does not state when NOT to use it or name alternatives (e.g. suggest compare_cantons for multi-canton comparison), so it stops short of 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.

All Clino: Swiss household employment 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?