N American govt data, cited to source: rates, VAT, tax, wages, holidays, FX. 10 countries; USA 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.2/5 across 10 of 10 tools scored.
Most tools have clear, distinct purposes: minimum wage checking, income tax, VAT, working days, holidays, settlement dates, and generic series access all serve different functions. However, compute_vat and check_minimum_wage could be confused with simple get_series lookups for the same series (vat, minimum-wage), though the descriptions clarify that the compute_* tools provide breakdowns rather than just current values.
The majority of tools follow a consistent verb_noun snake_case pattern (check_minimum_wage, compute_income_tax, compute_vat, count_working_days, get_public_holidays, get_series, get_series_history, get_snapshot, list_series). Settlement_date breaks the pattern as a noun-only name instead of something like get_settlement_date, creating a minor deviation.
With 10 tools, the server is well-scoped for its reference-data purpose. It covers a broad but justified range of statutory and financial reference data without being excessive, and each tool serves a distinct function within that domain.
The tool set provides comprehensive coverage of typical reference data: minimum wage, income tax, VAT, public holidays, working days, settlement dates, and generic series with current values, history, and snapshots. The inclusion of list_series for discovery and the generic get_series/get_series_history endpoints cover the full lifecycle of accessing reference data. No obvious gaps for the stated purpose.
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 properly discloses the tool's behavior: returns verdict, margin, statutory floor, legal instrument, and honest statuses. It also mentions the x402 payment or api_key, adding transparency about how results are obtained.
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 with four sentences covering purpose, return values, edge cases, and payment. It is front-loaded with the verdict statement, though the structure could be slightly improved by separating core purpose from payment details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, but the description adequately explains return values (verdict, margin, floor, legal instrument) and handles edge cases (missing floor, period mismatch). It covers legal dependence, which is critical for compliance tools.
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 parameters are well-documented in the schema. The description only adds minor context (e.g., 'country's own currency' and period matching), but does not significantly enhance understanding beyond what the schema provides.
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 checks if a salary meets minimum wage and returns verdict, margin, floor, and legal instrument. The name 'check_minimum_wage' aligns perfectly, and it is distinct from sibling tools like compute_income_tax.
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 the tool is honest about missing floors or period mismatches, and notes that cross-period conversion is never guessed. It does not explicitly list alternatives but implies when not to rely on it, which is adequate.
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?
No annotations provided, but description discloses it's a paid tool ($0.05), handles specific inflation-indexed units, and clarifies what it does not apply (reliefs/allowances, social security). Also mentions response includes scope_note and workings. Sufficient transparency for agent decision.
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 four sentences, front-loaded with purpose and cost. Efficient but could be more structured. However, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains scope, inputs, limitations (not net pay, no reliefs), and response includes workings and scope_note. Adequate for agent to use 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?
Schema covers 100% parameters with descriptions. Description adds meaning: taxable_income is in local currency, period basis varies; api_key bypasses x402. Provides contextual 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?
Clearly states it computes statutory income tax on taxable income using marginal brackets, with full workings, effective rate, marginal rate, and handles inflation-indexed tax units. The verb 'compute' and resource 'income tax' are specific, and it distinguishes from siblings like compute_vat and check_minimum_wage.
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 important usage guidance: it's tax on taxable income, not net pay; reliefs/allowances are caller's concern; mentions api_key or x402 payment. Could offer more explicit when-to-use vs alternatives but given sibling tools, it's clear this is for income tax computation.
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?
Discloses the cost ($0.02), that rates are current statutory, and that composite rates are handled (e.g., Ghana). Also explains what happens without an api_key, providing transparency about 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?
Three sentences, each providing key information: cost, purpose, mode options, and api_key guidance. Front-loaded with cost to set expectations. 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?
Given no output schema, the description explains the output components (net, tax, gross, and per-levy details). It covers cost and payment, but could mention error handling or rate update frequency.
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 the 'mode' parameter behavior (add vs extract) and the notion of composite rates tied to the 'country' parameter.
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 computes VAT breakdown (net, tax, gross) for an amount using current statutory rates, including composite rates for countries like Ghana. It distinguishes itself from siblings like compute_income_tax by focusing 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?
Explicitly explains the two modes (add vs extract) and when to use each. Also mentions api_key usage. However, it 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 fully discloses behavioral traits: paid ($0.02), weekend handling (Egypt's Fri-Sat shown as example), holiday application, return of holiday names and next working day, max range of 366 days, and payment mechanism via api_key or x402.
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 fairly concise and front-loaded with key facts (cost). However, it is a single long sentence that could be better structured for readability.
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?
While there is no output schema, the description explains return values (holidays hit and next working day). It covers the main behavior and constraints, though could detail error cases.
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 schema already documents parameters. The description only adds context about api_key usage for payment, adding minimal 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?
The description clearly states the tool counts working days in a date range for a country, applying weekends and statutory holidays, and returns holidays hit and next working day. It is specific and distinguishes 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?
The description mentions payment but does not provide explicit guidance on when to use this tool versus alternatives. It is implied for counting working days but no exclusions or comparisons.
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, the description carries the burden of behavioral transparency. It discloses the tool is free and returns official data with source citation. It mentions the merged behavior for subdivisions. However, it does not explicitly state it is read-only, has no side effects, or any rate limits.
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 very concise: two sentences, no wasted words. The first sentence states the core purpose and key features, and the second elaborates on subdivisions. It is front-loaded and 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 and no annotations, the description covers essential aspects: purpose, subdivision feature, official source, and free nature. It does not describe the output format but is reasonably complete for a simple holiday lookup tool. Minor gaps: no mention of error cases or country list.
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 parameters are documented. The description adds significant value beyond the schema: explains the 'subdivisions' field, gives an example (DE-BY), and clarifies that passing subdivision returns merged national+regional holidays tagged as such. This extra context helps usage.
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 provides an official public-holiday calendar for supported countries with sub-national options. The tool name 'get_public_holidays' reinforces its purpose, and it is distinct from sibling tools which handle taxes, wages, and working days. However, the description does not explicitly start with a verb like 'Retrieve' to emphasize the action.
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 subdivision parameter and notes the tool is free. It implies usage for fetching official holidays, but does not explicitly state when not to use it (e.g., for working days count) or compare to sibling tools like count_working_days.
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 provided, the description carries the full transparency burden. It discloses the cost ($0.005), the data characteristics (source citation, effective date, last-confirmed date, staleness flag), and the authentication/payment options (api_key vs x402). This goes well beyond the schema and is substantive 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 tightly written sentences convey price, purpose, output contents, and authentication details with no filler. The most critical information (cost and what it does) is front-loaded, making it easy for an agent to quickly assess relevance.
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 absence of an output schema, the description adequately describes what the return value contains (citation, effective dates, staleness flag). It also explains the payment flow. Minor gaps exist around error handling or edge cases, but for a simple lookup tool with clear schemas and examples, it is largely 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?
The input schema provides descriptions for all three parameters (100% coverage), so the baseline is 3. The description repeats the series examples and adds the 'current value' context, but does not add significant new meaning beyond what the schema already states. It meets but does not exceed the 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 identifies the tool as returning the current value of a reference series, with explicit examples (policy-rate, vat, minimum-wage). It distinguishes itself from siblings like get_series_history (which presumably returns historical values) and list_series (which lists available series). The verb and resource are specific 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 implies usage for retrieving current reference values, but does not explicitly contrast it with alternatives such as get_series_history for historical data. It provides examples and mentions payment, but no direct when-to-use or when-not-to-use guidance. Usage is inferable but not explicitly stated.
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 cost, authentication/payment behavior, and the notion of effective date ranges. It does not describe output format or error handling, but the most critical behavioral traits (cost, auth, historical scope) 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?
Two sentences, front-loaded with the paid warning, no filler. All information is relevant and efficiently presented.
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?
Without an output schema, the description should more concretely explain the return shape (e.g., array of date-value pairs). 'Historical values with effective date ranges' gives the gist but not enough detail for a paid API. It also leaves the relationship to get_series implicit.
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 baseline is 3. The description adds marginal value by explaining api_key's optionality and the YYYY-MM-DD format for from/to, but it does not elaborate on series or country beyond what the schema already provides.
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 historical values of a reference series with effective date ranges, distinguishing it from sibling tools like get_series or get_snapshot by the 'historical' focus. Though it lacks an explicit imperative verb, the intent is 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 clear context: the tool is paid ($0.005), supports optional from/to filtering, and explains the api_key vs x402 payment flow. However, it does not explicitly mention when to prefer this over get_series or list_series, leaving some use-case ambiguity.
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 provided, the description carries full burden. It discloses the cost and that the response may include payment instructions if no api_key is provided. However, it lacks details on response size, performance implications of fetching 'every series for every country,' or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two sentences to convey purpose, cost, and parameter guidance. It is front-loaded with the most critical information (payment) and contains no unnecessary 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?
For a simple tool with one optional parameter and no output schema, the description covers payment and basic purpose. However, it omits details about the snapshot's structure (e.g., format, fields) and any potential limitations (e.g., data volume), which would be helpful for an agent without seeing actual outputs.
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 api_key parameter. The description adds value by explaining the parameter's optionality and the behavior when omitted (response explains payment), which goes beyond the schema's simple 'API key' 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?
The description clearly states the tool provides a 'Snapshot of every series for every country in one call.' The verb 'get' and resource 'snapshot' are specific, and it distinguishes from siblings like 'get_series' and 'list_series' by offering a broad cross-country overview.
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 notes the tool is paid ($0.02) and advises on the api_key parameter: pass if you have one, otherwise the response explains payment via x402. This provides clear usage context, though it could further clarify 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.
list_seriesAInspectFREE. Catalog of all usaref 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 the burden of disclosure. It lists all output elements (countries, IDs, descriptions, freshness metadata, URLs) and notes 'FREE', indicating no cost. No contradictions or omissions for a read-only catalog.
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, no wasted words. Front-loaded with 'FREE' and 'Catalog of all usaref reference-data series', and each phrase adds essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description fully details what the tool returns. For a zero-parameter catalog tool with good annotation coverage, no additional context is needed.
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 has no parameters, and description coverage is 100%. The description adds value by clarifying the tool's role as an initial discovery step, which is appropriate for a parameterless tool.
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: catalog all usaref reference-data series, including supported countries, IDs, descriptions, freshness metadata, and URLs. It also advises to call this first, distinguishing it from sibling tools like get_series which fetches 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?
Explicitly instructs to call this first to discover existing data, providing clear usage context. While it doesn't list when not to use, the simplicity of a no-parameter catalog tool makes this guidance sufficient.
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, so description must fully disclose behavior. It does so comprehensively: paid ($0.05), refusal policy, calendar types (statutory holiday calendars, not exchange calendars), cycle sourcing, and the per-day trail output. 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?
Description is long but each sentence adds value. Front-loaded with key purpose and cost. Some minor redundancy (e.g., 'PAID ($0.05)' appears first but not in a separate line). Still, highly efficient given the tool's 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?
No output schema, but description implies the per-day trail format. Addresses edge cases: refusal rather than guess, documented citation sources, calendar types, and FX spot value dates. For a complex tool with 6 parameters, this is remarkably 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%, but description vastly enriches parameter meaning. It explains the dual mode (business_days vs market+instrument_class), clarifies calendar IDs as ISO country codes plus 'eu.t2', and adds crucial context about inheritance rules (e.g., government bonds never inherit equity cycle). Far exceeds 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 specifies exactly what the tool computes: settlement/value date based on n business days after trade date, with clear distinction from siblings. It mentions paid nature, calendar intersection, and per-day trail. This is a specific verb+resource definition.
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 guidance on when to use business_days vs market+instrument_class, which calendars to use, and what scenarios lead to refusal. Mentions free companion endpoint. While it doesn't explicitly name sibling tools, it effectively tells when to use this tool instead of guessing or using other holiday/date tools.
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!