Temsor API — Turkey & EU business data

Turkish Severance, Notice & Leave

tr_labor

Computes Turkish severance (kıdem), notice (ihbar) and annual-leave entitlement from service dates and the gross wage, using the official ceiling and minimum-wage tables for the given day.

Payroll and HR tools in Turkey chase a parameter that changes every January and July: the severance ceiling, the SGK cap, the minimum wage. This endpoint applies the statutory formulae (Labour Law 4857 arts. 17 and 53, former 1475 art. 14) to those tables. The ceiling is applied to the monthly wage, not the total. Stamp tax (0.759%) is deducted from severance; income tax is not — kıdem is exempt. Notice pay IS taxable; we return the gross and say so, because the actual withholding depends on the employee's cumulative tax base. What this will not tell you: whether the employee is entitled to severance at all. That depends on the reason for termination (retirement, just cause, marriage, military service…). Treating the number as "what is owed" is how you lose at trial.

Input Schema

TableJSON Schema

Name	Required	Description
`age`	No	Employee age at termination — affects annual-leave entitlement (under 18 or 50+).
`asOf`	No	Rate table date. Defaults to endDate.
`endDate`	Yes	Termination date (YYYY-MM-DD). Inclusive of this day.
`startDate`	Yes	Employment start date (YYYY-MM-DD).
`monthlyGross`	Yes	Gross monthly wage the severance is based on (giydirilmiş brüt).
`unusedLeaveDays`	No	Unused annual-leave days, if you also want the unused-leave gross.

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations to carry the burden, the description provides deep behavioral context: statutory references, ceiling application semantics, which taxes apply or don't, and the tool's limits. Goes well beyond a basic description of what the tool calculates.

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?

Information-dense with no wasted sentences; even the legal citations and tariff context serve as behavioral cues for the agent. The prose is slightly ornate in the middle section but remains functionally relevant to understanding the tool's behavior.

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?

For a tool computing three legal entitlements with tax nuances, the description covers input semantics and the legal limitations thoroughly. Missing a description of the return-value shape, which would help agents chain this with downstream logic.

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?

The input schema already has 100% coverage with rich parameter descriptions, so the baseline is raised. The description adds value by explaining how parameters interact ('the ceiling is applied to the monthly wage, not the total') and the tax implications of the salary inputs. This enriches the agent's understanding of what changing the parameters actually computes.

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?

Uses specific verb 'Computes' with clearly enumerated resources (severance, notice, annual-leave) and inputs. Distinguishes itself from sibling validator/parser tools by describing computation logic and legal basis. The description reads as a domain-specific calculation tool rather than a generic validation function.

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 lists boundary conditions with the 'What this will not tell you' section, warning about entitlement determination and legal consequences. Clearly states tax treatment (stamp tax, income tax exemption). Lacks explicit naming of alternative/sibling tools for when this endpoint is inappropriate, preventing a 5.

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

All Temsor API — Turkey & EU business data tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation4/5

Most tools have clearly distinct purposes (e.g., bic_validate vs vin_validate), but there is notable overlap: tr_validate bundles Turkish validations that are also covered individually by iban_validate and tin_validate. Also, lei_validate and lei_lookup are closely related but distinct enough. Overall, agents can usually pick the right tool, but a few pairs could confuse.

Naming Consistency4/5

Tool names are consistently snake_case with predominately verb_noun patterns (e.g., validate, lookup, screen, parse, build). Some nouns like mcp_index, model_archive, and series_history break the verb pattern but are still predictable. Minor deviations from the noun_verb form (tr_invoice_build, shipping_identify) don't cause confusion. Very readable and consistent overall.

Tool Count3/5

With 27 tools, the set is heavy, exceeding the typical 3–15 well-scoped range. However, the server covers a broad domain: international standards validation, Turkey-specific business data (fuel, labor, invoices, addresses), and even MCP/LLM model archives. The count is justifiable given the scope, but it stretches coherence and may overwhelm agents.

Completeness4/5

The tool surface is remarkably comprehensive for the stated Turkey & EU business data purpose: validators for most ID types, VAT, IBAN, phone, VIN, sanctions; plus Turkey-specific operations like invoice build/parse, labor calculations, fuel prices, business days, and address parsing. Minor gaps exist (e.g., no general exchange-rate conversion, no credit-note-specific builder), but agents can accomplish core workflows without dead ends.

Resources

Need Help?