African govt data, cited to source: rates, VAT, tax, wages, holidays, FX. 34 countries; Ghana 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.4/5 across 11 of 11 tools scored.
Each of the 11 tools addresses a clearly distinct operation: compliance checking, income tax, payroll, VAT, working days, holidays, series queries (current/history/snapshot/catalog), and settlement date. Even within the tax and calendar families, the descriptions precisely delineate boundaries, so there is no realistic risk of an agent selecting the wrong tool.
The vast majority of tools follow a consistent verb_noun snake_case pattern (check_, compute_, get_, list_, count_). The only deviation is settlement_date, which is a noun phrase rather than verb_noun, but it is still clear and idiomatic. This single outlier prevents a perfect score.
With 11 tools, the server is well-scoped for a reference-data domain covering statutory rates, calculations, calendars, and settlement conventions. Each tool has a distinct purpose and earns its place; the count is neither thin nor bloated.
The server provides strong coverage of its stated domain: statutory tax computations, payroll, minimum wage, VAT, holidays, working days, and settlement dates, plus a generic series API for extensibility. Minor gaps exist, such as payroll only supporting Nigeria and Kenya and no standalone social-security contributor, but the response descriptions explicitly disclose these limits, and the generic series endpoint provides a workaround for common lookups.
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 available, the description carries the full burden. It discloses honest statuses for missing floors and period mismatches, and explicitly states cross-period conversion is never guessed. It also explains the payment mechanism via api_key or x402. However, it does not state whether the operation is read-only or if it has side effects, but the purpose implies a query.
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 extremely concise, consisting of two sentences. The first sentence immediately explains the purpose and return values. The second sentence covers edge cases and payment. No wasted words, and 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 tool has moderate complexity with 4 parameters, no output schema. The description covers return values (verdict, margin, floor, instrument) and key edge cases (no floor, period mismatch). It explains payment flow. However, it does not enumerate possible verdict statuses or provide examples of the response structure, which would be helpful for an agent.
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 all parameters (100% coverage). The description adds value by explaining the purpose of the optional api_key parameter and emphasizing that the period must match the statutory floor's period, reinforcing the schema's note. It does not elaborate on the country or amount parameters 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's purpose: 'Compliance verdict: is a salary at, above or below the country's statutory minimum wage?' It identifies the specific verb (check/compliance), resource (minimum wage), and scope (country-specific). It is distinct from sibling tools which deal with taxes, holidays, 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 implies the tool is for checking minimum wage compliance but does not provide explicit guidance on when to use it versus alternatives, nor does it mention when not to use it. The optional api_key parameter is mentioned but not contextualized as a requirement. Absent any alternative tool for similar purpose, the guidance is adequate but not proactive.
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?
With no annotations provided, the description fully discloses behavioral traits: a cost of $0.05, the use of a verified bracket schedule, handling of indexed units, exclusion of reliefs and social security, and the api_key/x402 payment mechanism. This is comprehensive and leaves no major ambiguity.
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 a single paragraph that is information-dense but not excessively long. It front-loads the essential purpose and cost. Some structure (e.g., bullet points or separate sentences) could improve readability, but overall it communicates efficiently.
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 of tax computation across many countries, the description covers key aspects: what it computes, what it excludes, unit handling, and payment method. It hints at output (full workings, effective rate) and mentions a scope_note. The lack of an output schema is somewhat mitigated by the description's detail.
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 provides full descriptions for all three parameters (100% coverage), the description adds valuable context: it specifies that taxable_income is in local currency and notes the per-period basis (annual except for specific countries). This enriches the meaning 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 that the tool computes statutory income tax on a taxable income figure using a verified marginal bracket schedule. It specifies the handling of inflation-indexed tax units and explicitly distinguishes from net take-home pay, which helps differentiate it from sibling tools like compute_payroll.
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 context on what the tool does and does not do (e.g., not net pay, no reliefs/allowances). It also explains the api_key payment bypass and x402 alternative. However, it does not explicitly compare to sibling tools like compute_payroll, which might be used for net pay.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compute_payrollAInspectPAID ($0.10). Gross-to-net take-home pay for Nigeria or Kenya: applies PAYE (on the verified brackets) plus the statutory employee deductions (Nigeria: pension/NHF/NHIS; Kenya: NSSF/SHIF/Affordable Housing Levy) and reliefs, returning net pay with full workings, per-contribution citations and DISCLOSED assumptions. Nigeria's pension base needs pay composition — pass basic/housing/transport for an exact figure, or a market-convention 40/30/10 split is assumed and disclosed. Pass api_key if you have one; otherwise the response explains how to pay via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| basic | No | Nigeria: basic pay component | |
| gross | Yes | Gross pay in local currency | |
| period | No | Period the gross covers (default month) | |
| sector | No | Nigeria: public applies NHF; private (default) sets NHF 0 | |
| api_key | No | API key (bypasses x402; metered for invoicing) | |
| country | Yes | Payroll is supported for Nigeria (ng) and Kenya (ke) | |
| housing | No | Nigeria: housing allowance | |
| transport | No | Nigeria: transport allowance | |
| annual_rent | No | Nigeria: annual rent paid (unlocks rent relief) | |
| nhis_premium | No | Nigeria: NHIS employee premium if deducted | |
| pensionable_pay | No | Kenya: pensionable pay for NSSF tiers | |
| insurance_premium | No | Kenya: insurance premium for 15% relief |
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 tool is paid ($0.10), applies PAYE, statutory deductions, reliefs, and returns net pay with workings and assumptions. It also explains the pension base splitting and api_key usage. This is transparent for a payroll tool, though it could mention error handling.
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 relatively long but front-loaded with the key purpose. It packs a lot of information efficiently in two sentences, with no wasted words. A more structured format could improve readability, but it remains concise given the 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?
Given 12 parameters, 100% schema coverage, and no output schema, the description is complete enough. It covers the main logic, assumptions, and special cases, and hints that output includes net pay with workings and citations. It compensates for the lack of output schema by describing the return content.
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 adds value by explaining the roles of basic/housing/transport for Nigeria's pension base and the 40/30/10 split default, as well as sector differences and api_key purpose. This 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 specifies that the tool computes gross-to-net take-home pay for Nigeria or Kenya, listing specific deductions and reliefs. This distinguishes it from sibling tools like compute_income_tax, which only handle a subset of the payroll computation.
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 on when to use the tool (for Nigeria or Kenya payroll) and mentions requirements like providing basic/housing/transport for exact pension base. However, it does not explicitly contrast with alternatives like compute_income_tax, though the purpose implies this is a full payroll tool.
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 provided, but description discloses cost ($0.02), paywall via x402, and detailed output components. No contradictions. Sufficient transparency for a paid 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?
Three sentences front-load key info (cost, purpose, modes) with no redundant text. Every sentence provides unique 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 4 parameters, full schema coverage, no output schema, and no annotations, description covers usage modes, payment, and country-specific composite rates. Fully sufficient for agent to decide and invoke.
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 4 parameters with descriptions (100% coverage). Description adds value by clarifying mode default ('add' as net) and hinting at composite rate behavior, but does not significantly extend schema detail for other params.
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 it computes VAT breakdown (net, tax, gross) with per-levy components for composite rates, and distinguishes between two modes (add/extract). Tool name 'compute_vat' is well-aligned with purpose.
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 explains when to use mode=add vs mode=extract, and notes payment process (api_key or x402). However, does not explicitly contrast with sibling tools like compute_income_tax.
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 bears full burden and effectively discloses behavior: weekends (Egypt's Fri–Sat handled), statutory holidays applied, holidays listed by name, and the next working day after the range. It also mentions the payment model. Some details like error handling or rate limits are absent.
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 no wasted words, front-loading the most critical information (paid tool, core function, country handling, holidays). Every sentence serves a purpose.
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 no output schema, the description compensates by describing what is returned (weekends applied, holidays hit by name, next working day). Parameters are well-covered. The complexity is moderate, and the description is mostly complete, though it could mention typical use cases or limitations.
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%, but the description adds value beyond schema by explaining the api_key parameter's role in payment, and hints that subdivision codes can be discovered via get_public_holidays. This aids agent decision-making without repeating 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 the tool counts working days within a date range for a country, applying weekends and statutory public holidays. It distinguishes from siblings like 'get_public_holidays' and 'settlement_date' by focusing on counting working days and providing specific holiday details.
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 specifies the use case (counting working days with weekends and holidays), the maximum range of 366 days, and mentions the api_key/payment process. However, it lacks explicit guidance on when not to use or direct alternatives, though the sibling list provides some context.
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?
No annotations provided; description carries full burden. It discloses that the tool is free, uses official government sources, handles subdivisions with merging, and tags results. It does not cover rate limits or authentication, but for a free API this is reasonable.
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 paragraph, front-loaded with key info (FREE, official). Every sentence adds value; 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 explains the return includes government source, subdivisions field, and regional holiday tagging. It covers the tool's core function adequately for typical use, though it could detail the exact return format.
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 the subdivision parameter's behavior (merging national and regional holidays, tagging) beyond the schema's basic field description.
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 it provides the official public-holiday calendar for a supported country, with a specific verb ('get') and resource ('public-holiday calendar'). It is well-distinguished from sibling tools (tax, payroll, working days) which are unrelated.
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 includes usage context like 'FREE' and explains sub-national calendar behavior. It implies when to use (holiday lookups) vs alternatives (working days, taxes), though it doesn't explicitly state exclusions.
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 full burden and excels. It discloses the paid nature ($0.005), payment workflow via x402, alternative api_key auth, and response attributes (source citation, effective date, last-confirmed date, staleness flag). This goes far beyond a simple read operation and sets clear expectations.
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, and every clause contributes. It packs examples, response content, and payment guidance without 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?
Despite no output schema, the description explains what the response will include (official citation, effective date, last-confirmed date, staleness flag). It covers payment/auth nuances. For a simple current-value lookup, this is complete and self-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 description coverage is 100%, so the baseline is 3. The description adds value by giving series examples and explaining the api_key parameter's role (bypasses x402, metered). It does not add detail for 'country' beyond the schema's enum, but the additional context for series and api_key is meaningful.
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: 'Current value of a reference series' with concrete examples (policy-rate, vat, minimum-wage). This distinguishes it from sibling tools like get_series_history (historical values) and list_series (listing series). The verb 'get' is implicit but the resource and scope are explicit.
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 context for when to use this tool: when you need the current value of a reference series. It implies alternative tools (e.g., historical data would use get_series_history) but does not explicitly name them or state when not to use it. The payment and api_key guidance is helpful context.
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, the description carries the full burden. It discloses the paid nature ($0.005), the optional api_key behavior, and the fallback payment instruction via x402, which is crucial for a paid tool. It implies a read-only retrieval but does not explicitly state side-effects or error handling, so not a 5.
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, front-loaded with the cost warning, and no wasted words. It efficiently covers purpose, filters, and authentication in a compact way.
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 cost, auth, and filtering, giving a good overall picture. However, with no output schema, it does not specify the exact return format (e.g., list of value-date pairs), which leaves a minor gap. Still, it is sufficiently complete for a straightforward historical lookup 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 the parameters are already well documented. The description adds only minor context, such as the YYYY-MM-DD format and api_key payment semantics, which do not significantly enrich understanding beyond the schema. 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 clearly states the tool retrieves historical values of a reference series with effective date ranges, which distinguishes it from siblings like get_series and get_snapshot. The scope is specific: it provides time-filtered history, making the purpose 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 for historical data needs via 'Historical values' and 'optionally filtered by from/to', offering clear context. It does not explicitly name alternatives, but the sibling names and the phrase 'reference series' help the agent infer when this tool is appropriate.
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?
With no annotations, the description discloses the paid nature and optional api_key behavior, but lacks details on response structure, rate limits, or error handling.
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 efficiently convey purpose, cost, and parameter usage without 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?
Adequate for a simple tool with one optional parameter; covers what, cost, and how to use, though could clarify the return format since no output schema exists.
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 parameter, and the description adds context (optional api_key, payment explanation) but does not significantly extend 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 provides a snapshot of every series for every country, distinguishing it from sibling tools like get_series or list_series that operate on individual series or subsets.
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 the paid nature ($0.02) and when to pass an api_key vs letting the response explain payment, but does not explicitly contrast with alternatives like get_series for single series retrieval.
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 afriref 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?
No annotations are provided, so the description bears full responsibility. It states it is 'FREE' and describes the output content but does not disclose potential performance, pagination, or rate limits. As a simple list tool, this is adequate but not fully 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?
The description is extremely concise: two sentences (22 words) with no wasted words. It front-loads key information ('FREE') and immediately conveys the tool's purpose.
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 and no annotations, the description adequately explains the tool's role and output contents. However, it could specify the output structure (e.g., array of objects) for greater completeness.
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 tool has no parameters, and the schema coverage is 100% (trivially). The description adds value by describing what the output contains, which compensates for the lack of parameters.
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 specifies the tool's function: listing all afriref reference-data series with details like supported countries, series IDs, descriptions, freshness metadata, and URLs. It uses specific nouns and distinguishes itself from sibling tools (e.g., get_series retrieves a specific series).
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 guidance: 'Call this first to discover what data exists.' This implies it's the entry point before using other tools. While it doesn't list alternatives or exclusions, the context of sibling tools makes the usage 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?
No annotations provided, but description fully discloses paid cost ($0.05), refuse behavior, calendar research methodology, and output trail. No contradiction.
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 lengthy but every sentence adds value. Structured logically with cost, purpose, usage examples, and limitations. Minor verbosity but warranted for 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?
For a tool with 6 parameters and no output schema, the description covers all main use cases, edge cases, refusals, and even points to supplementary resources. Very 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%, yet description adds crucial context like the distinction between business_days and market+instrument_class, calendar ID meanings ('eu.t2'), and trade_date semantics ('Day 0 never counted').
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 settlement/value dates using calendar intersection. It distinguishes from sibling tools like count_working_days and get_public_holidays by specifying settlement date logic and paid nature.
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 explains when to supply business_days vs market+instrument_class, how calendars are selected, and what conditions cause refusals. Mentions free companion endpoint for conventions.
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!