EOR Scope

Contractor rate equivalent to an employee

contractor_rate_equivalent

Read-only

Use this when the user asks what day or hour rate a contractor would need to cost the same as an employee in a country, or wants to set a contractor rate against the full cost of employment (e.g. "what daily rate equals an 80k employee in Germany?"). The employee's annual cost (gross salary plus statutory employer charges, plus an Employer of Record fee if the user gives one) is divided by working days, by default 260 weekdays minus the country's statutory paid leave and public holidays, both adjustable. Costs only: it does not say whether a contractor arrangement is lawful or how to classify a worker. Data snapshot 2026-10-22. Cost comparison, not legal or tax advice.

Input Schema

Name	Required	Description	Default
`salary`	No	Gross salary, a year unless salary_period is "month". Omit to use the country's example salary.
`country`	Yes	ISO 3166-1 alpha-2 code ("DE") or country name ("Germany")
`assumptions`	No	Override an adjustable assumption the country declares, e.g. {"basic_share_of_gross": 0.6}. See `assumptions` in an employer_cost answer.
`working_days`	No	Working days a year, replacing the default calculation
`hours_per_day`	No	Hours per working day
`salary_period`	No	Whether the salary is a year (default) or a month. Pass a monthly salary as the user gives it, with "month": the statutory number of monthly payments of the country (13th, 14th month) is applied, see salary_basis in the answer.	year
`paid_leave_days`	No	Paid leave days a year. Omit to use the country's statutory minimum.
`public_holidays`	No	Public holidays falling on weekdays. Omit to use the number recorded for the country.
`salary_currency`	No	Currency of `salary`: USD, or the local currency of the country	USD
`eor_fee_usd_month`	No	An EOR fee to add to the employee cost, in USD per employee per month, as the user gives it
`payments_per_year`	No	With salary_period "month" only: the total number of monthly salaries the contract pays in a year, statutory ones included (e.g. 14). Omit to use the statutory number of the country.

Output Schema

Name	Required	Description	Default
`meta`	Yes
`salary`	Yes
`caveats`	Yes
`country`	Yes
`summary`	Yes
`annual_cost`	Yes
`salary_basis`	No
`working_days`	Yes
`employer_cost`	Yes
`hours_per_day`	Yes
`equivalent_rate`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 9, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the readOnly annotations by disclosing the computation method (annual cost incl. statutory employer charges and optional EOR fee, divided by working days), the default working-day basis (260 minus statutory leave and holidays), the data snapshot date, and a scope disclaimer. These are exactly the behavioral details an agent needs to trust and frame the answer.

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

Conciseness4/5

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

Four sentences, front-loaded with the trigger and example, then the formula, then scope exclusions and date. Dense but every sentence carries signal; only the trailing disclaimer could be trimmed slightly.

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 an 11-parameter tool with an output schema and full param descriptions, the description supplies the remaining gaps: methodology, defaults derivation, data vintage, and scope limits. Nothing an agent needs to invoke or interpret it correctly is missing.

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?

With 100% schema coverage the baseline is 3; the description adds real meaning by explaining that working_days defaults from 260 minus country leave/holidays, that both are adjustable, and that the EOR fee only applies when the user supplies one. It doesn't clarify salary_period/payments_per_year interplay, but that is already handled in the schema.

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+resource: converting an employee's total annual cost into a contractor day/hour rate, with a concrete example query. It is clearly distinct from siblings like employer_cost or compare_offers, which don't produce a contractor-rate equivalent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

Opens with an explicit trigger ('Use this when the user asks what day or hour rate a contractor would need...') and includes exclusions ('it does not say whether a contractor arrangement is lawful or how to classify a worker'). The agent knows both when to call it and what it must not be used to answer.

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

All EOR Scope 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.