European data validation tools for AI agents. Validates Portuguese NIF, IBAN for 18 European countries, VAT rates for all EU countries, Portuguese public holidays, and European number formatting.
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.
Average 4.6/5 across 11 of 11 tools scored.
Each tool targets a distinct resource and action. Multiple validators are differentiated by country and entity type (NIF, SIRET, TVA, IBAN). The only potential overlap is between calculate_working_days and get_portugal_holidays, but their purposes are clearly distinct: one counts days, the other lists holidays.
Most tools follow a lowercase verb_noun pattern, but country encoding is inconsistent: some use prefix (get_france_holidays), some suffix (validate_nif_es), and some omit it entirely (validate_nif, validate_siret). The verb set is consistent (get, validate, calculate, format), but the inconsistencies in noun structure prevent a perfect score.
11 tools is well within the ideal range for a domain-specific server. Each tool covers a distinct utility and the count is appropriate for the stated European business scope.
The server provides holiday data for France, Spain, and Portugal, but only calculates working days for Portugal. There is no working-days calculation for France or Spain despite equivalent holiday tools existing. Additionally, tax ID validation is limited to Portugal, Spain, and France, leaving other supported VAT/IBAN countries without fiscal identifier validation. These are notable gaps that affect agents handling non-Portuguese deadlines.
calculate_working_daysACounts the number of working days between two dates (inclusive), excluding Saturdays, Sundays, and all 10 Portuguese national public holidays. Returns { start_date, end_date, working_days: number }. Use when calculating Portuguese invoice payment deadlines (30/60/90 days), legal notice periods, project milestones, SLA response times, or any business process governed by Portuguese working days. Input dates must be in YYYY-MM-DD format.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | Yes | End date in YYYY-MM-DD format, inclusive. Example: '2026-01-31' | |
| start_date | Yes | Start date in YYYY-MM-DD format, inclusive. Example: '2026-01-01' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds behavioral details: inclusive date range, exclusion of Saturdays/Sundays and 10 Portuguese holidays, return object shape, and required date input format. 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?
Three sentences, each serving a purpose: core function, return value, and usage guidance. No redundant content, front-loaded with the most important 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?
For a simple calculator with two parameters and no output schema, the description includes all necessary info: function, exclusions, return shape, and usage contexts. Sibling tools are unrelated, so no missing context.
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 descriptions already cover both parameters with format and examples (100% coverage). The description adds minimal extra parameter semantics, only repeating the YYYY-MM-DD format requirement. Baseline of 3 applies.
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 the specific verb 'Counts' and resource 'number of working days between two dates', explicitly stating inclusivity and exclusions (weekends and Portuguese holidays). It also distinguishes itself from sibling tools like get_portugal_holidays which only lists holidays.
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 explicit use-case guidance: 'Use when calculating Portuguese invoice payment deadlines (30/60/90 days), legal notice periods, project milestones, SLA response times...' This clarifies when to choose this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
format_number_europeanAFormats a number using the locale conventions of a specific European country, applying the correct decimal separator and thousands separator. Returns { original: number, formatted: string, locale: string, country_code: string }. Different European countries use different conventions — Portugal and most of continental Europe use '1.234,56' (dot as thousands, comma as decimal), while Ireland uses '1,234.56'. Supports PT, ES, FR, DE, IT, NL, BE, PL, SE, DK, FI, AT, IE, GR, HU, RO. Use when displaying prices, measurements, or any numeric value to end users in a specific European country.
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | The numeric value to format. Example: 1234.56 | |
| decimals | No | Number of decimal places. Defaults to 2. Use 0 for whole numbers, 2 for prices. | |
| country_code | Yes | Two-letter country code for the target locale. Example: 'PT', 'FR', 'DE' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations establish read-only and idempotent behavior; description adds that it returns an object with original, formatted, locale, and country_code. It also discloses that different countries use different separators, giving concrete examples. This is valuable context beyond the annotations.
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 sentences with zero redundancy. Front-loads the action, includes a return type, examples, and supported countries. Everything 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?
For a simple formatting utility, the description covers purpose, usage, supported inputs, and output format. Since no output schema exists, the explicit return type is crucial and provided. No critical information is missing.
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 covers all three parameters with descriptions, so baseline is 3. The description adds the context of European decimal conventions and lists supported country codes, enriching the semantics of country_code. However, it doesn't add information about the 'number' or 'decimals' parameters beyond the schema, so a 4 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 formats a number using European locale conventions, with a specific verb ('Formats') and resource. It distinguishes itself from sibling tools (holidays, VAT, validation) by being the only formatting tool, and further differentiates internal behavior by country. The description is unambiguous and specific.
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 'Use when displaying prices, measurements, or any numeric value to end users in a specific European country', providing clear context. It also lists supported country codes and examples of conventions. While it doesn't mention alternatives, the sibling tools are clearly unrelated, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_france_holidaysAReturns all French national public holidays for a given year as a structured list. Each holiday includes { date: 'YYYY-MM-DD', name: string, name_en: string }. Returns 11 mandatory holidays defined by French law. Easter-dependent holidays (Easter Monday, Ascension Thursday, Whit Monday) are dynamically calculated for the requested year using the Anonymous Gregorian algorithm. Use when calculating French business deadlines, delivery dates, or scheduling tasks that must avoid non-working days in France.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | Calendar year as a 4-digit integer. Example: 2026 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the annotations: it specifies that 11 mandatory holidays are returned, explains that Easter-dependent holidays are dynamically calculated using the Anonymous Gregorian algorithm, and describes the return structure. This is useful information not present in the readOnlyHint or idempotentHint annotations.
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 five sentences, each earning its place: it states the core function, details the output structure, quantifies the holidays, explains the algorithm, and gives usage guidance. It is front-loaded with the primary purpose and contains no fluff.
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 one parameter and no output schema, the description is remarkably complete. It describes the output format explicitly, notes the exact count and algorithmic behavior, and provides a clear use case. The annotations cover safety and idempotency, so the description fully covers the remaining context.
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% for the single 'year' parameter, with a clear description ('Calendar year as a 4-digit integer. Example: 2026'). The tool description adds only 'for a given year,' which doesn't provide additional semantic value beyond the schema. Baseline 3 is appropriate for high schema coverage.
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 returns all French national public holidays for a given year as a structured list. It uses a specific verb ('Returns') and resource ('French national public holidays'), and distinguishes itself from sibling tools like get_portugal_holidays and get_spain_holidays by specifying 'French'.
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 clear usage context: 'Use when calculating French business deadlines, delivery dates, or scheduling tasks that must avoid non-working days in France.' It does not explicitly mention alternatives or when not to use the tool, but the context is sufficient for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_portugal_holidaysAReturns all Portuguese national public holidays for a given year as a structured list. Each holiday includes { date: 'YYYY-MM-DD', name: string, name_en: string }. Returns 10 mandatory national holidays defined by Portuguese law. Use when calculating business deadlines, delivery dates, payment due dates, SLA periods, or scheduling tasks that must avoid non-working days in Portugal. Does not include municipal or regional holidays (e.g. Lisbon June 13, Porto June 24) which vary by city.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | Calendar year as a 4-digit integer. Example: 2026 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and idempotentHint, and the description adds meaningful behavioral details: the exact output structure, the count (10 mandatory national holidays defined by law), and the exclusion of municipal/regional holidays. This goes beyond the annotation-only safety profile.
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?
Three sentences, front-loaded with purpose, then output structure, use cases, and exclusions. No unnecessary words; every 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?
For a simple tool with one parameter and no output schema, the description covers function, output format, scope, and limitations. An agent has enough context to decide when to use it and interpret results.
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?
The input schema fully documents the 'year' parameter with type and example, so description doesn't need to add more. The phrase 'for a given year' reinforces but doesn't extend schema information. Baseline 3 is appropriate given high schema coverage.
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 'Returns all Portuguese national public holidays for a given year as a structured list,' with specific verb and resource. It distinguishes from sibling country-holiday tools by explicitly naming Portugal and excluding municipal holidays.
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?
Explicit usage context is provided: 'Use when calculating business deadlines, delivery dates, payment due dates, SLA periods, or scheduling tasks that must avoid non-working days in Portugal.' It also gives a clear exclusion ('Does not include municipal or regional holidays'), guiding agents away from inappropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_spain_holidaysAReturns all Spanish national public holidays for a given year as a structured list. Each holiday includes { date: 'YYYY-MM-DD', name: string, name_en: string }. Returns 9 mandatory national holidays defined by Spanish law. Use when calculating business deadlines, delivery dates, or scheduling tasks that must avoid non-working days in Spain. Does not include regional holidays that vary by autonomous community (Catalonia, Madrid, Andalusia, etc.) — only nationally mandated holidays are returned.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | Calendar year as a 4-digit integer. Example: 2026 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds the exact return structure (date, name, name_en), the fixed count of 9 holidays, and the boundary that only national holidays are included, significantly enriching behavioral context beyond the annotations.
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 every sentence earns its place: it states the action, lists the return fields, specifies the count, explains the use case, and clarifies the exclusion of regional holidays. No redundancy or fluff.
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 one-parameter tool without an output schema, the description compensates fully by specifying the return structure, the fixed number of holidays, the intended use cases, and the limitations. It is complete for an agent to select and invoke the tool correctly.
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?
The single parameter 'year' is fully described in the schema with format and example (100% coverage). The description only refers to 'a given year' without adding new details, so the baseline of 3 applies.
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 the specific verb 'Returns' and identifies the resource 'Spanish national public holidays' for a given year. It also lists the return fields (date, name, name_en) and distinguishes itself from regional holidays and sibling country-specific tools (France, Portugal), making the purpose highly clear.
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 explicitly states 'Use when calculating business deadlines, delivery dates, or scheduling tasks that must avoid non-working days in Spain' and notes the exclusion of regional holidays, providing clear context. However, it does not name an alternative tool for regional holidays, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_vat_rateAReturns all VAT (Value Added Tax) rates for a given EU country — standard, reduced, intermediate, and super-reduced rates where applicable, as numeric percentages. Returns { country, standard, reduced?, intermediate?, superreduced? } for supported countries, or { error, available } listing all valid codes if the country is not found. Supports 18 EU member states: PT, ES, FR, DE, IT, NL, BE, PL, SE, DK, FI, AT, IE, GR, HU, RO, CZ, HR. Use when calculating EU cross-border invoice tax, determining correct rate for e-commerce checkout by customer country, generating compliant VAT breakdowns, or any workflow requiring accurate and current EU VAT rates per jurisdiction.
| Name | Required | Description | Default |
|---|---|---|---|
| country_code | Yes | Two-letter ISO 3166-1 alpha-2 country code. Example: 'PT' for Portugal, 'FR' for France, 'DE' for Germany |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint), the description discloses the return format ('Returns { country, standard, reduced?, intermediate?, superreduced? }'), error behavior for invalid countries ('{ error, available } listing all valid codes'), and that rates are numeric percentages. It also lists supported countries, providing full transparency for a read-only lookup.
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 efficient: the first sentence states the core function, followed by output format, supported countries, and use cases. Every sentence contributes meaningful information, with no redundancy or fluff.
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?
With no output schema, the description fully explains the return values, including conditional fields and error cases. It also specifies the supported country set and the numeric format of rates. This is complete for a simple read-only lookup tool with one parameter.
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?
The input schema already provides a detailed description for country_code (ISO 3166-1 alpha-2, examples). The description adds value by listing the 18 supported country codes, which helps the agent choose valid input values. Since the schema already covers parameter semantics well, this extra country list justifies a score above baseline.
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: 'Returns all VAT (Value Added Tax) rates for a given EU country' and specifies the types of rates (standard, reduced, intermediate, super-reduced). It also provides the output structure and supported countries, making it distinct from sibling tools that deal with holidays, validation, or working days.
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 explicitly details when to use the tool: 'Use when calculating EU cross-border invoice tax, determining correct rate for e-commerce checkout by customer country, generating compliant VAT breakdowns, or any workflow requiring accurate and current EU VAT rates per jurisdiction.' This gives clear context and implicitly differentiates it from other tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_ibanAValidates an IBAN (International Bank Account Number) using the ISO 13616 MOD-97 algorithm. Supports 18 European countries: PT, ES, FR, DE, IT, NL, BE, PL, SE, DK, FI, AT, IE, GR, HU, RO, CZ, HR. Returns { valid: boolean, country: string, iban: string } — country is extracted from the 2-letter prefix. Returns { valid: false, reason: string } for malformed input. Spaces are automatically stripped before validation. Use when validating supplier bank details for SEPA transfers, processing direct debit mandates, verifying payment data in e-commerce checkouts, or any workflow requiring a verified EU bank account number. Validates structure and checksum only — does not confirm account existence.
| Name | Required | Description | Default |
|---|---|---|---|
| iban | Yes | European IBAN with or without spaces. Example: 'PT50 0002 0123 1234 5678 9015 4' or 'PT50000201231234567890154' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond the readOnly/idempotent annotations by detailing the return object shapes for both valid and malformed input, the automatic whitespace stripping, and the limitation that account existence is not verified.
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 and well-organized: purpose, return values, usage context, and limitations are each covered in a few sentences 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?
With a single parameter and no output schema, the description provides all necessary context: return formats, error handling, supported countries, and practical use cases. It feels complete for the tool's complexity.
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?
The input schema already describes the iban parameter with an example. The description adds that spaces are automatically stripped, which is useful behavioral detail 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 IBANs using the ISO 13616 MOD-97 algorithm and lists supported countries. It distinguishes itself from sibling validation tools like validate_nif and validate_siret by focusing on bank account numbers.
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?
Explicit use cases are provided (SEPA transfers, direct debit mandates, e-commerce checkouts), and the description notes the tool checks structure/checksum only, not account existence. However, it does not mention when not to use it or suggest alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_nifAValidates a Portuguese NIF (Número de Identificação Fiscal) — the 9-digit tax identification number issued by the Portuguese Tax Authority (AT) to individuals and companies. Applies the official modulo-11 checksum algorithm to verify the check digit. Returns { valid: true, nif: string } for valid NIFs, or { valid: false, reason: string } for invalid format or failed checksum. First-digit rules are enforced: 1–3 for individuals, 5 for corporations, 6 for public entities, 7–8 for other entities, 9 for occasional taxpayers. Use when processing Portuguese invoices (faturas), onboarding suppliers, validating user registrations, or any fiscal compliance workflow. Does not query the AT database — offline format and checksum validation only.
| Name | Required | Description | Default |
|---|---|---|---|
| nif | Yes | 9-digit Portuguese NIF, with or without spaces. Example: '123456789' or '123 456 789' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond annotations by disclosing the modulo-11 checksum algorithm, first-digit rules for different entity types, return shape, and offline-only behavior. This provides rich behavioral context that annotations (readOnlyHint, idempotentHint) do not cover. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Six sentences, each informative and front-loaded with purpose. The enumeration of first-digit rules and multiple use cases adds slight verbosity, but overall the description is well-structured with no fluff.
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 one-parameter validation tool with no output schema, the description covers purpose, algorithm, return values, input rules, use cases, and limitations. It compensates for the absence of an output schema by explicitly describing the return shape and reason field.
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?
The input schema already covers the nif parameter with a full description and example (100% coverage). The description adds context about validation rules but does not add additional parameter syntax or format details beyond what the schema provides. Baseline 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 uses a specific verb 'Validates' with a precise resource 'Portuguese NIF' (expanded as Número de Identificação Fiscal). It clearly distinguishes from sibling tools like validate_nif_es by specifying the Portuguese jurisdiction and providing details on the tax authority (AT).
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 use cases (invoices, supplier onboarding, user registrations, fiscal compliance) and notes the offline-only limitation, which indicates when a DB-backed validation would be needed. Though it doesn't explicitly name an alternative tool, the context is strong and the sibling list makes the distinction obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_nif_esAValidates Spanish tax identification numbers — NIF (DNI, 8 digits + check letter, for Spanish citizens), NIE (Número de Identidad de Extranjero, starts with X/Y/Z, for foreign residents), and CIF (Código de Identificación Fiscal, letter + 7 digits + control, for companies). Automatically detects the document type. Returns { valid: boolean, type: 'NIF'|'NIE'|'CIF', id: string }. Use when processing Spanish invoices, e-commerce orders, supplier registrations, or any document requiring a verified Spanish fiscal identifier.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Spanish NIF, NIE or CIF with or without spaces. Examples: '12345678Z' (NIF), 'X1234567L' (NIE), 'B12345678' (CIF) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safe read-only nature is known. The description adds behavioral context beyond annotations by specifying the return format ({ valid, type, id }) and the automatic document-type detection, which clarifies how the tool behaves on various inputs. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three focused sentences: purpose and type formats, return behavior, and usage context. Information is front-loaded and every sentence earns its place with no filler 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?
With a single parameter and no output schema, the description covers the full behavior: accepted document types, auto-detection, return format, and concrete use cases. The schema provides input formatting details (e.g., spaces), so nothing essential is missing.
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?
The schema covers the 'id' parameter with examples at 100% coverage, so baseline is 3. The description enhances parameter understanding by explaining the NIF/NIE/CIF structures and stating that the tool automatically detects the type, which helps the agent understand the valid input space beyond the schema's raw examples.
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 opens with a clear verb and resource: 'Validates Spanish tax identification numbers' and explicitly enumerates the three document types (NIF, NIE, CIF) with format details. This distinguishes it from sibling tools like validate_nif and validate_iban, making its scope unambiguous.
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?
It provides a direct 'Use when' clause with concrete contexts: 'processing Spanish invoices, e-commerce orders, supplier registrations, or any document requiring a verified Spanish fiscal identifier.' However, it does not explicitly name when not to use it or mention alternatives, so it stops short of full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_siretAValidates a French SIRET (Système d'Identification du Répertoire des Établissements) number using the official Luhn algorithm. SIRET is a 14-digit number — the first 9 digits are the SIREN (company identifier) and the last 5 digits identify the specific establishment. Returns { valid: boolean, siren: string, establishment: string, siret: string }. Use when processing French invoices (factures), validating supplier registrations, or any B2B transaction requiring a verified French business establishment identifier. Handles the La Poste special case automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| siret | Yes | 14-digit French SIRET, with or without spaces/dashes. Example: '732 829 320 00074' or '73282932000074' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnly and idempotent hints; the description adds valuable behavioral details including the Luhn algorithm, automatic La Poste special case handling, input tolerance for spaces/dashes, and the exact return object shape. This exceeds what annotations convey.
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?
Five sentences, each conveying a distinct piece of information (purpose, structure, return value, use cases, special case) with no redundancy or filler. The most critical information is front-loaded.
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 description covers purpose, input format, output structure, algorithm, special case, and appropriate usage contexts. Despite lacking an output schema, the return value is explicitly described, making the tool fully self-contained.
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?
Although the schema already fully describes the single parameter with an example, the description adds semantic meaning by breaking down the SIRET into SIREN and establishment parts, enriching the understanding of what the parameter represents.
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 a French SIRET number using the official Luhn algorithm, which is specific and distinct from sibling validators like validate_iban or validate_nif. It also explains the SIRET structure, further clarifying the resource.
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 lists use cases (French invoices, supplier registrations, B2B transactions) which gives clear context. However, it does not mention when not to use this tool or explicitly reference alternatives among siblings, so it falls short of the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_tva_frAValidates a French TVA intracom (VAT) number — the EU VAT identifier for French companies. Format is 'FR' + 2 alphanumeric key characters + 9-digit SIREN. Returns { valid: boolean, key: string, siren: string, tva: string }. When the key is numeric, validates using the official formula: key = (12 + 3 × (SIREN mod 97)) mod 97. Use when validating French supplier VAT numbers, processing cross-border EU invoices, or any intra-EU transaction requiring a verified French VAT identifier.
| Name | Required | Description | Default |
|---|---|---|---|
| tva | Yes | French TVA intracom number with or without spaces. Example: 'FR 40 303 265 045' or 'FR40303265045' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return shape, the expected format, and the exact validation formula for numeric keys, which goes beyond the annotations' read-only/idempotent hints. This gives the agent insight into the tool's behavior and limitations.
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, with no fluff. The first sentence states the action, second gives format and return, third gives formula and usage. Every sentence adds value and it is efficiently 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?
For a simple read-only validation tool with one parameter, the description covers purpose, input format, output structure, validation logic, and use cases. There is no output schema, so the explicit return object description fills that gap completely.
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?
The schema already covers the 'tva' parameter with a description and example, so baseline is 3. The tool description adds the structural rule 'FR' + 2 alphanumeric key + 9-digit SIREN, which enriches understanding beyond the schema's simple 'with or without spaces' note. This additional format detail raises the score.
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 opens with 'Validates a French TVA intracom (VAT) number', which is a specific verb and resource. It clearly distinguishes from sibling validation tools by naming the French TVA and explaining it's for EU VAT identification, so the agent knows exactly its scope.
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 explicit usage context: 'Use when validating French supplier VAT numbers, processing cross-border EU invoices...'. This tells the agent when to select this tool, though it doesn't mention alternatives or exclusions, just the positive case.
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.
No comments yet. Be the first to start the discussion!
