Temsor API — Turkey & EU business data
Server Details
Turkey & EU business data: validation, sanctions screening, parsing, FX and fuel price history
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 13 of 13 tools scored.
Each tool targets a distinct resource and operation (e.g., email_verify vs. phone_validate vs. sanctions_screen). Even overlapping areas like IBAN validation are clearly scoped: iban_validate handles international IBANs, while tr_validate includes Turkish-specific IBAN validation among other Turkish identifiers. No two tools are ambiguous.
All names use lowercase with underscores, but the pattern varies: some are noun_verb (sanctions_screen, shipping_identify, tr_address_parse) while others are noun_noun (series_history, tr_business_days, tr_fuel_prices) or verb_noun (email_verify). The 'validate' tools are consistent in form (eu_vat_validate, iban_validate, phone_validate, tr_validate) but others break the pattern.
With 13 tools, the server is well-scoped for its purpose of Turkey and EU business data. Each tool covers a specific function (verification, parsing, data lookup) without redundancy or bloat. The count feels natural for the domain.
The tool set covers essential business data operations: identity validation (email, phone, tax IDs), address parsing, legal checks (sanctions), financial data (fuel prices, series history), and document handling (invoice parsing, money to words). Minor gaps exist (e.g., no Turkish company registry search or currency conversion), but the core workflows are well-supported.
Available Tools
14 toolsemail_verifyE-mail VerificationAInspect
Checks an e-mail address: syntax, whether the domain can actually receive mail, disposable and role-account detection, and typo correction.
No SMTP probing. Most competitors connect to the target server and try RCPT TO, which sounds thorough but produces a confident-looking number you cannot trust: most servers are catch-all, the big providers refuse to answer, and doing it in bulk gets the probing IP blacklisted. We report only what is provable — whether the domain has a mail exchanger, whether it is a known disposable service, whether the mailbox belongs to a role rather than a person, and whether the domain looks like a typo of a common one (gmial.com → gmail.com). Addresses are also normalised, so Gmail dots and +tags stop creating duplicate signups.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | E-mail address to check. | ||
| rejectRoleAccounts | No | ||
| rejectFreeProviders | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fully covers behavioral traits: what is checked, what is not (no SMTP), and why. Discloses limitations and rationale.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with core function, then provides rationale. Could be slightly shorter but well-organized and each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description fully explains what the tool returns and its capabilities. No missing essential information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one of three parameters (email) has a description in schema. The description does not explain 'rejectRoleAccounts' or 'rejectFreeProviders' parameters, leaving gaps despite mentioning role/disposable detection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it checks email syntax, domain deliverability, disposable/role detection, and typo correction. Distinguishes from competitors by specifying no SMTP probing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains when not to use SMTP probing and what the tool does instead. Lacks explicit when-to-use guidance but context is clear given sibling tools are unrelated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eu_vat_validateEU VAT Number ValidationAInspect
Validates an EU VAT number against the official VIES register, with per-country format checks and honest handling of upstream outages.
VIES is free but unreliable: member-state services drop out individually and a failed lookup can easily be mistaken for a rejection. Treating an outage as "invalid" means charging VAT to a customer who should have been exempt — an error with a price tag. So this endpoint never returns invalid when the service could not answer; it returns unknown and names the reason, and reports whether that country's service is currently up. Format is checked locally first, so an obvious typo never becomes an upstream call. Results are cached for 24 hours. Note that most member states do not publish the company name; when they do, it is returned.
| Name | Required | Description | Default |
|---|---|---|---|
| vatNumber | Yes | VAT number with or without the country prefix, e.g. "DE811907980". | |
| countryCode | No | Country code, when the number is given without a prefix. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of behavioral disclosure. It honestly describes that VIES can be unreliable, outlines the nuanced handling of outages (returning 'unknown' instead of 'invalid'), local format pre-checks, caching, and the optional return of company names. This is exemplary transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet comprehensive, with each sentence adding value. It begins with the core purpose, then clearly explains edge cases, caching, and limitations. No redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description covers important behavioral aspects like error handling and caching. It could explicitly describe the return structure (e.g., fields like 'valid', 'unknown', 'country', 'name'), but it implies enough from the explanation of 'unknown' and company name returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are described in the schema (100% coverage). The description adds useful context, such as the vatNumber being acceptable with or without a country prefix, and that countryCode is optional when the prefix is present. This enhances understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates EU VAT numbers against the VIES register with local format checks. It is distinct from siblings like email_verify or iban_validate, which handle different validation tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool for EU VAT validation and provides important context about handling VIES outages and caching. However, it does not explicitly state when not to use it or mention alternative tools, though the purpose is specific enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
iban_validateIBAN ValidationAInspect
Validates an IBAN from any of 70+ countries: checksum, country length and in-country account structure, and resolves the bank and branch codes.
Most free libraries stop at the mod-97 checksum. That only says the digits are self-consistent — not that the number could exist in that country. This checks the country's BBAN structure too, so a wrong-length or wrong-shaped account is rejected before your payment file reaches the bank. When only the two check digits are wrong, the correct ones are computed and returned as a suggestion, because that is what people actually mistype. Turkish IBANs additionally resolve to the bank name.
| Name | Required | Description | Default |
|---|---|---|---|
| iban | Yes | IBAN, boşluklu veya boşluksuz. | |
| expectCountry | No | Beklenen ülke kodu (ISO 3166-1 alfa-2). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the validation steps (checksum, BBAN structure), special handling of Turkish IBANs, and suggestion of corrected check digits. No contradictions. It is transparent about its behavior beyond basic schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise with 3 sentences. It front-loads the main capability, then differentiates, then adds edge-case details. Every sentence adds value, though it could be slightly more terse without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, so the description should cover return values. It mentions returning corrected check digits as a suggestion but does not describe the full response structure or error handling. The tool has only 2 params, so completeness is moderate but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add extra meaning beyond what the schema already provides (e.g., 'IBAN, boşluklu veya boşluksuz' and 'Beklenen ülke kodu'). It provides context on validation behavior but not on parameter specifics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Validates' and clearly states the resource (IBAN from 70+ countries) and the scope of validation (checksum, country length, account structure, bank resolution). It distinguishes itself from simpler checksum-only libraries, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool over siblings like email_verify or eu_vat_validate. It implicitly suggests use before payment files and compares to free libraries, but does not provide clear when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
phone_validatePhone Number ValidationAInspect
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 | Required | Description | Default |
|---|---|---|---|
| phone | Yes | Phone number in any common format. | |
| defaultCountry | No | ISO 3166-1 alpha-2 country to assume when the number has no international prefix. Defaults to TR. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It fully discloses behavioral traits: validates, normalizes, classifies, resolves province, and explicitly states that it does not claim current operator, returning `originallyAllocatedTo` with a caveat. The caveat about number portability adds valuable context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and is concise. Each sentence adds value, covering functionality, use cases, and limitations. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description provides a complete picture: input format, processing details, output format (E.164 and national notation), and limitation about operator detection. It covers all essential aspects for selecting and using the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds extra meaning: defaultCountry defaults to TR, phone can be in any common format, and explains that Turkish numbers are handled in depth. This is additional context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates, normalizes to E.164, classifies line type, and resolves province for Turkish landlines. It specifies a use case (signup/checkout flows) and distinguishes from siblings like email_verify and eu_vat_validate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (flows needing canonical form) and what it deliberately does not do (report current mobile operator), with reasoning about portability. Provides clear guidance on limitations and what to expect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sanctions_screenSanctions & PEP ScreeningAInspect
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 | Required | Description | Default |
|---|---|---|---|
| asOf | No | Screen against the lists as they stood on this date. Limited by when our archive begins. | |
| name | Yes | Name to screen — person or organisation. | |
| type | No | Restrict to one subject type. Narrowing this removes most false positives. | any |
| limit | No | ||
| country | No | Known country or nationality. | |
| sources | No | Defaults to all lists. | |
| minScore | No | Score floor. 0.92+ reads as a match, 0.80+ as possible. | |
| birthYear | No | Known birth year. The single strongest false-positive filter available. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It details transliteration, fuzzy matching, hit explanation (matched name, alias strength, birth year/country comparison). Discloses that asOf is bounded by archive start. Does not mention rate limits or authentication, but the behavioral coverage is strong for a screening tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single well-structured paragraph. Front-loaded with purpose, then details on matching, hit explanation, and parameter guidance. Every sentence contributes meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, and no annotations, the description provides comprehensive context on behavior and parameter usage. Output format is hinted ('every hit explains itself') but could be more explicit. Still, adequate for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 88%, so baseline is 3. Description adds significant value: birthYear is 'the single strongest false-positive filter', asOf is for auditors and bounded, sources default to all. This extra context helps the agent use parameters effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool screens a name against six official sanctions lists with fuzzy matching. The verb 'screens' and resource 'name against six official sanctions lists' are specific. No sibling tools overlap with sanctions screening, so differentiation is inherent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides clear guidance on when to use: screening names for sanctions compliance. Recommends providing birthYear to reduce false positives and asOf for historical screening. Missing explicit when-not-to-use or alternatives, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
series_historyTime Series HistoryAInspect
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 | Required | Description | Default |
|---|---|---|---|
| to | No | Bitiş tarihi (dahil). | |
| from | No | Başlangıç tarihi (dahil). | |
| limit | No | ||
| fillGaps | No | ||
| seriesId | No | Seri kimliği, ör. `tcmb.usd`. Boş bırakılırsa katalog döner. | |
| includeEvidence | No | Her nokta için kaynak URL ve içerik özetini döndürür. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: returns change statistics, source receipts per point, normalization of units, and that fillGaps carries values across holidays. No annotations exist, so the description carries full burden; it covers safety (non-destructive) and data provenance well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences with no wasted words. Front-loads the core purpose, then provides examples and parameter explanations. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Coverage is high for a tool with no annotations and no output schema: explains main function, parameter behaviors, and data provenance. Minor gap is not detailing the 'change statistics' output, but overall complete given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond the input schema: explains the special behavior of empty seriesId (catalogue listing), normalizes currency quotes, and describes the effect of fillGaps and includeEvidence on the output. The schema descriptions are in Turkish; the English description provides essential context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Returns the accumulated history of public data series', explicitly identifies the resource (time series data), and distinguishes from sibling tools (validation tools) by focusing on data retrieval. Examples like tcmb.usd add specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: leaving seriesId empty lists the catalogue, and explains the effects of fillGaps and includeEvidence. No explicit when-not-to-use or alternatives are given, but the usage is well implied and distinct from unrelated siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
shipping_identifyTracking Number IdentificationAInspect
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 | Required | Description | Default |
|---|---|---|---|
| country | No | Destination or origin country hint, e.g. "TR". Narrows the candidates. | |
| trackingNumber | Yes | Tracking number, with or without spaces and dashes. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully bears transparency burden. It discloses: returns ranked candidate list for ambiguous cases, fully validates UPU S10 numbers with check digit, uses 'not-verified' for unconfirmed checksums, and explicitly states delivery status is out of scope. This is highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with core purpose, then explains rationale for candidate list and limitations. Each sentence adds value, though slightly long. Still efficient given complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is medium complexity with no output schema. Description covers purpose, behavior, logic for ambiguous results, and explicitly excludes delivery status. Only minor gap is lack of explicit return format (but 'ranked candidate list' is sufficient).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by explaining that country parameter is a hint to narrow candidates, and that tracking number can include spaces/dashes. This goes beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool identifies carrier, validates checksum, and returns tracking link. It distinguishes from sibling tools by focusing on tracking number identification, while siblings handle email, VAT, IBAN, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides context for when to use (order systems routing tracking pages) and explains limitations (Turkish carrier overlap, candidate list). Does not explicitly list when not to use or alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tr_address_parseTurkish Address ParserAInspect
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 | Required | Description | Default |
|---|---|---|---|
| address | Yes | Serbest metin adres. | |
| defaultProvince | No | Adreste il geçmiyorsa varsayılacak il. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behavioral traits: handling of abbreviations, cross-checking province/postcode, repairing misspellings, returning confidence score, and listing unparsed components with 'nothing is dropped silently.' This provides full transparency with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two paragraphs with the main purpose front-loaded in the first sentence. Every sentence adds value—no fluff. It uses parallel structure and lists outcomes without bloating.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains what the tool returns (components, confidence score, unparsed list). It covers the tool's niche for Turkish address parsing. Slightly lacking on output format (e.g., JSON), but the description is functionally complete for an AI agent to understand the tool's capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description adds value by explaining how the input address is parsed into components and the handling of abbreviations, confidence score, and unparsed fields. It goes beyond the schema's simple descriptions, providing operational context that aids agent understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Splits a free-form Turkish address into neighbourhood, street, building, floor, flat, district, province and postcode.' The verb 'splits' and the specific resource 'free-form Turkish address' make the purpose unambiguous. It also distinguishes itself from sibling tools (e.g., email_verify, phone_validate) by focusing on address parsing, which no other sibling does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context: it handles abbreviation chaos, cross-checks province/postcode, repairs misspellings, and returns a confidence score. It explicitly states 'Built for shipping, checkout and CRM systems that receive Turkish addresses typed by humans,' which implies when to use. However, it does not explicitly state when not to use the tool or compare it to alternatives, though no direct alternatives exist among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tr_business_daysTurkish Business DaysAInspect
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 | Required | Description | Default |
|---|---|---|---|
| end | No | Verilirse aradaki iş günü sayılır. | |
| start | Yes | Başlangıç tarihi (YYYY-AA-GG). | |
| addDays | No | Bu kadar İŞ GÜNÜ ekle/çıkar. | |
| countHalfDaysAsWork | No | Arife yarım günleri iş günü sayılsın mı? |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It transparently explains how religious holidays are handled (table lookup, confirmed:false for unannounced years) and defaults for half-day eves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with purpose, then details, then use cases. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the description covers holiday handling and use cases. Missing details on the return format (e.g., what 'confirmed:false' looks like) but still adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds value by explaining the counting vs adding distinction and the meaning of countHalfDaysAsWork, beyond the schema's Turkish descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds or counts business days accounting for Turkish holidays, with specific mention of religious feasts. This distinguishes it from sibling validation/parsing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description suggests use cases like delivery promises and SLA clocks, but does not explicitly state when not to use it or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tr_fuel_pricesTurkey Fuel PricesAInspect
Petrol, diesel and heating-oil pump prices for all 81 Turkish provinces, including the price in force on any past date.
Today's pump price is on a public web page; the archive is not. This endpoint answers the question that actually costs money: 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 | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| asOf | No | Price in force on this date (YYYY-MM-DD). Omitted → latest known price. | |
| from | No | With `to`: return the price changes in this window. | |
| product | No | Fuel product. Omitted → every product available for that province. | |
| province | No | Province name or plate code — "Ankara", "istanbul" or 34. Leave empty to list covered provinces. | |
| includeDistricts | No | Adds districts whose pump price differs from the province reference price. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It discloses that if no price change occurred, the previous price is carried forward with `carriedForward: true`. It explains change events with percentage moves and that each figure includes a source URL and content hash for audit. This provides meaningful behavioral context beyond a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose. Each subsequent sentence adds useful detail about parameters, edge cases, and audit features. Although slightly long, every sentence contributes meaning, making it efficient for an agent to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and no output schema, the description is highly complete. It explains what is returned (price, effectiveFrom, carriedForward flag, percentage moves, source URL, content hash) and covers all parameters' behaviors. It leaves no major gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 83%, so most parameters already have descriptions. The description adds value by explaining the `asOf` date logic, the `from`/`to` window for change events, and that empty `province` lists covered provinces. It also mentions the `includeDistricts` option. This enriches understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Petrol, diesel and heating-oil pump prices for all 81 Turkish provinces, including the price in force on any past date.' This clearly identifies the tool's purpose (providing fuel prices) and its unique scope (historical data by province). It is well-distinguished from sibling tools which deal with validation, address parsing, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool's value over public pages: 'Today's pump price is on a public web page; the archive is not. This endpoint answers the question that actually costs money.' It also provides guidance on using parameters like `asOf` and `from/to` for historical queries. However, it does not explicitly state when not to use the tool or list alternative approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tr_invoice_buildTurkish e-Invoice BuilderAInspect
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 | Required | Description | Default |
|---|---|---|---|
| id | No | Invoice number. Omit and supply `series` to have it built from the series and sequence. | |
| uuid | No | Document UUID (ETTN). Generated when omitted. | |
| lines | Yes | ||
| notes | No | ||
| series | No | Three-letter series code, used with `sequence`. | |
| profile | No | TEMELFATURA: no formal objection flow. TICARIFATURA: buyer may accept/reject. EARSIVFATURA: buyer is not an e-Invoice user. | TEMELFATURA |
| currency | No | ISO 4217. Anything other than TRY requires `exchangeRate`. | TRY |
| customer | Yes | ||
| sequence | No | Sequence number within the series and year. | |
| supplier | Yes | ||
| issueDate | Yes | ||
| issueTime | No | ||
| exchangeRate | No | Units of TRY per one unit of `currency`. | |
| amountInWords | No | Adds the payable amount written out in Turkish words as a note, the way invoices require. | |
| invoiceTypeCode | No | SATIS | |
| orderReferenceId | No | ||
| despatchDocumentId | No | Delivery note number, if the goods shipped separately. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behaviors: total recomputation (ignoring user totals), VKN/TCKN checksum verification, and amount-in-words generation. It does not mention error handling or idempotency, but covers the main behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise paragraphs. The first sentence captures the main purpose, and the second paragraph elaborates on key behaviors without redundancy. Every sentence adds value, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (17 parameters, nested objects, no output schema), the description is quite complete: it explains what the tool does, its limitations (no signing/transmission), validations, and the rationale (kuruş rounding). It lacks details on output format and authentication, but overall covers the essentials.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 53%, so baseline is 3. The description adds context: explains why totals are ignored, that id/uuid can be omitted, and validates tax numbers. This supplements the schema, enhancing parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a UBL-TR e-Invoice or e-Archive XML from JSON, specifying verb and resource. It distinguishes from siblings like tr_invoice_parse (parsing) and tr_money_to_words (money to words) by focusing on document generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides solid context for use (selling into Türkiye, need for UBL-TR) and explicitly states what it does not do (sign or transmit), guiding the agent on next steps. However, it does not explicitly compare to sibling tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tr_invoice_parseTurkish e-Invoice (UBL-TR) ParserAInspect
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 | Required | Description | Default |
|---|---|---|---|
| xml | Yes | UBL-TR e-Fatura / e-Arşiv XML içeriği. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: handles any namespace prefix, normalizes single-line documents to arrays, and reports amount mismatches in warnings. With no annotations, this is good coverage, though it doesn't mention if the operation is read-only or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences and front-loaded with the main purpose. The second sentence adds valuable technical details. The third sentence is slightly marketing-oriented but provides context. Could be more concise but effectively conveys information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's single parameter and no output schema, the description adequately explains the output structure (parties, line items, taxes, totals) and mentions warnings. However, it could provide more on error handling or expected XML structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (xml) with 100% schema coverage. The schema already describes it as UBL-TR content. The description adds no extra semantic details beyond what the schema provides, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool turns UBL-TR e-Invoice or e-Archive XML into clean JSON, specifying parties, line items, taxes, and totals. This is distinct from sibling tools which are validation and other unrelated services.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use (e-Invoice parsing) but does not explicitly state when not to use or mention alternative tools. Sibling list helps distinguish but no direct exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tr_money_to_wordsAmount to Turkish WordsAInspect
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 | Required | Description | Default |
|---|---|---|---|
| style | No | Çıktı harf biçimi. | lower |
| amount | Yes | Tutar. "1.234,56" ve 1234.56 biçimlerinin ikisi de kabul edilir. | |
| currency | No | TRY | |
| wrapHash | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral transparency. It discloses key behaviors: applies Turkish-specific rules, accepts two number formats ("1.234,56" and "1,234.56"), automatically detects format. It does not mention idempotency or side effects, but as a pure conversion tool, these are implicitly safe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: two short paragraphs. The first sentence states the purpose clearly, and the second paragraph adds necessary detail. Every sentence adds value with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and the description does not explain the return format (e.g., how the Turkish words are structured). Given 4 parameters and no output documentation, the description is incomplete. It also lacks error handling or edge case behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (2 of 4 parameters have descriptions in schema). The description adds no additional parameter-specific information beyond stating the tool accepts number formats. For example, 'style', 'currency', and 'wrapHash' have no further explanation. The description does not compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts monetary amounts to Turkish words for invoices, cheques, and promissory notes. It specifies the specific Turkish rules applied (e.g., 'bin' not 'bir bin'), distinguishing it from generic libraries. This is a clear verb+resource+scope with differentiation from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the tool is mandatory for Turkish e-invoices, cheques, and notes, providing clear usage context. However, it does not explicitly state when not to use this tool or compare it to siblings, though siblings are for different purposes (validation, formatting) making the context sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tr_validateTurkish ID & Number ValidationAInspect
Validates Turkish national ID, tax number, IBAN, licence plate, IMEI and barcodes 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 | Required | Description | Default |
|---|---|---|---|
| type | No | Belirtilmezse biçimden otomatik tespit edilir. | auto |
| value | Yes | Doğrulanacak değer. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses that validation is local, deterministic, and microseconds-fast, which is helpful. However, it does not mention error handling, return format, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences. First sentence covers core function and scope; second sentence adds valuable behavioral detail. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description does not specify the return structure (e.g., boolean or object with details). It mentions extra resolution but lacks completeness on what the agent can expect from the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions, but the description adds meaning by explaining type auto-detection and the extra resolution (bank, province, prefix) that the parameters enable, beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it validates multiple Turkish identifiers (ID, tax number, IBAN, etc.) with type auto-detection, and distinguishes from siblings by offering extra resolution (bank, province, GS1 prefix) in a single endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for Turkish validation with extra info ('goes past a yes/no'), but does not explicitly state when to use this tool versus siblings like iban_validate or when not to use it. No alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!