EOR Scope

Employer cost at a future date

cost_next_year

Read-only

Use this when the user budgets an employee for next year or a future date and asks how the statutory employer cost will move (e.g. "what will this hire in Brazil cost the employer in January 2027?"). Returns the cost today and at that date (by default 1 January of next year), at the same gross salary and exchange rate, applying only the enacted dated changes recorded for the country; changes announced in a budget come in a separate, flagged variant, and dates deduced from a source are flagged. A country whose changes are not tracked yet gets today's cost and "not yet tracked", never a projection. Amounts given in the local currency come back in it, with the USD in brackets. 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")
`on_date`	No	Date of the projection, YYYY-MM-DD. Omit for 1 January of the year after the data snapshot.
`assumptions`	No	Override an adjustable assumption the country declares, e.g. {"basic_share_of_gross": 0.6}. See `assumptions` in an employer_cost answer.
`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
`salary_currency`	No	Currency of `salary`: USD, or the local currency of the country	USD
`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
`flags`	No
`salary`	Yes
`country`	Yes
`current`	Yes
`on_date`	Yes
`reading`	Yes
`summary`	Yes
`coverage`	No
`tracking`	Yes
`projected`	Yes
`salary_basis`	No
`researched_on`	No
`with_budget_announced`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 9, 2026

TDQS

A4.5/5.0

Behavior5/5

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

The description adds substantial behavioral context beyond the annotations: only enacted dated changes are applied, budget-announced changes are a separate flagged variant, deduced dates are flagged, untracked countries return today's cost plus 'not yet tracked' rather than a projection, and currency formatting is specified. These details materially affect interpretation of results.

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

Conciseness5/5

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

The description is dense and front-loaded, beginning with the usage trigger and then layering projection rules, edge cases, and output currency behavior. Every sentence carries operational value, including the snapshot date and disclaimer, with no filler.

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 projection tool with an output schema, the description covers the important unknowns: what changes are included, how unenacted or deduced changes are treated, how untracked countries behave, and what currency the response uses. Nothing an agent needs in order to invoke or interpret the tool correctly appears to be missing.

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 parameters are already documented in the schema. The description reinforces a few behaviors, such as same gross salary and exchange rate and default date behavior, but does not add meaningful parameter semantics beyond the structured schema. Baseline 3 is appropriate.

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?

The description states a specific verb and resource: projecting statutory employer cost to a future date. It clearly distinguishes this from a current-cost lookup by explaining that it returns both today's cost and the future cost, applying only enacted dated changes. An agent can identify the scope without needing sibling schemas.

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 gives a clear triggering scenario: the user budgets an employee for next year or a future date and asks how employer cost will move. It also explains edge cases such as untracked countries and budget-announced changes. It stops short of explicitly naming employer_cost as the alternative for present-day cost, so it lacks full 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 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.