bls-labor-mcp-server
Server Details
Fetch US Bureau of Labor Statistics data — CPI, unemployment, wages, JOLTS, and more via MCP.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/bls-labor-mcp-server
- GitHub Stars
- 1
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.7/5 across 6 of 6 tools scored.
Each tool has a clearly distinct purpose: list_surveys and search_series for discovery, get_series and get_latest for data retrieval (one for time-series, one for latest), and describe/query for analysis. No overlap.
All tools follow a consistent bls_ verb_noun pattern in snake_case (e.g., bls_get_series, bls_search_series), making naming predictable and clear.
With 6 tools, the set is well-scoped for BLS labor data: covers discovery, retrieval, and analysis without unnecessary bulk or missing essentials.
The tool surface supports the full workflow: discover surveys (list_surveys), search series (search_series), fetch data (get_series/get_latest), and analyze via SQL (describe/query). No obvious gaps.
Available Tools
6 toolsbls_dataframe_describeDescribe BLS DataframesARead-onlyIdempotentInspect
List canvas dataframes materialized by bls_get_series, with provenance (source tool, query parameters), TTL, row count, and column schema. Use before writing SQL to confirm column names. Lazy-sweeps expired tables before responding. Requires CANVAS_PROVIDER_TYPE=duckdb.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional table name (df_XXXXX_XXXXX) to describe a single dataframe. Omit to list all active dataframes. |
Output Schema
| Name | Required | Description |
|---|---|---|
| dataframes | Yes | Active dataframes for this tenant, newest first. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and idempotentHint. Description adds behavioral details: 'Lazy-sweeps expired tables before responding' and environment requirement, providing context beyond annotations.
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 plus a requirement line. Every sentence adds value, front-loaded with purpose. 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 the simple tool (1 optional param, output schema exists), the description covers purpose, usage hint, behavioral side-effect, and environment constraint. Complete for an agent to select and invoke 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 coverage is 100% and the description largely repeats the schema's parameter description. No additional semantic value beyond what the input 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 uses specific verb 'List' and resource 'canvas dataframes materialized by bls_get_series', clearly distinguishing from sibling tools like bls_dataframe_query (which queries) and bls_get_series (which retrieves 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 states 'Use before writing SQL to confirm column names' for context, and mentions prerequisite 'Requires CANVAS_PROVIDER_TYPE=duckdb'. Does not explicitly state when not to use, but sibling names imply alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bls_dataframe_queryQuery BLS DataframesARead-onlyIdempotentInspect
Run a single-statement SELECT against the canvas dataframes registered by bls_get_series. Read-only: writes, DDL, DROP, COPY, PRAGMA, ATTACH, and external-file table functions are rejected. System catalogs (information_schema, pg_catalog, sqlite_master, duckdb_*) are denied at the bridge layer — use bls_dataframe_describe to list available dataframes. Supports JOINs, aggregates, window functions, and CTEs. Optional register_as persists the result as a new dataframe with a fresh TTL for chained analysis. Canvas SQL operations consume zero BLS API quota. Requires CANVAS_PROVIDER_TYPE=duckdb.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | Single-statement SELECT against df_<id> tables on the shared canvas. Reference dataframes by the names returned in bls_get_series responses or listed by bls_dataframe_describe. Standard DuckDB SQL — joins, aggregates, window functions, CTEs all supported. Example: SELECT series_id, year, period, value FROM df_AAAAA_BBBBB WHERE year >= '2020' ORDER BY year DESC. | |
| preview | No | Inline row preview count. Defaults to row_limit. Set lower (e.g. 50) when chaining via register_as and only a sample is needed immediately. | |
| row_limit | No | Hard cap on rows materialized in the response (default 1000, max 10000). Full results live on-canvas under register_as when provided. | |
| register_as | No | When set, persist the query result as a new dataframe under this name. Fresh TTL — not inherited from parent tables. Use to chain analyses without re-running source SQL or consuming additional BLS quota. |
Output Schema
| Name | Required | Description |
|---|---|---|
| rows | Yes | Materialized rows, bounded by preview / row_limit. |
| notice | No | Guidance when results were capped by preview or row_limit — names which parameter was the binding limiter and suggests how to retrieve the rest. Absent when all rows fit in the response. |
| columns | Yes | Column names in projection order. |
| row_count | Yes | Total rows the query produced (may exceed rows.length when capped by row_limit). |
| expires_at | No | ISO 8601 expiry for the newly registered dataframe, when applicable. |
| registered_as | No | Set when register_as was supplied and the result was materialized. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds significant behavioral context: it is read-only, rejects certain SQL statements, denies system catalogs at the bridge layer, mentions zero BLS API quota consumption, and explains that register_as persists the result with a fresh TTL. No contradictions with annotations.
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 and front-loaded with the core purpose. Every sentence adds value: purpose, constraints, usage alternatives, supported operations, and optional parameter behavior. It is appropriately sized for a complex tool with 4 parameters and 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?
Given the tool complexity (4 parameters, required 1, output schema present), the description is complete. It covers purpose, constraints, usage guidelines, parameter semantics, and chaining. The output schema exists, so the description does not need to explain return values. No gaps identified.
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 substantial meaning beyond the schema: for 'sql' it provides an example and clarifies referencing dataframes; for 'preview' it explains default behavior and chaining; for 'row_limit' it explains hard cap and defaults; for 'register_as' it explains TTL and chaining benefits. This significantly helps the agent understand parameter 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 runs a single-statement SELECT against canvas dataframes registered by bls_get_series. It distinguishes itself from sibling tools like bls_dataframe_describe (for metadata) and bls_get_series (for fetching data). The verb 'Query' and resource 'BLS Dataframes' 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 explicitly states when to use this tool: for querying dataframes. It also specifies when not to: rejects writes, DDL, DROP, COPY, PRAGMA, ATTACH, and external-file table functions. It provides an alternative: use bls_dataframe_describe to list available dataframes. It also gives context on supported operations (JOINs, aggregates, etc.) and the optional register_as parameter for chaining.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bls_get_latestGet Latest BLS ObservationARead-onlyIdempotentInspect
Return the single most recent observation for one or more BLS series. Use for "what is X right now" questions — the current unemployment rate, the latest CPI reading, etc. Each series consumes one API query against the 500/day limit; for the current value of many series, bls_get_series with a 1-year window is more quota-efficient (one query for up to 50 series). Recommended limit: 10 series; maximum: 50.
| Name | Required | Description | Default |
|---|---|---|---|
| series_ids | Yes | One or more BLS SeriesIDs (1–50). Each consumes one daily API query. Use bls_search_series to resolve concepts to SeriesIDs. Recommended: ≤10 series. |
Output Schema
| Name | Required | Description |
|---|---|---|
| failed | Yes | Series that failed to fetch. Inspect seriesId and error for per-item details. Not-found series appear here rather than as a tool-level error. |
| notice | No | Guidance when one or more series failed — e.g. to use bls_search_series to verify SeriesIDs. Absent when all series returned data. |
| results | Yes | Successfully fetched series with their latest observations. Series that failed appear in failed[] instead. |
| succeeded | Yes | Number of series with a successfully fetched observation. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. Description adds API quota context (500/day limit, each series consumes one query) and notes alternative for efficiency. No contradiction. with annotations covering safety, description adds meaningful behavioral info beyond annotations.
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 substantive. First sentence states primary function. Second gives usage guidance and alternatives. Third adds limits. 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 single parameter, annotations, output schema, and sibling tools, description covers purpose, usage context, quota concerns, and alternatives completely. No gaps.
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% (series_ids fully described). Description adds meaning beyond schema: explains per-series quota consumption and recommends ≤10 for efficiency. Provides context not in 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 'return the single most recent observation for one or more BLS series'. Uses specific verb 'return' and resource 'BLS series'. Distinguishes from siblings like bls_get_series (returns range) and bls_search_series (resolves concepts).
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 says use for 'what is X right now' questions, provides alternatives (bls_get_series for quota efficiency), and gives recommended (≤10) and maximum (50) series limits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bls_get_seriesGet BLS Time-Series DataARead-onlyInspect
Fetch time-series data for 1–50 BLS series by SeriesID in a single API request (one query against the 500/day limit). Supports optional year range (up to 20 years per request) and BLS-computed period-over-period calculations (net change and percent change; a survey returns whichever it supports — CPI and PPI return percent change only, the inflation rate — so check bls_list_surveys first). When the total observation count would exceed the inline context budget, results spill to a canvas dataframe and the response includes a dataset.name handle for follow-up SQL via bls_dataframe_query. Use bls_search_series first if you need to resolve a concept to a SeriesID.
| Name | Required | Description | Default |
|---|---|---|---|
| end_year | No | End year for the data range (inclusive). Defaults to the current year when omitted. | |
| series_ids | Yes | One or more BLS SeriesIDs (1–50). The entire batch counts as one API query. Use bls_search_series to resolve concepts to SeriesIDs. | |
| start_year | No | Start year for the data range (inclusive). The BLS API allows up to 20 years per request. Omit for the API default (typically 3–20 years depending on survey). | |
| calculations | No | When true, request BLS-computed period-over-period calculations. The flag is a single boolean (you cannot select an individual calculation type), but the API returns whichever the survey supports: CPI and PPI return percent change only (the inflation rate), with no error. Only surveys that support neither net nor percent change (e.g. AP average price data) return an error — check bls_list_surveys first. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance for agents — e.g. when results spilled to canvas and SQL is needed for full access. Absent when all observations fit inline. |
| series | Yes | Series data, in request order. |
| dataset | No | Canvas dataframe handle — present when the observation volume exceeded the inline budget. Use bls_dataframe_query with dataset.name to run SQL across the full data. |
| spilled | Yes | True when results spilled to canvas due to inline budget overflow. |
| endYearApplied | No | End year in effect, when a range was requested. |
| seriesRequested | Yes | Number of SeriesIDs requested. Compare against the returned series[] length to detect series that returned no data. |
| startYearApplied | No | Start year in effect, when a range was requested. |
| totalObservations | Yes | Total observation rows across all requested series. |
| calculationsApplied | No | Whether BLS net/percent-change calculations were requested. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses beyond annotations: rate limit consumption (one query against 500/day), optional year range (max 20 years), BLS-calculations behavior (CPI/PPI return percent change only), and spill-to-canvas dataframe when observation count exceeds budget. No contradiction with readOnlyHint or openWorldHint.
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?
Concise but slightly verbose; every sentence adds value, but could be tightened (e.g., 'a survey returns whichever it supports' phrase). Front-loaded with core purpose and well-structured.
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?
Thorough given complexity: covers data volume handling (spill to canvas), calculations nuances, rate limit, and workflow with siblings and follow-up SQL tool. Output schema exists, so return values are not needed in description.
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?
Provides meaning beyond schema: explains calculations flag's survey-dependent behavior, start_year default, and the count logic for series_ids. With 100% schema coverage, the description adds crucial context like 'The flag is a single boolean... but the API returns whichever the survey supports.'
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 fetches time-series data for 1-50 BLS series via SeriesID, specifying it's a single API request. It distinguishes from siblings by directing users to bls_search_series for concept resolution and bls_list_surveys for survey-specific calculations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when to use alternatives: 'Use bls_search_series first if you need to resolve a concept to a SeriesID' and 'check bls_list_surveys first' for calculations. Also mentions rate limit (500/day) and query count (one per call), guiding appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bls_list_surveysList BLS SurveysARead-onlyIdempotentInspect
List BLS survey programs with their abbreviation codes, full names, and metadata about calculation support and annual averages. Use to discover which survey covers a topic before calling bls_search_series. Optional category filter narrows results to prices, employment, wages, productivity, injuries, or time_use surveys.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional category filter. One of: prices, employment, wages, productivity, injuries, time_use. Omit to list all surveys. |
Output Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | Total surveys returned. |
| surveys | Yes | BLS survey programs matching the filter, sorted alphabetically by abbreviation. |
| categoryFilter | No | Category filter applied, if any. Absent when all surveys were listed. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds specific details about outputs (abbreviation codes, full names, metadata) beyond what annotations provide. Annotations already declare readOnlyHint and idempotentHint, so the description's additional context about the output's contents enhances transparency without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no superfluous content. It front-loads the core purpose and follows with usage guidance, making it highly efficient and reader-friendly.
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 simplicity (1 optional param, no required params), the description, combined with annotations and schema, covers all necessary information. The existence of an output schema means return values need not be detailed in the description. The workflow reference to a sibling tool provides complete contextual guidance.
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 single optional parameter (`category`) has full description coverage in the schema (100%). The description reinforces the parameter's purpose and enum values, adding value by explaining its role in narrowing results. Baseline 3 is elevated due to this contextual reinforcement.
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 BLS survey programs with specific information (abbreviation codes, full names, metadata). It distinguishes itself from the sibling tool `bls_search_series` by indicating its use as a precursor to that tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance: 'Use to discover which survey covers a topic before calling bls_search_series.' It implies when to use and suggests an alternative. However, it does not explicitly state when not to use or other exclusions, keeping it from a top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bls_search_seriesSearch BLS SeriesARead-onlyInspect
Search the BLS series catalog by natural language query, survey code, geographic area, or keywords to resolve cryptic SeriesIDs. Returns matching series with decoded components (survey, area, item, seasonal flag) and plain-language names. Use this before bls_get_series when you have a concept but not a SeriesID. Operates offline — no API quota consumed. Survey filter accepts two-letter codes (CU, CE, LN, LA, PC, JT, OE, EC, PR). Area filter accepts state names, MSA names, or FIPS area codes.
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | State name, MSA name, or FIPS area code to narrow results to a geographic area. Omit for national series. | |
| limit | No | Maximum number of results to return (1–50, default 10). | |
| query | Yes | Natural language or keyword query (e.g. "unemployment rate", "CPI food", "nonfarm payrolls"). Also accepts a SeriesID directly for exact lookup. | |
| survey | No | Two-letter LABSTAT survey abbreviation to filter results (e.g. CU for CPI, CE for CES, LN for CPS, LA for LAUS, JT for JOLTS, OE for OEWS). Omit to search all loaded surveys. | |
| seasonal_adjustment | No | When true, return only seasonally adjusted series. When false, return only not-seasonally-adjusted. Omit to return both. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The result limit that capped the returned list. |
| shown | No | Number of series returned in this response. |
| capped | Yes | True when the FTS candidate pool reached the internal cap (~1000). totalCount is then a lower bound, not an exact match count. Narrow the query, add survey/area filters, or use a direct SeriesID to get an exact count. |
| notice | No | Guidance when no results matched — e.g. how to broaden the query or remove filters. Absent when results are returned. |
| series | Yes | Matching series, ordered by relevance. |
| truncated | No | True when more candidates matched than the limit returned. |
| areaFilter | No | Area filter applied, if any. Absent when no area filter was passed. |
| totalCount | Yes | Total candidates scored before the limit was applied. A lower bound when capped is true — the catalog index may contain more matching series. |
| catalogSize | Yes | Total series in the loaded catalog index. Distinguishes an empty-result search from a failed catalog load. |
| limitApplied | Yes | Result limit in effect (defaults to 10 when omitted). |
| surveyFilter | No | Survey filter applied, if any. Absent when no survey filter was passed. |
| effectiveQuery | Yes | Query string as the server received and searched on. Confirms interpretation for self-correction. |
| seasonalFilter | No | Seasonal-adjustment filter applied, if any. Absent when not passed. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds valuable context beyond this: it operates offline, consumes no API quota, and returns decoded components and plain-language names. No contradictions with annotations.
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 wasted words. It front-loads the primary purpose, then adds supporting details in separate sentences. Every sentence serves a purpose and contributes to clarity.
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 (5 parameters, output schema present), the description covers all essential aspects: search type, parameter formats, return format, and usage context. The presence of an output schema reduces the need to describe return values in detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds extra meaning by listing more survey codes, clarifying that query accepts SeriesID for exact lookup, and explaining area filter options. This enrichment justifies a score above 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 states the tool's verb ('Search'), resource ('BLS series catalog'), and how it interacts with siblings. It explicitly mentions resolving cryptic SeriesIDs and distinguishes itself by advising use before bls_get_series when lacking a SeriesID.
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 states when to use the tool ('Use this before bls_get_series when you have a concept but not a SeriesID') and provides alternative tools (bls_get_series). It also notes offline operation and no API quota, which informs decision-making.
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!