Oceania govt data, cited: rates, VAT, tax, wages, holidays, FX. 8 countries; Australia 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. Lowest: 3.6/5.
Each tool targets a distinct domain: wage compliance, income tax, VAT, working days, holidays, series data (current, history, snapshot, catalog), and settlement dates. Even the financial computations (check_minimum_wage, compute_income_tax, compute_vat) have clearly different inputs and purposes, so no two tools are confusable.
Most tools follow a clear verb_noun snake_case pattern (check_, compute_, count_, get_, list_). The only exception is `settlement_date`, which is a noun phrase rather than verb-first, but it remains consistent in style and readability. This minor deviation prevents a perfect score.
With 10 tools, the server is well-scoped for a reference-data provider. It balances specific computations (minimum wage, tax, VAT) with general data access (series, holidays, settlements), and each tool serves a clear purpose without overlap or unnecessary bulk.
The tool surface comprehensively covers reference data for financial and calendar domains: statutory rates and compliance, holiday and working-day calendars, settlement conventions, and a generic series system with current, historical, snapshot, and catalog access. No obvious gaps impede an agent from accomplishing typical reference-data tasks, and the free list_series enables discovery.
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?
No annotations provided, so description carries full burden. Discloses honest statuses for missing floors and period mismatches, explicitly states no cross-period guessing. Mentions payment method (x402) and api_key bypass. Does not detail rate limits or idempotency, but overall sufficiently transparent for a read-only check.
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?
Very concise—3 sentences cover purpose, behavior, edge cases, and payment. Front-loaded with key information. No redundant or vague wording.
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, yet description specifies return values: verdict, margin, statutory floor, legal instrument. Covers edge cases and payment flow. Given no annotations, this is a complete picture for an AI 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?
Schema coverage is 100%, so baseline 3. Description reinforces that period must match statutory floor's period, but does not add new semantic details beyond schema. No additional explanations for parameters like country codes or amount format.
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 explicitly states it provides a compliance verdict on whether a salary meets statutory minimum wage, using specific verb ('check' implied by name, 'returns verdict') and resource ('statutory minimum wage'). Clearly distinguishes 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?
Describes when to use (check salary against minimum wage) and mentions edge cases like no enforceable floor or period mismatch. States option to pass api_key or use x402 payment. No explicit 'when not to use', but context from sibling tools clarifies it's for minimum wage compliance.
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 exist, so the description fully carries transparency. It discloses the paid nature ($0.05), the exclusion of net take-home pay, the handling of inflation-indexed units, and the presence of a scope_note in the response. This gives a clear behavioral contract.
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, well-organized paragraph that front-loads key information (paid, purpose) and efficiently conveys all necessary details without redundancy. Every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description effectively covers what the tool returns (per-bracket workings, effective rate, marginal rate) and limitations. It provides enough context for correct usage, including payment methods and parameter specifics.
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 value by clarifying that taxable_income is in local currency and period basis as per the schedule, and that api_key is optional and bypasses x402. This enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool's action: computing statutory income tax on taxable income using marginal bracket schedules. It distinguishes itself from sibling tools like compute_vat (indirect tax) by focusing on income tax. The specific mention of handling inflation-indexed tax units adds precision.
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 (for income tax on taxable income) and what it does not cover (reliefs, social security, net pay), directing responsibility to the caller. Also provides guidance on API key usage vs. x402 payment, aiding correct invocation.
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?
Despite no annotations, the description fully discloses that the tool costs $0.02, explains how payment works (api_key or x402), and details the behavioral difference between modes. This is transparent about all key behaviors.
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 no redundant sentences. It front-loads the purpose and payment info, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return components (net, tax, gross, per-levy) and covers payment. It lacks error handling details but is sufficient for a simple calculation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that amount is in the country's own currency and that mode defaults to 'add', improving understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes VAT breakdown (net, tax, gross) using the country's statutory rate, including per-levy components for composite rates. It distinguishes from siblings like compute_income_tax by being VAT-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the two modes (add/extract) and when to use each, but does not explicitly state when not to use this tool or provide alternatives among siblings.
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?
No annotations provided, so description carries full burden. Discloses paid nature, api_key requirement, and handling of weekends (e.g., Egypt's Fri-Sat). But lacks details on response format, error handling, or exact behavior when range exceeds 366 days.
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 concise, single sentence with key information front-loaded. No unnecessary words, but could be slightly more 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?
Covers main aspects (paid, holidays, max range) but misses output format specification. Without output schema, the description should clarify return structure (e.g., count, holiday names, next working day). Adequate but not fully 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 adds significant value: explains country's weekend handling, application of holidays by name, range max, and api_key usage. Exceeds 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?
Description clearly states the tool counts working days in a date range for a country, explicitly mentioning weekends and statutory holidays. It distinguishes from siblings like get_public_holidays (lists holidays) and settlement_date (next working day).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for use: includes holidays, max range 366 days, payment info. However, does not explicitly compare to alternatives or state when not to use this tool.
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, so description carries full burden. It discloses that the tool is free, cites official sources, and explains behavior with subdivisions (merged calendar). It does not mention rate limits or auth, but for a read-only holiday tool this is sufficient. Missing details on response format, but the explanation of sub-national calendars adds transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose in the first sentence. The second sentence provides essential sub-national detail. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 2 parameters and no output schema, the description covers the main functionality (national and sub-national calendars). However, it does not clarify the limited set of supported countries (the enum shows only 8 Pacific nations), nor does it describe the expected response structure (e.g., list of holiday objects). This could leave the agent uncertain about handling unsupported countries or the output 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 description coverage is 100%, baseline 3. Description adds value by explaining that 'country' is an ISO code with examples, and that 'subdivision' returns merged national+regional holidays. It also mentions the existence of the 'subdivisions' field in the response, which goes 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?
Description clearly states it provides official public holiday calendars, including movable holidays and sub-national calendars. It uses specific verbs like 'get' and 'returns', and distinguishes from siblings like count_working_days or settlement_date by focusing on holiday data.
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 marked as 'FREE', and explains when to use the subdivision parameter. It implies usage for obtaining holiday data but does not state when not to use it or provide direct comparison to sibling tools. However, given sibling tools are about wage, tax, working days, etc., the context is clear.
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), the need for api_key or x402 payment, and the response metadata (source citation, effective date, last-confirmed date, staleness flag). This goes beyond basic purpose and gives important behavioral details, though it omits potential rate limits or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. It front-loads the cost and purpose, then adds return metadata and authentication details. Every sentence earns its place, making it highly 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 there is no output schema, the description explains what each value contains. It covers cost, purpose, authentication, and response metadata. It does not detail response structure or potential errors, but for a simple getter with moderate complexity, this is reasonably 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 the baseline is 3. The description adds value by providing concrete examples for the 'series' parameter (policy-rate, vat, minimum-wage) and clarifies the role of api_key in bypassing x402 payment. It also implies that country is needed but relies on the schema for exact enum values.
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 the current value of a reference series, with examples like policy-rate, vat, and minimum-wage. It implicitly distinguishes from siblings like get_series_history (by using 'current') and list_series, but does not explicitly name alternatives, so it falls short of a perfect score.
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 series values and mentions payment/authentication, but it does not explicitly state when to use this tool versus alternatives such as get_series_history or list_series. There is no 'when not to use' guidance, so usage context is only implied.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses the cost ($0.005), the optional api_key behavior, and the fallback payment via x402. It does not cover error handling or response structure, but key behavioral traits are present, adding significant value beyond structured fields.
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, front-loaded with the cost and core function, no filler. Every sentence earns its place, covering cost, purpose, filters, and auth/payment.
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 essential aspects: purpose, payment, optional filters, and the api_key fallback. It does not detail response structure (no output schema exists), but for a moderate-complexity tool with 5 parameters, it is adequately complete, though a bit more on return format 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?
Schema coverage is 100%, so baseline is 3. The description adds meaning by clarifying that from/to are optional filters with YYYY-MM-DD format and that api_key is optional with a specific fallback behavior. This adds context 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 retrieves 'Historical values of a reference series with effective date ranges', specifying the resource (reference series) and the action (get history). It distinguishes itself from sibling tools like get_snapshot and list_series by focusing on historical data with date ranges.
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 series data with optional filters, but does not explicitly state when to use this tool versus alternatives like get_series or get_snapshot. The paid nature hints at cost-conscious usage, but no alternatives or exclusions are mentioned.
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?
No annotations provided, so the description carries full burden. It discloses the cost ($0.02) and the behavior when no api_key is provided (response explains payment). However, it doesn't mention whether the call is idempotent, rate limits, or response size. Adequate but not exhaustive.
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 'PAID ($0.02)'. Every word earns its place. 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?
No output schema exists, so the description should cover what the snapshot contains. It says 'snapshot of every series for every country' but doesn't specify the data format or structure. Also lacks potential response size warnings. Adequate for a simple tool but leaves some unknowns.
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 one parameter (api_key) with 100% coverage. The description adds that the api_key is optional and explains the fallback behavior (payment instructions). This gives context 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 it provides a snapshot of every series for every country. The verb 'snapshot' combined with the scope distinguishes it from siblings like get_series (single series) or list_series (list). However, it doesn't explicitly contrast itself with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives context about the paid nature and how to pass an api_key or get payment instructions. But it doesn't explicitly state when to use this tool vs siblings (e.g., 'use this to get all data at once; use get_series for a single series').
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 ausref 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 carries the full burden. It states that the tool is 'FREE' and describes the return content, but does not discuss any potential side effects, rate limits, or data freshness guarantees. For a read-only catalog tool, this is adequate but not comprehensive.
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 sentence that is concise and front-loaded with 'FREE.' It includes all essential information without extraneous words, earning 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 the tool has no parameters, no output schema, and no annotations, the description is fairly complete. It tells the agent to call this first for discovery and lists what is returned. However, it lacks details about pagination, response size limits, or format, but overall it is adequate for the tool's simplicity.
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 zero parameters, so schema coverage is 100%. The description adds value by explaining that the tool returns a catalog of series, which is useful context. With no parameters, a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists a catalog of all ausref reference-data series, including specific content like countries, series ids, descriptions, freshness metadata, and URLs. It uses the specific verb 'catalog' and resource 'series', and distinguishes from siblings by advising to call this first.
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 says 'Call this first to discover what data exists,' providing clear usage guidance. It implies this is a discovery tool before using other tools like get_series, but does not explicitly mention when not to use it or alternative tools.
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?
Despite no annotations, the description fully discloses behavioral traits: it charges $0.05, shows a per-day trail, refuses to guess, uses national statutory holiday calendars (not CSD/exchange), and cites primary sources for cycles. It also notes known divergences and refusal conditions.
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 dense but front-loaded with the core purpose. It efficiently packs many details (pricing, cycle examples, calendar definitions, refusal conditions) into a single paragraph, making it comprehensive for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema, no annotations), the description is remarkably complete. It covers all essential aspects: how to invoke, what to expect, edge cases, pricing, and data sources, leaving no significant gaps for an AI 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?
Schema coverage is 100%, so baseline is 3. The description adds significant meaning beyond the schema by explaining how business_days and market+instrument_class interact, calendar codes like 'eu.t2', and the meaning of trade_date (day 0 never counted/rolled). This justifies a 4.
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 as n business days after a trade date using the intersection of specified calendars. It distinguishes itself from sibling tools (none of which handle settlement date computations), and provides specific examples of cycles and jurisdictions.
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 tells when to use the tool (e.g., 'Supply business_days for a cycle you are trading under, or market + instrument_class') and when not (e.g., 'We refuse FREE rather than guess: beyond published calendar coverage, no cited cycle...'). It also explains how to specify calendars and the 'eu.t2' for euro cash leg.
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!