reference-data
Server Details
Latin American government reference data: central-bank rates, VAT, wages, holidays, 6 countries.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 4.1/5 across 9 of 9 tools scored. Lowest: 3.4/5.
Each tool targets a distinct operation or resource: compliance checks, tax/VAT calculations, working days, holidays, series values (current/history/snapshot/catalog). No two tools have overlapping purposes; descriptions clearly differentiate them.
All tools follow a consistent verb_noun pattern in snake_case (e.g., check_minimum_wage, get_series_history, list_series). No mixed conventions or irregular naming.
9 tools is well-scoped for a reference data server. Each tool serves a clear function without redundancy, covering compliance, tax, holidays, and series data retrieval.
The tool set covers the expected domain comprehensively: minimum wage checking, income tax and VAT computation, working days with holidays, and series discovery/retrieval (current, historical, snapshot). No obvious gaps for the stated purpose.
Available Tools
9 toolscheck_minimum_wageAInspect
PAID ($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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses important behaviors: honest statuses for missing floors or period mismatches, and that cross-period conversion is never guessed. It also explains the payment flow. Missing explicit statement about read-only or destructive nature, but the context implies 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?
The description is extremely concise, using a few sentences to convey purpose, edge cases, and authentication. Every sentence adds value with no fluff or repetition. Key information is front-loaded for quick agent parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully explains return values (verdict, margin, statutory floor, legal instrument) and covers edge cases (missing floor, period mismatch). It also addresses the payment mechanism via x402. Given the tool's complexity and sibling set, the description 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 coverage is 100% for all 4 parameters. The description adds meaning beyond the schema: 'amount in the country's own currency', 'period must match the statutory floor's period', and the constraint about no cross-period conversion. It also clarifies the api_key parameter's role and payment fallback.
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: a compliance verdict checking if a salary is at, above, or below the statutory minimum wage. It specifies the resource (minimum wage) and the action (check/compliance), and distinguishes from siblings like compute_vat and get_public_holidays by its unique function.
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 usage, including authentication options ('Pass api_key if you have one; otherwise the response explains how to pay via x402'). It implies the tool is for checking salary compliance, but does not explicitly state when not to use it or name alternative tools, though the sibling context makes the distinction clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compute_income_taxAInspect
PAID ($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) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses that the tool is paid ($0.05), handles only taxable income, provides per-bracket workings, effective rate, marginal rate, and supports inflation-indexed units. It also explains the payment mechanism (x402) and the need for an api_key. 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?
The description is well-structured but slightly verbose. It front-loads key info like cost and purpose, but the first word 'PAID' may be jarring. Each sentence adds value, though minor trimming could improve conciseness.
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 partially explains return values (per-bracket workings, effective rate, marginal rate) and mentions a 'scope_note' in the response. However, it does not fully describe all return elements, which may be acceptable given tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for each parameter. The description adds context about local currency and inflation-indexed units but does not significantly enhance parameter 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 statutory income tax on taxable income using marginal bracket schedules, with verb 'compute' and resource 'income tax'. It distinguishes itself from sibling tools like compute_vat and check_minimum_wage by focusing on 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 explicitly warns that this tool computes tax on taxable income, not net take-home pay, and that reliefs/allowances and social-security contributions are the caller's concern. It also mentions the alternative of passing an api_key or using x402 payment. However, it does not directly compare to sibling tools like compute_vat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compute_vatAInspect
PAID ($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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses paid nature ($0.02), alternative payment explanation via x402 without api_key, and handling of composite rates (e.g., Ghana VAT + NHIL + GETFund).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundant information. Every phrase is meaningful and 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?
Given no output schema and full schema coverage, the description adequately covers purpose, usage, and behavioral context for a 4-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, but description adds value by explaining that 'country' uses current statutory rate and that 'mode' defines treatment of amount (net/gross). Also clarifies api_key behavior beyond schema's minimal 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 computes VAT breakdown (net, tax, gross) using current statutory rates, including composite components. It is distinct from sibling tools which deal with wages, holidays, and 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 explains when to use mode=add vs mode=extract, and how to handle api_key. Does not state when not to use, but provides clear context for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
count_working_daysAInspect
PAID ($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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and covers key behavioral traits: the tool is paid, applies holidays per country, handles special weekend days (e.g., Egypt's Fri-Sat), imposes a 366-day range limit, and explains payment flow. It does not discuss error handling or rate limits, but the core behavior is well disclosed.
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 that efficiently convey purpose, key features, and usage notes. Every sentence adds value: first sentence defines core function, second covers payment and range. No redundant or filler language.
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 informs what is returned (holidays hit and next working day). It also covers payment model and constraints. While sibling differentiation is not explicit, the tool's unique value is clear. Could add more detail on error conditions or country-specific nuances, but overall 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 covers all 4 parameters with descriptions. The description adds value by explaining the api_key optionality, max range, and that return includes holiday names and next working day. It also implies the country enum values map to the listed codes (enumerated in schema). This enriches understanding beyond the schema alone.
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 given country, accounting for weekends and statutory holidays, and lists what is returned. It is specific about the resource and action, and distinguishes itself from sibling tool 'get_public_holidays' by focusing on counting working days rather than just listing 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 the tool is paid ($0.02) and provides instructions for payment via api_key or x402 response. It also states a maximum range of 366 days. However, it does not explicitly state when to use this tool versus alternatives like 'get_public_holidays' or provide when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_public_holidaysBInspect
FREE. Official public-holiday calendar for a supported country, including gazetted movable holidays, with the official government source cited.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | ISO country code |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description adds only 'FREE' and source credibility, lacks disclosure of rate limits or authentication needs.
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 sentence effectively packs key features: free, official, movable holidays, cited source.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, description covers purpose and content well; slight gap on 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 coverage is 100% with clear enum and description; the description does not add new parameter meaning beyond stating 'supported country'.
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 holidays for a supported country with government source, distinct from sibling series tools.
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?
Only mentions being 'FREE', no guidance on when to use vs alternatives or avoid duplication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_seriesAInspect
PAID ($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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses the paid nature ($0.005), response elements (source citation, effective date, staleness flag), and payment mechanism. Lacks mention of rate limits but is otherwise 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?
Two sentences, front-loaded with cost and examples. No wasted words; every sentence adds necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema, description covers return values, cost, and payment. Missing error handling or rate limits, but the tool is simple and the description is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by explaining the api_key parameter's optionality and payment implication, and giving examples for series. This surpasses the schema's 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 'Current value of a reference series' with concrete examples like policy-rate, vat, minimum-wage. This distinguishes it from siblings like get_series_history (history) and list_series (list all), making purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on api_key usage and x402 payment alternative. However, it does not explicitly state when to use this tool versus alternatives for historical or list operations; context from sibling names partially compensates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_series_historyAInspect
PAID ($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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the paid nature and payment method, but does not elaborate on side effects, auth requirements beyond api_key, or 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?
Extremely concise with two sentences, no redundancy, and key information 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?
Covers purpose and payment but omits return format, error handling, and potential pagination; acceptable for a simple query 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%; description adds minimal value by clarifying optional payment flow, but does not significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves historical values of a reference series with effective date ranges, distinguishing it from siblings like get_public_holidays and list_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 context on payment and optional filtering, but lacks explicit guidance on when to use 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.
get_snapshotAInspect
PAID ($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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the cost ($0.02) and the x402 payment mechanism if no api_key is provided. It does not mention other behavioral aspects like rate limits or side effects, but the tool is read-only and cost transparency is well handled.
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. The cost is front-loaded, followed by purpose and parameter guidance. Extremely concise and effective.
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 the essential purpose and usage. It could mention the response structure, but the name 'snapshot' and purpose make it clear.
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% (one parameter). The description adds meaning beyond the schema by clarifying the api_key is optional, and its absence triggers payment instructions via x402.
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 explicitly states the tool returns a snapshot of every series for every country, using a specific verb and resource. It clearly distinguishes from siblings like get_series (single series) and get_public_holidays (different domain).
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 advises when to pass api_key vs not, and hints at the bulk nature of the snapshot, implying use for comprehensive data retrieval. However, it does not explicitly exclude alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_seriesAInspect
FREE. Catalog of all latamref reference-data series: supported countries, series ids, descriptions, freshness metadata and per-series URLs. Call this first to discover what data exists.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'FREE' (ambiguous) and lists output contents but does not disclose read-only nature, auth requirements, rate limits, or any side effects. This leaves significant behavioral gaps.
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. The first sentence lists what the tool provides, the second gives usage priority. Perfectly front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no params and no output schema, the description covers the main purpose and output contents. However, it lacks details on response format, potential pagination, or error behavior, which would help agents use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage. According to guidelines, with 0 parameters baseline is 4. The description does not need to add parameter info.
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 lists a catalog of reference-data series with specific details (countries, ids, descriptions, freshness, URLs). It also instructs to call this first, distinguishing it from sibling tools that likely operate on 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?
The description explicitly says 'Call this first to discover what data exists,' providing clear when-to-use guidance. It does not specify when not to use it or explicitly name alternatives, but the context implies it is the initial discovery step.
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.
Discussions
No comments yet. Be the first to start the discussion!