LatAm govt data, cited to source: rates, VAT, tax, wages, holidays, FX. 22 countries; Brazil free.
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.3/5 across 10 of 10 tools scored.
Each tool targets a distinct operation: compliance check, tax computation, VAT breakdown, day counting, holiday retrieval, series value/history/snapshot, catalog listing, and settlement date calculation. Even where underlying data overlaps (e.g., minimum wage as a series), the outputs and use cases are clearly differentiated.
Nine of ten tools follow a clear verb_noun pattern (check_minimum_wage, compute_income_tax, compute_vat, count_working_days, get_public_holidays, get_series, get_series_history, get_snapshot, list_series). The outlier is settlement_date, which uses a noun phrase rather than a verb-based name, though it remains unambiguous and readable.
With 10 tools, the server is well-scoped for its reference-data purpose, covering tax, wages, holidays, working days, series discovery, and settlement dates. Each tool earns its place without redundancy or bloat.
The surface provides comprehensive coverage: discovery via list_series, current/historical data via get_series and get_series_history, a full snapshot, tax computations, wage compliance, public holidays, working day counts, and settlement date calculations. There are no obvious gaps or dead ends for the intended domain.
check_minimum_wageAInspectPAID ($0.05). Compliance verdict: is a salary at, above or below the country's statutory minimum wage? Returns verdict, margin, the statutory floor and the legal instrument it rests on. Honest statuses when no enforceable floor exists or the period doesn't match the floor's period (cross-period conversion is never guessed). Pass api_key if you have one; otherwise the response explains how to pay via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Wage to check, in the country's own currency | |
| period | Yes | Period the amount covers — must match the statutory floor's period | |
| api_key | No | API key (bypasses x402; metered for invoicing) | |
| country | Yes | ISO country code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the paid nature ($0.05), the return fields (verdict, margin, floor, legal instrument), and honesty for edge cases (missing floor, period mismatch). Adding the exact format of the verdict would improve it further.
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 sentences) but the opening 'PAID ($0.05)' is somewhat jarring. It is front-loaded with the payment info, which is important. Minor improvement could be better integration.
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 the tool's inputs, outputs (verdict, margin, floor, legal instrument), edge cases (missing floor, period mismatch), and payment methods. Without an output schema, this is fairly complete but could specify the possible verdict values.
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 context for the api_key parameter (payment method) and reinforces period matching. This adds modest value 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 verb ('checks' by implication) and the resource (salary vs statutory minimum wage), and it is distinct from all sibling tools which deal with tax, holidays, series, 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 function (compliance verdict) and key constraints (period must match, no cross-period conversion). It does not explicitly state when not to use it or list alternatives, but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compute_income_taxAInspectPAID ($0.05). Statutory income tax on a TAXABLE-income figure using the country's verified marginal bracket schedule, with full per-bracket workings, effective rate and marginal rate. Handles inflation-indexed tax units (Colombia UVT, Chile UTA, Peru UIT, Uruguay BPC) — you pass local currency. IMPORTANT: this is tax on taxable income, NOT net take-home pay — reliefs/allowances and social-security contributions are the caller's concern and are not applied (see the response scope_note). Pass api_key if you have one; otherwise the response explains how to pay via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | API key (bypasses x402; metered for invoicing) | |
| country | Yes | ISO country code | |
| taxable_income | Yes | Taxable income in the country's local currency, in the schedule's own period basis (annual for most; monthly for Côte d'Ivoire, Uganda, Ethiopia, Costa Rica) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses the tool is paid ($0.05), handles inflation-indexed tax units, and clarifies the scope (not net take-home pay). It also mentions response includes scope_note and explains api_key usage. Could be improved by stating failure modes, but overall sufficient.
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 (a few sentences) and front-loaded with cost and purpose. Every sentence adds essential information without fluff. Well-structured for quick parsing.
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 complex tool without output schema, the description covers key aspects: cost, scope, response details (per-bracket workings, effective rate, marginal rate, scope_note), and indexed unit handling. Minor gaps like missing return format are acceptable 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?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining that taxable_income should be in local currency and in the schedule's period basis, and clarifies api_key bypasses x402. This context goes beyond the 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 computes statutory income tax on taxable income using marginal bracket schedules, including per-bracket workings. It specifies the resource (income tax) and verb (compute) implicitly. The tool is distinct from siblings like check_minimum_wage and compute_vat, as it focuses on income tax calculation.
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 computing income tax on taxable income) and what it does NOT cover (reliefs, allowances, social-security contributions). It also mentions the payment mechanism via api_key or x402. However, it does not explicitly contrast with sibling tools like compute_vat, relying on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compute_vatAInspectPAID ($0.02). VAT breakdown for an amount: net, tax and gross using the country's current statutory rate, including per-levy components where the rate is composite (e.g. Ghana VAT + NHIL + GETFund). mode=add treats the amount as net; mode=extract backs VAT out of a gross amount. Pass api_key if you have one; otherwise the response explains how to pay via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | add = amount is net (default); extract = amount is gross | |
| amount | Yes | Amount in the country's own currency | |
| api_key | No | API key | |
| country | Yes | ISO country code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description fully bears the burden. It discloses the cost ($0.02), reliance on current statutory rates, composite rate handling (e.g., Ghana VAT+NHIL+GETFund), and behavior without api_key (explains x402 payment).
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, dense paragraph with no redundant words. Front-loaded with key action and resource, then details. 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?
Given no output schema, the description explains what is computed (net, tax, gross) and composite rate details. However, it does not specify the return format or structure, which could be helpful for an agent to parse 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?
Schema already covers all 4 parameters (100% coverage). Description adds critical nuance: mode=add treats amount as net, mode=extract backs VAT out of gross, and api_key is optional with fallback explanation. Enhances understanding 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?
The description clearly states the tool computes VAT breakdown (net, tax, gross) using current statutory rates, including composite rates. It distinguishes from siblings (e.g., compute_income_tax) by focusing specifically on VAT.
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 explains when to use mode=add vs mode=extract and mentions api_key fallback. However, it does not explicitly state when not to use this tool or compare to siblings, though sibling names are distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
count_working_daysAInspectPAID ($0.02). Working days in a date range for a country: weekends (Egypt's Fri–Sat handled) and statutory public holidays applied, with the holidays hit by name and the next working day after the range. Range max 366 days. Pass api_key if you have one; otherwise the response explains how to pay via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Range end, YYYY-MM-DD, inclusive | |
| from | Yes | Range start, YYYY-MM-DD, inclusive | |
| api_key | No | API key | |
| country | Yes | ISO country code | |
| subdivision | No | Optional ISO 3166-2 region code (e.g. 'DE-BY') to apply that region's statutory holidays on top of the national calendar. Regions are listed under `subdivisions` by get_public_holidays. Unknown code is refused free with the list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses payment, range limits, and special weekend handling for Egypt. It does not cover error behavior or rate limits, but provides essential behavioral 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?
Three concise sentences front-load the paid nature, clearly state functionality, limits, and API key guidance. 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?
Covers main functionality, inputs, and a key constraint (max 366 days). Lacks explicit output schema but mentions returned elements (holidays, next working day). Sufficient 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?
Schema coverage is 100%, baseline 3. The description adds context about weekends per country, max range implying from/to constraints, and optional api_key usage, enhancing the 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 it counts working days in a date range for a country, handling weekends and holidays, and distinctively mentions returning holiday names and the next working day, differentiating it from siblings like get_public_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?
It indicates the tool is paid, notes a max range of 366 days, and advises on API key usage or payment instructions. However, it does not explicitly contrast with siblings or provide 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.
get_public_holidaysAInspectFREE. Official public-holiday calendar for a supported country, including gazetted movable holidays, with the official government source cited. Some countries also carry sub-national calendars (e.g. the German Laender): the subdivisions field lists them, and passing subdivision (ISO 3166-2, e.g. 'DE-BY') returns the national calendar merged with that region's statutory days.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | ISO country code | |
| subdivision | No | Optional ISO 3166-2 region code (e.g. 'DE-BY'). Returns national + that region's statutory holidays, each tagged national/regional. Omit for the national calendar. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description covers key behavioral traits: it is free, uses official sources, returns national and optionally regional calendars, and tags holidays. Missing details like rate limits or authentication, but overall informative.
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 but contains all essential information in a single paragraph. It is well-structured, starting with the key feature (free) and then detailing the functionality. Slightly verbose with 'e.g.' examples, but overall efficient.
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 lacks details on the exact response format. It mentions tagging but does not specify fields like holiday names, dates, etc. While adequate for a simple tool, more completeness would help.
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 schema coverage is 100%, the description adds meaningful context: explains the subdivision parameter's ISO 3166-2 format, effect on output, and the existence of a 'subdivisions' field. This goes beyond the schema's minimal 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 retrieves public holiday calendars for supported countries, with explicit mention of official sources and sub-national support. This distinguishes it from sibling tools which focus on wage, tax, or workday calculations.
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 (retrieving holiday calendars) and provides guidance on optional subdivision parameter usage. However, it does not explicitly state when not to use it or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_seriesAInspectPAID ($0.005). Current value of a reference series — e.g. series=policy-rate, vat, minimum-wage. Every value carries its official source citation, effective date, last-confirmed date and staleness flag. Pass api_key if you have one; otherwise the response explains how to pay via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| series | Yes | Series id, e.g. policy-rate, vat, minimum-wage | |
| api_key | No | API key (bypasses x402; metered for invoicing) | |
| country | Yes | ISO country code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the cost ($0.005), payment flow via x402/api_key, and the response contents (source citation, effective date, last-confirmed date, staleness flag). It does not mention potential side effects, but as a read-only query that is implicitly safe. This is strong value beyond 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 two sentences, with the cost flag front-loaded and no filler. Every sentence adds value: purpose, examples, response details, and payment instructions. It is optimally concise.
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 provides a rich overview for a simple 3-parameter tool: cost, payment, return data (including staleness). It omits the 'country' parameter from the prose, but the schema handles that. Given no output schema, the explanation of response fields is valuable and mostly complete.
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 descriptions already handle parameter meaning. The description adds examples for 'series' and clarifies 'api_key' behavior (bypasses x402, metered). It does not mention 'country', which is a slight gap, but the schema covers it. Overall, the description enhances 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 states 'Current value of a reference series' with concrete examples (policy-rate, vat, minimum-wage), clearly distinguishing it from siblings like 'get_series_history' (historical) and 'list_series' (catalog). The verb+resource pattern is explicit and 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?
The description clearly implies this tool is for retrieving current values, not historical or lists. However, it does not explicitly mention when not to use it or name alternative tools. The 'Current value' phrasing gives strong contextual guidance, but lacks explicit exclusion statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_series_historyAInspectPAID ($0.005). Historical values of a reference series with effective date ranges, optionally filtered by from/to (YYYY-MM-DD). Pass api_key if you have one; otherwise the response explains how to pay via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Latest effective date, YYYY-MM-DD | |
| from | No | Earliest effective date, YYYY-MM-DD | |
| series | Yes | Series id | |
| api_key | No | API key | |
| country | Yes | ISO country code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the $0.005 fee, the optional api_key, and the x402 payment flow, which are critical behavioral details beyond the schema. It stops short of describing response structure or error handling, but the essential traits are covered.
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 sentences, front-loaded with the cost warning, then a clear purpose statement, and payment instructions. Every sentence provides necessary context without 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?
Despite no output schema and no annotations, the description covers the core purpose, the paid nature, payment handling, and optional date filters. It lacks response format details, but for a data retrieval tool with fully described parameters, this is 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 description coverage is 100%, so the baseline is 3. The description adds little beyond the schema: it mentions from/to YYYY-MM-DD format and the api_key, but these are already documented. It reinforces that from/to are optional, which is inferable from the schema's required fields.
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 that the tool provides 'Historical values of a reference series with effective date ranges', which distinguishes it from sibling tools like get_series or get_snapshot. The verb is implicit but the resource and action are 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?
The description implies usage when historical values with effective dates are needed, but it does not explicitly mention alternatives or conditions for use. No exclusions or comparison to siblings are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_snapshotAInspectPAID ($0.02). Snapshot of every series for every country in one call. Pass api_key if you have one; otherwise the response explains how to pay via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | API key |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses cost ($0.02) and payment method (x402), but no other behavioral details; annotations absent so description carries full burden.
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 sentences conveying cost, scope, and usage hint with 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?
Covers essential aspects for a simple tool with one optional param and no output schema; slight gap on response format but acceptable.
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 value beyond schema by explaining api_key is optional and fallback behavior; schema coverage is 100%.
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 'Snapshot of every series for every country in one call' with specific verb and resource, distinguishing it from series-specific siblings.
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 guidance on api_key parameter and payment fallback, but lacks explicit when-to-use or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_seriesAInspectFREE. Catalog of all latamref reference-data series: supported countries, series ids, descriptions, freshness metadata and per-series URLs. Call this first to discover what data exists.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions 'FREE' and lists output fields, but does not disclose pagination, response size, or any limitations. Adequate but could provide more behavioral 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?
Two short sentences with no fluff. Critical info ('FREE', catalog contents, usage advice) is front-loaded and concise.
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 zero parameters and no output schema, the description covers the tool's purpose and output contents. Lacks explicit format details but is sufficient for a simple discovery 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?
No parameters exist, so baseline 4 applies. The description adds value by detailing what the output contains, which compensates for the lack of schema details.
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 is a catalog of all latamref reference-data series, listing specific contents like countries, IDs, descriptions, freshness metadata, and URLs. It distinguishes from siblings like get_series or get_snapshot by being the discovery tool.
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 suggests calling this first to discover data, positioning it as a precursor to other series tools. No explicit exclusions, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
settlement_dateAInspectPAID ($0.05). Settlement/value date: the date n business days after a trade date, computed on the INTERSECTION of the calendars you name, with a per-day trail showing every skipped day and why, on which calendar. Supply business_days for a cycle you are trading under, or market + instrument_class to have a settlement cycle applied that we cite to its primary source (e.g. US equities T+1 under 17 CFR 240.15c6-1(a); UK gilts T+1 by DMO convention, which is NOT the T+2 equity cycle; Japan equities T+2 but JGBs T+1). Calendars are NATIONAL statutory holiday calendars with researched statutory weekend rules (Israel Saturday-only, Gulf Friday+Saturday, India Sundays plus the 2nd and 4th Saturday), NOT CSD or exchange calendars — each response states the basis and any known divergence. Use 'eu.t2' for the euro cash leg. We refuse FREE rather than guess: beyond published calendar coverage, no cited cycle for the instrument (government bonds never inherit an equity cycle), a cycle not in force on the trade date, or FX spot value dates. Free companion: GET /settlement-conventions.
| Name | Required | Description | Default |
|---|---|---|---|
| market | No | ISO country of the market whose cited cycle should apply (with instrument_class) | |
| api_key | No | API key (bypasses x402; metered for invoicing) | |
| calendars | Yes | Calendar ids to intersect: two-letter ISO country codes, plus 'eu.t2' for the euro cash leg | |
| trade_date | Yes | Trade/reference date, YYYY-MM-DD. Day 0: never counted, never rolled. | |
| business_days | No | The offset you are trading under (T+n) | |
| instrument_class | No | Instrument class — a government bond never inherits an equity cycle |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description bears full burden. It discloses paid nature ($0.05), per-day trail output, use of statutory calendars (not CSD/exchange), refusal scenarios, and companion API. 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 long but efficient; each sentence adds unique value. Front-loaded with key details (paid, core function). Slightly verbose but appropriate for complexity. No waste.
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?
Comprehensive coverage: return value (per-day trail), edge cases (refusal), prerequisites (calendars), and related endpoint. No output schema, but description adequately describes output. Complete for 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 has 100% coverage but description adds significant meaning: explains trade_date day 0, calendar id format ('eu.t2'), business_days vs market+instrument_class usage, and instrument_class enum specifics. Adds value 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 computes settlement/value dates based on business days and calendar intersections. It distinguishes itself from siblings like count_working_days and get_public_holidays by focusing on settlement date calculation with detailed calendar logic.
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 (e.g., trading under a cycle) and when not (e.g., no cited cycle, FX spot dates). Mentions alternative endpoint GET /settlement-conventions and conditions where the tool refuses to guess.
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!