Temsor API — Turkey & EU business data
REMOTE · API.TEMSOR.COM · SCANNED SEP 24
Turkey & EU business data: validation, sanctions screening, parsing, FX and fuel price history
Available components
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security66
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation not fully verified: no authorisation is required to call this server, and 72 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe. See how to fix → View diagnostics → Unverified
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- The HSTS (Strict-Transport-Security) header is present. View diagnostics → Pass
- DNSSEC is configured correctly; the domain's records validate against the full chain to the root. View diagnostics → Pass
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability66
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 13973 tokens (~194/item across 72 items; 72 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management100
- No destabilizing schema changes in the last 30 days.Pass
Tool Coverage95
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 84% of tool parameters carry a description.Partial
Tool Safety75
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- 0 of 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "pay_epc_qr" implies "pay" and declares no destructiveHint at all, which the MCP spec reads as destructive by default. See how to fix → Fail
- An AI judge read all 72 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities60
- Spec-recency check failed: implements MCP spec 2025-06-18; the latest is 2026-07-28. See how to fix → Fail
How do I install the Temsor API — Turkey & EU business data MCP server?
Temsor API — Turkey & EU business data is a hosted endpoint at https://api.temsor.com/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · api.temsor.com
claude mcp add --transport http com-temsor-api 'https://api.temsor.com/mcp'
{
"mcpServers": {
"com-temsor-api": {
"url": "https://api.temsor.com/mcp"
}
}
} {
"servers": {
"com-temsor-api": {
"type": "http",
"url": "https://api.temsor.com/mcp"
}
}
} [mcp_servers.com-temsor-api] url = "https://api.temsor.com/mcp"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"com-temsor-api": {
"type": "remote",
"url": "https://api.temsor.com/mcp",
"enabled": true
}
}
} openclaw mcp add com-temsor-api --url 'https://api.temsor.com/mcp' --transport streamable-http
mcp_servers:
com-temsor-api:
url: "https://api.temsor.com/mcp" {
"McpServers": {
"com-temsor-api": {
"Transport": "http",
"Url": "https://api.temsor.com/mcp"
}
}
} assistant mcp add com-temsor-api -t streamable-http -u 'https://api.temsor.com/mcp'
{
"mcpServers": {
"com-temsor-api": {
"type": "http",
"url": "https://api.temsor.com/mcp"
}
}
} The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 24 Sept 26 0
- A breaking change shipped without a version bump: still 1.0.0 ▼ security
- Tool “pbx_enrich” was removed ▼ security
- 23 Sept 26 0
- New tool “pbx_enrich” functional
- 22 Sept 26 0
- Tool “pbx_bridge_multi_agent” rewrote its description, which is the text the model reads security
- Tool “pbx_calls_graph” rewrote its description, which is the text the model reads security
- Tool “pbx_events” rewrote its description, which is the text the model reads security
- Tool “pbx_facts” rewrote its description, which is the text the model reads security
- Tool “pbx_orchestra_act” rewrote its description, which is the text the model reads security
- Tool “pbx_orchestra_acts” rewrote its description, which is the text the model reads security
- Tool “pbx_persons” rewrote its description, which is the text the model reads security
- Tool “pbx_promises” rewrote its description, which is the text the model reads security
- Tool “pbx_promises_act” rewrote its description, which is the text the model reads security
- Tool “pbx_search” rewrote its description, which is the text the model reads security
- Tool “pbx_status” rewrote its description, which is the text the model reads security
- Tool “pbx_webhooks” rewrote its description, which is the text the model reads security
- Tool “pbx_webhooks_deliveries” rewrote its description, which is the text the model reads security
- Tool “pbx_whisper_suggest” rewrote its description, which is the text the model reads security
- Tool “pbx_bridge_multi_agent” changed its title: PBX Multi-Agent Bridge → Multi-Agent Handoff Bridge cosmetic
- Tool “pbx_calls_graph” changed its title: PBX Call Graph / Transfers → Call Handoff Graph cosmetic
- Tool “pbx_events” changed its title: PBX Events → Call Events Ingest cosmetic
- Tool “pbx_orchestra_act” changed its title: PBX ARI Orchestra Act → Call Orchestra Act cosmetic
- Tool “pbx_promises” changed its title: PBX Open Promises → Open Call Promises cosmetic
- Tool “pbx_search” changed its title: PBX Search → Voice Archive Search cosmetic
- 15 Sept 26 +53
- Injection markers: unverified → pass ▲ security
- Stability: unverified → pass ▲ security
- HSTS header: fail → pass ▲ security
- Transport: fail → pass ▲ security
- Authorization: Authorisation not fully verified: no authorisation is required to call this server, and 72 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe. security
- Tool “pbx_dictionary” rewrote its description, which is the text the model reads security
- Tool “pbx_dictionary_add” rewrote its description, which is the text the model reads security
- Tool “pbx_index_partial” rewrote its description, which is the text the model reads security
- Tool “pbx_index_partial_get” rewrote its description, which is the text the model reads security
- Tool “pbx_orchestra_act” rewrote its description, which is the text the model reads security
- Tool “pbx_redact” rewrote its description, which is the text the model reads security
- Tool “pbx_redact_audit” rewrote its description, which is the text the model reads security
- Tool “pbx_whisper_suggest” rewrote its description, which is the text the model reads security
- MCP protocol: unverified → fail ▼ functional
- Endpoint reachability: not serving MCP → reachable ▲ functional
- Tool coverage: unverified → 100 ▲ functional
- New tool “pbx_orchestra_acts” functional
- New tool “pbx_promises_act” functional
- New tool “pbx_whisper_status” functional
- “pbx_dictionary” reworded the description of “domain” cosmetic
- “pbx_dictionary_add” reworded the description of “domain” cosmetic
- “pbx_facts” reworded the description of “domain” cosmetic
- 14 Sept 26 −53
- Endpoint reachability: reachable → not serving MCP ▼ security
- Stability: pass → unverified ▼ security
- Tool safety: pass → unverified ▼ security
- Transport: pass → fail ▼ security
- HSTS header: pass → fail ▼ security
- Authorization: Authorisation not fully verified: no authorisation is required to connect, but we couldn't read the tool list to see what that exposes. security
- Capabilities: fail → unverified ▼ functional
- Tool coverage: 100 → unverified ▼ functional
- First check of Schema quality: unverified functional
- 13 Sept 26 0
- New tool “ai_messages” functional
- 9 Sept 26 0
- Schema quality: 229 → 191 ▲ functional
- New tool “pbx_audio_chunk” functional
- New tool “pbx_bridge_multi_agent” functional
- New tool “pbx_calls” functional
- New tool “pbx_calls_get” functional
- New tool “pbx_calls_graph” functional
- New tool “pbx_dictionary” functional
- New tool “pbx_dictionary_add” functional
- New tool “pbx_events” functional
- New tool “pbx_facts” functional
- New tool “pbx_facts_get” functional
- New tool “pbx_index_partial” functional
- New tool “pbx_index_partial_get” functional
- New tool “pbx_ingest_transcript” functional
- New tool “pbx_night_twin_last” functional
- New tool “pbx_night_twin_run” functional
- New tool “pbx_orchestra_act” functional
- New tool “pbx_persons” functional
- New tool “pbx_persons_get” functional
- New tool “pbx_promises” functional
- New tool “pbx_promises_close” functional
- New tool “pbx_promises_export” functional
- New tool “pbx_promises_reopen” functional
- New tool “pbx_redact” functional
- New tool “pbx_redact_audit” functional
- New tool “pbx_register” functional
- New tool “pbx_search” functional
- New tool “pbx_status” functional
- New tool “pbx_synthetic_run” functional
- New tool “pbx_webhooks” functional
- New tool “pbx_webhooks_deliveries” functional
- New tool “pbx_whisper_suggest” functional
- 7 Sept 26 0
- Tool “tr_validate” rewrote its description, which is the text the model reads security
- Schema quality: 7444 → 8501 ▼ functional
- New tool “ean_gtin” functional
- New tool “isbn_validate” functional
- New tool “tr_iban_olustur” functional
- New tool “tr_posta_kodu” functional
- New tool “tr_qr_odeme” functional
- New tool “uuid_validate” functional
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 24 Sept 2026 · Probed https://api.temsor.com/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=temsor.com | CN=WE1,O=Google Trust Services,C=US | 4 Sept 2026 | 3 Dec 2026 | ECDSA 256 | ECDSA-SHA256 | a95a54f96a088ea131768b8200d188e |
| SANs: temsor.com, *.temsor.com | ||||||
| CN=WE1,O=Google Trust Services,C=US (CA) | CN=GTS Root R4,O=Google Trust Services LLC,C=US | 13 Dec 2023 | 20 Feb 2029 | ECDSA 256 | ECDSA-SHA384 | 7ff31977972c224a76155d13b6d685e3 |
| CN=GTS Root R4,O=Google Trust Services LLC,C=US (CA) | CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE | 15 Nov 2023 | 28 Jan 2028 | ECDSA 384 | SHA256-RSA | 7fe530bf331343bedd821610493d8a1b |
Background: What to check on a remote MCP endpoint →
DNSSEC secure
Validation of api.temsor.com. — Secure
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| com. | present | 19718 | 13 | Verified |
| temsor.com. | present | 2371 | 13 | Verified |
| api.temsor.com. | Verified address RRset verified with the apex keys |
Authentication No authorisation required
The endpoint answered without asking for a token. Anyone who knows the URL can reach it.
| Result | No authorisation required |
|---|---|
| HTTP status | 200 |
| Header | Value |
|---|---|
| strict-transport-security | max-age=15552000; includeSubDomains |
| x-content-type-options | nosniff |
| referrer-policy | no-referrer |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://api.temsor.com/mcp | Verified | 200 | |
| http (plaintext) | http://api.temsor.com/mcp | HTTPS enforced | 301 | https://api.temsor.com/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
pbx_whisper_status PBX Whisper RTP Status ~130
Capability: mode=stub|ready from TEMSOR_RTP_*. No live RTP on forge; idle $0. GET /v1/pbx/whisper/status. Reports MediaBridge config presence (TEMSOR_RTP_PATH). mode=ready means path env set — not that Asterisk RTP is flowing. live_rtp/listening always false on forge (R2–R3 IVR sidecar; R4 lab E2E harness). No ≤400ms production claim. TEMSOR_RTP_LAB=1 → optional lab_latency_ms on suggest. No DID sales.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
pbx_whisper_suggest PBX Live Whisper Suggest ~171
Live agent handoff cards (≤3): open promises/facts from in-call index. Idle $0. Lab: TEMSOR_RTP_LAB=1 → lab_latency_ms. POST /v1/pbx/whisper/suggest {call_id, partial_text}. Returns open promises and facts as whisper cards for agent handoff. Prefers in-call partial index when present. Mock latency_ms under 400ms (compat stub). Idle $0. No Telnyx/DID/live PSTN. Advanced: optional lab_latency_ms when TEMSOR_RTP_LAB=1 (measured; not prod SLA).
| Name | Type | Req | Description |
|---|---|---|---|
| call_id | string | yes | Active call id for agent UI context. |
| partial_text | string | – | Partial transcript / utterance text (no live speech recognition). |
No output schema declared.
No examples provided.
phone_validate Phone Number Validation ~242
Validates and normalises a phone number to E.164, classifies the line type, and resolves the province for Turkish landlines. For signup and checkout flows that need to store one canonical form and reject typos early. Turkish numbers are handled in depth: landline area codes resolve to a province, mobile and special ranges (toll-free 0800, fixed-rate 0850, premium 0900) are classified, and every accepted input comes back in both E.164 and national notation. One thing this endpoint deliberately does not claim: the current mobile operator. Turkey has had number portability since 2008, so a 0532 number may well be on another network today. Competing APIs report the prefix owner as "the operator" and customers pick SMS routes on that basis. We return it as `originallyAllocatedTo` with the caveat attached, because a confident wrong answer costs more than an honest gap.
| Name | Type | Req | Description |
|---|---|---|---|
| defaultCountry | string | – | ISO 3166-1 alpha-2 country to assume when the number has no international prefix. Defaults to TR. |
| phone | string | yes | Phone number in any common format. |
No output schema declared.
No examples provided.
sanctions_screen Sanctions Screening ~336
Screens a name against six official sanctions lists — US OFAC, UN, EU, UK OFSI, Switzerland SECO and Canada — with transliteration-aware fuzzy matching. Six official lists are reduced to one schema, so a name is checked everywhere at once instead of six integrations. Cyrillic and Arabic names are transliterated, titles and corporate suffixes are stripped, and known spelling families are unified — "Abd al-Rahman", "Abdul Rahman" and "Abdulrahman" reach the same record. Every hit explains itself: which name matched, whether it was an alias the source flags as weak, and how the birth year and country compared. Supply `birthYear` whenever you have it; it removes most false positives. `asOf` screens against the lists as they stood on a past date, which is the question auditors actually ask — note that this is bounded by when our archive begins, reported in `coverage`.
| Name | Type | Req | Description |
|---|---|---|---|
| asOf | string | – | Screen against the lists as they stood on this date. Limited by when our archive begins. |
| birthYear | integer | – | Known birth year. The single strongest false-positive filter available. |
| country | string | – | Known country or nationality. |
| limit | integer | – | – |
| minScore | number | – | Score floor. 0.92+ reads as a match, 0.80+ as possible. |
| name | string | yes | Name to screen — person or organisation. |
| sources | array | – | Defaults to all lists. |
| type | string | – | Restrict to one subject type. Narrowing this removes most false positives. |
No output schema declared.
No examples provided.
series_history Time Series History ~198
Returns the accumulated history of public data series with change statistics and a source receipt for every point. Currently ingesting the Turkish Central Bank daily FX bulletin (`tcmb.usd`, `tcmb.eur`, …), normalised to one unit so JPY-style 100-unit quotes stop biting. Leave `seriesId` empty to list the catalogue. `fillGaps` carries the last value across weekends and holidays; `includeEvidence` attaches the source URL and content hash for every point, so a value can still be defended years later.
| Name | Type | Req | Description |
|---|---|---|---|
| fillGaps | boolean | – | – |
| from | string | – | Start date (inclusive). |
| includeEvidence | boolean | – | Include source URL and content excerpt for each point. |
| limit | integer | – | – |
| seriesId | string | – | Series id, e.g. `tcmb.usd`. Omit to list the catalogue. |
| to | string | – | End date (inclusive). |
No output schema declared.
No examples provided.
shipping_identify Tracking Number Identification ~237
Identifies which carrier a tracking number belongs to, validates it where a checksum exists, and returns the canonical tracking link. Built for order systems that receive numbers from many carriers and have to route the customer to the right tracking page. Turkish carriers mostly use plain numeric ranges that overlap, so a single confident answer is often impossible — this returns a ranked candidate list instead of inventing certainty, because sending a customer to the wrong carrier's page makes them think the parcel is lost. Universal Postal Union (S10) numbers are fully verified: the mod-11 check digit is computed, the service type and origin country are decoded. For formats whose checksum we have not verified against the standard, the result says `not-verified` rather than guessing — a wrong rejection is worse than an honest unknown. Delivery status is deliberately out of scope: Turkish carriers require merchant credentials for that, and scraping their sites would be fragile and against their terms.
| Name | Type | Req | Description |
|---|---|---|---|
| country | string | – | Destination or origin country hint, e.g. "TR". Narrows the candidates. |
| trackingNumber | string | yes | Tracking number, with or without spaces and dashes. |
No output schema declared.
No examples provided.
tin_validate Tax Identifier Validation ~237
Validates a tax identifier for 25+ countries: checksum where the algorithm is public, format-only where it is not. Country is required. Onboarding forms collect a tax number from whatever country the customer is in and then store garbage because they only checked the length. This applies the published checksum (SIREN/SIRET Luhn, ABN mod-89, CPF/CNPJ, NIP, BSN 11-proef, NIF/NIE, OIB, IČO, AFM, TCKN/VKN, …) and refuses to guess the country: the same 9 digits are a well-formed identifier in more than one place. Where the checksum is not published (US EIN, UK UTR, DE Steuernummer, IN PAN) the answer is format + `checksum: not-verified`, not a fake pass. This does not ask any tax authority whether the number is issued.
| Name | Type | Req | Description |
|---|---|---|---|
| country | string | yes | ISO 3166-1 alpha-2 country that issued the identifier. Required. |
| tin | string | yes | Tax identifier as written, with or without spaces and punctuation. |
No output schema declared.
No examples provided.
tr_address_parse Turkish Address Parser ~149
Splits a free-form Turkish address into neighbourhood, street, building, floor, flat, district, province and postcode. Handles the abbreviation chaos (Mah./Mh., Cd./Cad., Sk./Sok., No:12/5, K:3 D:7), cross-checks the province against the postcode, repairs misspelled district names against a dictionary, and returns a confidence score. Anything it could not place is listed in `unparsed` — nothing is dropped silently. Built for shipping, checkout and CRM systems that receive Turkish addresses typed by humans.
| Name | Type | Req | Description |
|---|---|---|---|
| address | string | yes | Free-text address. |
| defaultProvince | string | – | Province to assume when the address has none. |
No output schema declared.
No examples provided.
tr_business_days Turkish Business Days ~160
Adds business days or counts them between two dates, accounting for Turkish public and religious holidays including half-day eves. Ramadan and Sacrifice feasts follow the Hijri calendar and cannot be derived reliably by formula, so announced dates are read from a table; years without an official announcement are returned with `confirmed:false` rather than guessed silently. For delivery promises, SLA clocks, payment terms and shipping estimates.
| Name | Type | Req | Description |
|---|---|---|---|
| addDays | integer | – | Add/subtract this many business days (not calendar days). |
| countHalfDaysAsWork | boolean | – | Count Arife half-days as working days? |
| end | string | – | If set, count business days between start and this date. |
| start | string | yes | Start date (YYYY-MM-DD). |
No output schema declared.
No examples provided.
tr_fuel_prices Turkey Fuel Prices ~313
Petrol, diesel and heating-oil pump prices for all 81 Turkish provinces, including the price in force on any past date. The distributor publishes today's pump price and a per-district history query, one district and one range at a time. This endpoint answers the question that actually costs money, in a single call: what was diesel in Ankara on 12 March? Pass `asOf` for the price in force on that day — if the distributor did not change prices that day, the previous price is carried forward and `effectiveFrom` says when it started, with `carriedForward: true`. Pass `from`/`to` to get the change events in a window, each with the percentage move. Every figure carries the source URL and a content hash of the page it was read from, so the number can still be defended in an audit years later. Leave `province` empty to list coverage.
| Name | Type | Req | Description |
|---|---|---|---|
| asOf | string | – | Price in force on this date (YYYY-MM-DD). Omitted → latest known price. |
| from | string | – | With `to`: return the price changes in this window. |
| includeDistricts | boolean | – | Adds districts whose pump price differs from the province reference price. |
| product | string | – | Fuel product. Omitted → every product available for that province. |
| province | – | – | Province name or plate code — "Ankara", "istanbul" or 34. Leave empty to list covered provinces. |
| to | string | – | – |
No output schema declared.
No examples provided.
tr_iban_olustur Build Turkish IBAN ~202
Builds a Turkish IBAN from a 5-digit bank code and account number, computing ISO 7064 check digits. A Turkish IBAN is TR + 2 check digits + 5-digit bank code + 1 reserved digit + 16-character account. This pads the account on the left, defaults the reserved digit to 0, computes the mod-97 check digits, and resolves the bank name from the same national table used by IBAN validation when the code is known. Unknown bank codes still produce a structurally valid IBAN with bankName null — existence at the bank is not claimed.
| Name | Type | Req | Description |
|---|---|---|---|
| accountNumber | string | yes | Account number, up to 16 alphanumeric characters (padded left with zeros). |
| bankCode | string | yes | 5-digit Turkish national bank / EFT code (e.g. 00062). |
| reserved | string | – | Reserved BBAN digit after the bank code. Defaults to 0. |
No output schema declared.
No examples provided.
tr_invoice_build Turkish e-Invoice Builder ~454
Builds a UBL-TR e-Invoice or e-Archive XML document from plain JSON, computing every total and validating the parties. Selling into Türkiye means issuing a UBL-TR document whose element order is fixed by schema and whose totals must agree to the kuruş, or the integrator rejects it. This endpoint takes the invoice as ordinary JSON and returns the XML. Totals you send are ignored on purpose — line amounts, per-rate VAT subtotals and the payable amount are all recomputed here, because a rounding difference of one kuruş is the most common rejection. VKN and TCKN checksums are verified, and the amount is written out in Turkish words as invoices require. It does not sign the document and does not transmit it: the financial seal and the submission to the tax authority belong to your certificate and your integrator. What comes back is a document ready to enter that step.
| Name | Type | Req | Description |
|---|---|---|---|
| amountInWords | boolean | – | Adds the payable amount written out in Turkish words as a note, the way invoices require. |
| currency | string | – | ISO 4217. Anything other than TRY requires `exchangeRate`. |
| customer | object | yes | – |
| despatchDocumentId | string | – | Delivery note number, if the goods shipped separately. |
| exchangeRate | number | – | Units of TRY per one unit of `currency`. |
| id | string | – | Invoice number. Omit and supply `series` to have it built from the series and sequence. |
| invoiceTypeCode | string | – | – |
| issueDate | string | yes | – |
| issueTime | string | – | – |
| lines | array | yes | – |
| notes | array | – | – |
| orderReferenceId | string | – | – |
| profile | string | – | TEMELFATURA: no formal objection flow. TICARIFATURA: buyer may accept/reject. EARSIVFATURA: buyer is not an e-Invoice user. |
| sequence | integer | – | Sequence number within the series and year. |
| series | string | – | Three-letter series code, used with `sequence`. |
| supplier | object | yes | – |
| uuid | string | – | Document UUID (ETTN). Generated when omitted. |
No output schema declared.
No examples provided.
tr_invoice_parse Turkish e-Invoice (UBL-TR) Parser ~118
Turns a UBL-TR e-Invoice or e-Archive XML document into clean JSON: parties, line items, taxes and totals. Works regardless of the namespace prefix the sender used (cbc:, cac:, ns0:), normalises single-line documents into arrays, and reports amount mismatches in `warnings` instead of returning quietly wrong totals. The job that costs accounting and expense software the most engineering time.
| Name | Type | Req | Description |
|---|---|---|---|
| xml | string | yes | UBL-TR e-Invoice / e-Archive (e-Arsiv) XML body. |
No output schema declared.
No examples provided.
tr_labor Turkish Severance, Notice & Leave ~356
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.
| Name | Type | Req | Description |
|---|---|---|---|
| age | integer | – | Employee age at termination — affects annual-leave entitlement (under 18 or 50+). |
| asOf | string | – | Rate table date. Defaults to endDate. |
| endDate | string | yes | Termination date (YYYY-MM-DD). Inclusive of this day. |
| monthlyGross | number | yes | Gross monthly wage the severance is based on (giydirilmiş brüt). |
| startDate | string | yes | Employment start date (YYYY-MM-DD). |
| unusedLeaveDays | number | – | Unused annual-leave days, if you also want the unused-leave gross. |
No output schema declared.
No examples provided.
tr_money_to_words Amount to Turkish Words ~156
Writes a monetary amount out in Turkish words, the way invoices, cheques and promissory notes require. Applies the rules that trip up generic libraries: Turkish says "bin", never "bir bin"; the kuruş part is read separately; and both "1.234,56" and "1,234.56" are accepted and told apart automatically. A mandatory field on Turkish e-invoices, cheques and notes — with no off-the-shelf API until now.
| Name | Type | Req | Description |
|---|---|---|---|
| amount | – | yes | Amount. Accepts both "1.234,56" and 1234.56. |
| currency | string | – | – |
| style | string | – | Output letter case. |
| wrapHash | boolean | – | – |
No output schema declared.
No examples provided.
tr_posta_kodu Turkish Postal Code ~127
Validates a 5-digit Turkish postal code and resolves the province from the first two digits (plate map). PTT postal codes are five digits; the leading pair matches the province plate code for the 81 provinces. This endpoint checks the shape, maps 01–81 to the province name, and returns null with confidence none when the prefix is outside that range — it does not invent a district. District-level resolution needs the full PTT directory and is out of scope here.
| Name | Type | Req | Description |
|---|---|---|---|
| postalCode | string | yes | Turkish 5-digit postal code, with or without spaces. |
No output schema declared.
No examples provided.
tr_qr_odeme Turkish FAST / TR Karekod Payload ~279
Builds a person-to-person TR Karekod (FAST) payment payload from IBAN, name and optional TRY amount. Text only — no PNG. Turkish instant payments (FAST) can start from a TR Karekod that encodes the payee IBAN and name in EMV-style TLV. This builds the person-to-person organisation (payload format indicator 750210): application template with IBAN, payee name, optional 12-digit kuruş amount, optional free-text explanation, and a CRC-16/CCITT-FALSE trailer. The Turkish IBAN is normalised and checked with ISO 7064 mod-97; non-TR IBANs and non-TRY currencies are rejected. This does not send money and does not render a QR image.
| Name | Type | Req | Description |
|---|---|---|---|
| amount | number | – | TRY amount; omitted → static QR (payer enters amount). |
| currency | string | – | Must be TRY if provided. |
| explanation | string | – | Optional remittance note (application free field 10). |
| generatorCode | string | – | QR generator / EFT code (4 digits). Defaults to last 4 of the IBAN bank code. |
| iban | string | yes | Beneficiary Turkish IBAN (with or without spaces). |
| name | string | yes | Payee name shown to the payer (2–26 chars after trim). |
No output schema declared.
No examples provided.
tr_tebligat_clock Turkish Service-of-Process Clock ~598
Computes the deemed-received date and the HMK deadline (with holiday shifting) for a Turkish notification, from the date the underlying event actually happened. Turkish notification law (7201) ties the deadline clock to an event that is not "the date on the letter" — for electronic notification the UETS platform reports send, read AND reached dates, and only the reached date starts the clock (art. 7/a: deemed received 5 calendar days after reaching the address, whether or not it was opened). HMK adds two more rules on top: the day of notification itself does not count (art. 92 — the period starts the next day) and if the computed last day lands on a weekend or a full public/religious holiday, it moves to the next business day (art. 93); a half-day eve (arife) does not shift it. What this will not tell you: whether the notification was itself valid, or what a specific `periodType` (itiraz, temyiz, cevap…) is in days for your case — that number differs by statute and we do not guess it; supply `periodDays` yourself. Only the "hmk" law family is covered so far.
| Name | Type | Req | Description |
|---|---|---|---|
| basisDate | string | yes | The date `basisLabel` describes for this type — for "electronic" this is the date UETS reports the message as reached, not sent or read. |
| hasAttorney | boolean | – | Whether the addressee has a registered attorney of record. When true and `type` is not "vekil", a TK 11 warning is added noting that service should have gone to the attorney. |
| ilanenDeemedDays | integer | – | Only valid with type "ilanen": number of days the competent authority set for the notice to become deemed received (TK 31), 7-15, default 7. Not the number of days for the underlying period. |
| lawFamily | string | yes | Body of procedural law the period is computed under. Only "hmk" (Code of Civil Procedure) is supported so far. |
| periodDays | integer | yes | Length of the statutory or judicial period, in days, counted from `periodStart`. |
| periodType | string | – | Free-text label for the period (e.g. "itiraz", "temyiz"), echoed back only — not mapped to a day count. |
| subjectToJudicialRecess | boolean | – | Whether this matter is subject to the judicial recess (adli tatil, HMK 104) instead of being exempt. Only affects the result when `lawFamily` is "hmk" and the computed last day falls in the 20 July -… |
| type | string | yes | Notification method. Determines which event `basisDate` refers to and whether the deemed-received date is same-day or shifted. |
No output schema declared.
No examples provided.
tr_validate Turkish ID & Number Validation ~131
Validates Turkish national ID, tax number, IBAN, licence plate, IMEI, barcodes, KEP, MERSİS, postal code and ISBN from one endpoint, with type auto-detection. Goes past a yes/no: resolves the bank behind an IBAN, the province behind a licence plate and the GS1 country prefix behind a barcode. Pure local computation — no upstream service is called, so latency is microseconds and the answer never changes for the same input.
| Name | Type | Req | Description |
|---|---|---|---|
| type | string | – | Omitted → inferred from the format. |
| value | string | yes | Value to validate. |
No output schema declared.
No examples provided.
tr_vat Turkish VAT & Withholding ~304
Splits a Turkish amount into net, VAT and (optionally) withholding: who pays the seller, who remits the withheld VAT. For invoice lines and checkout totals that have to show KDV dahil / hariç and, when the parties are in a withholding (tevkifat) situation, the split between what the buyer pays the seller and what the buyer remits to the tax office. Rates are 0, 1, 10 and 20 percent. Withholding is a fraction of the VAT (2/10 through 10/10), or a named code from the GİB partial-withholding list. The 2026 threshold (TRY 12,000 gross) is reported and compared with the amount, but `applies` is always null: whether withholding actually applies depends on the taxpayer status of both parties, which this endpoint does not know. Feeding it a fraction is not a legal opinion.
| Name | Type | Req | Description |
|---|---|---|---|
| amount | number | yes | The amount to tax. See amountIncludesVat. |
| amountIncludesVat | boolean | – | If true, `amount` is the gross (KDV dahil); if false, it is the net/matrah. |
| rate | – | – | VAT rate in percent. 0, 1, 10 or 20. |
| withholding | string | – | Withholding fraction such as "5/10", or a code from the list (reklam, tasima, hurda, isgucu…). |
No output schema declared.
No examples provided.
uuid_validate UUID Validate ~122
Validates UUID structure and reports version (1–5, 7) and RFC 4122 variant bits. Deterministic. Accepts dashed or 32-hex compact form. Reports the version nibble, variant (NCS / RFC 4122 / Microsoft / future), and whether the layout matches a known UUID version used in practice (v1–v5 and Unix-epoch v7). A valid structure is not proof the UUID was issued by a particular system.
| Name | Type | Req | Description |
|---|---|---|---|
| uuid | string | yes | UUID string, with or without hyphens. |
No output schema declared.
No examples provided.
vin_validate VIN Validation ~194
Validates a 17-character VIN: forbidden letters, ISO 3779 check digit, WMI region/manufacturer, model year and plant. Typos in a VIN are usually a forbidden letter (I, O, Q — they look like 1 and 0) or a shifted character. This rejects those, splits WMI/VDS/VIS, and names the manufacturer when the WMI is in a conservative built-in table. The 9th-character check digit is computed and compared, but a mismatch does not fail the VIN: it is mandatory under FMVSS 115 in North America and routinely ignored in Europe. `checkDigitMatch` tells you; `valid` stays true if the 17-character form is legal. This does not decode the full vehicle (engine, body, options) and does not prove the VIN was issued.
| Name | Type | Req | Description |
|---|---|---|---|
| vin | string | yes | Vehicle identification number, 17 characters. |
No output schema declared.
No examples provided.
What is the Temsor API — Turkey & EU business data MCP server?
Temsor API — Turkey & EU business data is an MCP server listed in the public MCP registry as com.temsor/api. Turkey & EU business data: validation, sanctions screening, parsing, FX and fuel price history. This page covers its hosted endpoint (https://api.temsor.com/mcp).
Is the Temsor API — Turkey & EU business data MCP server safe to use?
Temsor API — Turkey & EU business data scores 77 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the Temsor API — Turkey & EU business data MCP server expose?
Temsor API — Turkey & EU business data exposes 72 tools: ai_messages, bic_validate, container_validate, creditor_ref, ean_gtin, and 67 more. Their descriptions and schemas cost roughly 13,973 tokens of context every time the server is loaded.
Does the Temsor API — Turkey & EU business data MCP server require authentication?
No. We connected to Temsor API — Turkey & EU business data without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.
Is the Temsor API — Turkey & EU business data MCP server still maintained?
Temsor API — Turkey & EU business data is still listed as active in the MCP registry. We last reached this channel on 24 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.