Skip to main content
Glama

Check an EOR or payroll quote

reconcile_quote
Read-only

Use this when the user shares a quote, offer, invoice or cost breakdown from an Employer of Record, PEO or payroll provider and asks whether it is fair, correct, overpriced or what it includes (e.g. "here is my EOR quote for Germany: salary 5,900, employer contributions 1,350, fee 560 a month, is it honest?", "voici le devis de mon EOR, est-il correct ?"). Checks the quote lines against the statutory ledger of the country at the same salary: expected and quoted amount per statutory line, statutory lines missing from a detailed quote, charges with no statutory counterpart, and the gap split into fee lines, charges above the statutory ledger and the salary-line difference (often an exchange-rate margin). When the quote gives employer charges as one total, that total is compared with the statutory total and the expected line-by-line breakdown is returned. A monthly quote in a country paying more than 12 monthly salaries a year (e.g. 14 in Spain) is read against one monthly payment, the extra payments being owed outside its lines. Amounts given in the local currency come back in it, with the USD in brackets. Pass the amounts as written on the quote; the provider's name is never needed. Do not use without figures from the user. Data snapshot 2026-10-22. Cost comparison, not legal or tax advice.

Input Schema

NameRequiredDescriptionDefault
linesYes
periodNoWhether the quote line amounts are per month or per year (one employee)month
salaryYesGross salary the quote is for, a year unless salary_period is "month"
countryYesISO 3166-1 alpha-2 code ("DE") or country name ("Germany")
assumptionsNoOverride an adjustable assumption the country declares, e.g. {"basic_share_of_gross": 0.6}. See `assumptions` in an employer_cost answer.
salary_periodNoWhether 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_currencyNoCurrency of `salary`: USD, or the local currency of the countryUSD
amounts_currencyNoCurrency of the quote line amountsUSD
payments_per_yearNoWith 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

NameRequiredDescriptionDefault
metaYes
linesYes
salaryYes
countryYes
readingYes
summaryYes
salary_lineNo
missing_noteNo
quote_detailYes
salary_basisNo
gap_breakdownYes
per_month_usdYes
aggregate_linesNo
per_month_localNo
expected_breakdownNo
missing_from_quoteYes
not_in_statutory_ledgerYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations declare read-only, closed-world, non-destructive behavior. The description adds valuable context beyond annotations: how monthly quotes in 13/14-payment countries are interpreted, that local currency amounts are returned in local currency with USD in brackets, the data snapshot date, and a clear 'cost comparison, not legal or tax advice' disclaimer. No contradiction with annotations.

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?

Front-loads the when-to-use clause and then provides logical supporting details. However, it is lengthy with multiple examples and could be tightened; some sentences overlap in purpose. Still, every sentence contributes useful context for a complex tool.

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?

Given 9 parameters, nested objects, and an existing output schema, the description is complete: it covers when to use, what the tool checks, how currencies and payment periods are handled, and includes a data snapshot and disclaimer. An agent has enough to invoke it correctly without needing to consult siblings or external docs.

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 description coverage is high (89%), so baseline is 3. The description adds meaningful guidance: 'Pass the amounts as written on the quote; the provider's name is never needed' and explains the interaction of salary_period with statutory payments (e.g., 14 salaries in Spain). This supplements the schema without duplicating it.

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 ('checks') and resource ('quote lines against the statutory ledger of the country'), and details what it computes (expected vs quoted amounts, missing lines, non-statutory charges, gap split). This distinguishes it from siblings like compare_offers by focusing on validating a user-provided quote against statutory data.

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?

Explicitly says when to use ('when the user shares a quote... and asks whether it is fair, correct...') and includes a when-not condition ('Do not use without figures from the user'). However, it does not name alternative tools (e.g., employer_cost) for cases where the user lacks a quote, leaving routing to siblings implicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.