french-rental-compliance

Frontalier telework — 40 % tax; 25 % / 50 % social security

calculate_teletravail_frontalier

Read-only

Frontalier telework thresholds (FR–CH): 40 % tax; social security Swiss below 25 %, French from 25 % unless the employer's A1 (framework agreement, below 50 %), reported separately. · Télétravail frontalier : seuil fiscal 40 % ; sécurité sociale suisse sous 25 %, française dès 25 % sauf A1 de l'employeur (accord-cadre, moins de 50 %). — Projects a typical working week over 46 worked weeks and returns the telework share, the position against BOTH limits (different instruments: the FR–CH tax avenant in force 24/07/2025, applying to pay from 01/01/2023, vs the EU/EFTA social-security framework agreement since 01/07/2023), the telework days that can still be added over the projected year (its worked days stay fixed) before each is crossed, and how many temporary mission days count inside the allowance (≤ 10 a year). What the 40 % line means depends on the canton of work — give work_canton: Geneva and the other source-taxing cantons stay taxed in Switzerland up to 40 %; the eight cantons of the 1983 agreement are taxed in France and keep the frontalier status up to 40 %. Without it, both regimes are stated. Optional: the 3-month LAMal/CMU droit d'option window (Swiss and EU nationals) from the Swiss employment start date or the later move to France. Deterministic — verified official facts with sources and dates, nothing stored. Same engine as the free web counter; a signed-in monthly log turns the projection into the real position (list_deadlines then carries the threshold warnings).

Input Schema

TableJSON Schema

Name	Required	Description
`as_of_date`	No	YYYY-MM-DD reference date for the option window (default: today) — makes the answer reproducible.
`work_canton`	No	Swiss canton of work (code like GE, VD, or name). Picks the tax rule: the 8 cantons of the 1983 agreement (BE, SO, BS, BL, VD, VS, NE, JU) tax in France; the others tax at source. Omitted: both regimes are stated.
`days_per_week`	No	Contractual working days per week (1–7). Default 5.
`france_move_date`	No	YYYY-MM-DD the worker took up residence in France, if already working in Switzerland — the window then counts from the LATER of the two dates (official form p.3).
`mission_days_per_year`	No	Temporary mission days per year in France or a third country — only the first 10 count inside the telework allowance.
`swiss_employment_start`	No	YYYY-MM-DD the Swiss employment began (or the Swiss pension was granted) — adds the 3-month LAMal/CMU droit d'option window. Only if this job opened the option: a first Swiss job since living in France, or a return after unemployment — a change of employer does not reopen it.
`telework_days_per_week`	Yes	Days per week worked from home in France (fractions allowed, e.g. 1.5).

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 1, 2026

addedInput schema / properties / france_move_date

Added value: +{
+  "description": "YYYY-MM-DD the worker took up residence in France, if already working in Switzerland — the window then counts from the LATER of the two dates (official form p.3).",
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+  "type": "string"
+}

changedInput schema / properties / swiss_employment_start / description

Previous value: -"YYYY-MM-DD the Swiss employment began — adds the 3-month LAMal/CMU droit d'option window."New value: +"YYYY-MM-DD the Swiss employment began (or the Swiss pension was granted) — adds the 3-month LAMal/CMU droit d'option window. Only if this job opened the option: a first Swiss job since living in France, or a return after unemployment — a change of employer does not reopen it."

addedInput schema / properties / work_canton

Added value: +{
+  "description": "Swiss canton of work (code like GE, VD, or name). Picks the tax rule: the 8 cantons of the 1983 agreement (BE, SO, BS, BL, VD, VS, NE, JU) tax in France; the others tax at source. Omitted: both regimes are stated.",
+  "maxLength": 40,
+  "type": "string"
+}

AddedSep 6, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds meaningful behavioral context: deterministic output, official sourced facts with dates, nothing stored, and the distinction between projection and a signed-in real-position log. It does not describe authentication or rate limits, but those are not central for this read-only calculation.

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

Conciseness2/5

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

The description is very long, dense, and bilingual, with the French translation doubling content without adding new information. It also delays the core action — projecting the telework position — until after a compact block of legal thresholds, so it is not well front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex multi-jurisdiction calculation with no output schema, the description does the heavy lifting: it explains what is returned, the canton-dependent meaning of the 40% line, the separate tax and social-security instruments, the mission-day allowance, and the optional option-window logic. An agent has enough context to invoke it correctly despite the lack of a formal output schema.

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 100%, so all seven parameters are already documented in the schema. The description reinforces how work_canton changes the tax rule and how mission_days_per_year is capped at 10 inside the allowance, but it adds little syntax or interpretation beyond what the schema already states.

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

Purpose4/5

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

The description names the specific resource (frontalier telework thresholds under FR–CH rules) and states the operation (projects a typical working week and returns telework share, limit positions, addable days, and mission-day treatment). It is clear enough to distinguish from generic calculators, but it does not explicitly contrast itself with the most plausible sibling, compare_lamal_cmu, even though the LAMal/CMU option window is part of its scope.

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?

It provides clear usage context: when work_canton should be supplied, what happens if it is omitted, and when the optional LAMal/CMU window applies. It also references the signed-in monthly log path and says list_deadlines then carries threshold warnings, which is useful alternative routing, but it stops short of explicit when-not-use guidance.

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

All french-rental-compliance 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?