WHO Global Health Observatory — 3,059 indicators across 194 member states.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.4/5 across 6 of 6 tools scored. Lowest: 3.8/5.
The tools have distinct purposes: browsing/searching indicators, fetching metadata, listing dimensions/values, and querying data. The primary potential confusion is between who_list_indicators and who_search_indicators, but descriptions clarify the distinction (browse vs search with keyword).
All tools follow a consistent who_verb_noun pattern with clear verbs: list, search, get, query. The naming is predictable and makes the tool purpose immediately obvious.
6 tools is well-scoped for a health indicator data API, covering discovery (list/search indicators, list dimensions), metadata (indicator metadata, dimension values), and data retrieval (query indicator data). No tools feel redundant.
The tool set covers the full lifecycle: discover dimensions → browse/search indicators → get indicator metadata → query data. Minor gaps include lack of dimension metadata (e.g., descriptions) and inability to list all regions or income groups directly, but the core workflow is complete.
who_get_indicator_metadataGet WHO GHO Indicator MetadataAFetch metadata for one or more WHO GHO indicator codes: the full indicator name and the dimensions it supports (e.g. COUNTRY, REGION, SEX, YEAR, WORLDBANKINCOMEGROUP, AGEGROUP). Call this before querying data with who_query_indicator_data to confirm which filter dimensions are valid for a given indicator. Accepts up to 10 codes per call. Many valid indicators have no dimension listing upstream — those return an empty dimensions array with a dimensionsNote, not a not-found. Only codes absent from the catalog are reported in the notFound array, and that is reported rather than raised as an error.
| Name | Required | Description | Default |
|---|---|---|---|
| indicator_codes | Yes | One to ten indicator codes, e.g. ["WHOSIS_000001", "MDG_0000000026"]. |
| Name | Required | Description |
|---|---|---|
| notFound | Yes | Indicator codes that resolved to neither a catalog name nor any dimension rows — they do not exist in the GHO catalog. |
| indicators | Yes | Metadata for each code that resolved to a catalog entry. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and idempotent, consistent with 'fetch metadata'. Description adds key context: empty dimensions array vs not-found behavior, 10-code limit beyond schema maxItems, and error handling preference (notFound array). 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?
Three sentences, each carrying distinct information: first explains output, second explains usage context, third clarifies edge cases. No filler; optimal length for the wealth of detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and an implicit output schema, the description fully explains the purpose, behavior, and error patterns. Minor gap: doesn't confirm that output includes the full indicator name (only 'metadata'). Still very complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% – the parameter is documented inline with format example. Description adds no new parameter-specific meaning beyond 'fetch for one or more codes'. Approaches adequacy but does not exceed 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?
Describes fetching metadata (indicator name, dimensions) for one or more WHO GHO indicator codes. The verb 'fetch' and resource 'metadata' are specific, but it doesn't explicitly distinguish from who_search_indicators which may return some overlapping fields.
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?
Advises calling this before who_query_indicator_data to confirm valid filter dimensions. However, it does not clarify when to use this vs who_list_indicators or who_search_indicators, missing explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
who_list_dimensionsList GHO Dimension TypesAList all dimension type codes and human-readable titles available in the WHO Global Health Observatory API. Use this to discover valid dimension codes before calling who_list_dimension_values. Common dimensions include COUNTRY, REGION, SEX, WORLDBANKINCOMEGROUP, and AGEGROUP, but many additional types exist — this tool exposes them all.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| dimensions | Yes | All available dimension types in the GHO catalog. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds context about the WHO GHO API and that it exposes all dimension types, which goes beyond annotations but doesn't need to repeat them.
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 purpose, and contains zero redundant words. Every sentence earns 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?
For a zero-parameter tool with good annotations and an output schema (not shown but present), the description fully covers purpose, usage, and output type. 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?
No parameters exist, so schema coverage is 100%. Baseline 4 is appropriate; the description adds value by specifying output (codes and titles) and linking to the API, but no parameter details are needed.
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 'dimension type codes and human-readable titles' from the WHO GHO API, distinguishing it from sibling tools like who_list_dimension_values by its role in discovering valid dimension codes before querying values.
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 this to discover valid dimension codes before calling who_list_dimension_values' and provides examples of common dimensions, giving clear when-to-use guidance and an implicit alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
who_list_dimension_valuesList GHO Dimension ValuesAList valid codes and labels for a WHO GHO dimension type such as COUNTRY, REGION, SEX, WORLDBANKINCOMEGROUP, or AGEGROUP. Use this to discover valid filter values before calling who_query_indicator_data, or to confirm the correct ISO code for a country. Use who_list_dimensions to discover all available dimension type codes. Results are paged in a deterministic order — narrow hierarchical dimensions with parent_code (e.g. the countries in one WHO region), and page the rest with offset.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of values to return per page. Default 100, max 500. | |
| offset | No | Zero-based offset into the values for this dimension and filter. Default 0. Read hasMore and nextOffset from the response to continue paging. An offset at or beyond totalCount returns an empty values array, not an error. | |
| dimension | Yes | Dimension type code. Use who_list_dimensions to discover all available codes. Common values: COUNTRY, REGION, SEX, WORLDBANKINCOMEGROUP, AGEGROUP. | |
| parent_code | No | Restrict results to values under one parent, e.g. dimension="COUNTRY" with parent_code="EUR" for the countries in the WHO European Region. Only hierarchical dimensions carry a parent; a filter that matches nothing returns an empty page, not an error. |
| Name | Required | Description |
|---|---|---|
| notice | No | Present when values were withheld, the parent_code filter matched nothing, or the requested offset ran past the end. Explains what to do next. |
| offset | Yes | Zero-based offset this page started at. |
| values | Yes | Valid values for this dimension type, for the requested page. |
| hasMore | Yes | True when more values remain beyond this page. Pair with nextOffset to continue. |
| pageInfo | Yes | Human-readable page position, e.g. "offset 0, showing 100 of 234". Use to construct the next offset. |
| dimension | Yes | The requested dimension type code. |
| nextOffset | No | Offset to request for the next page. Absent when this page reached the end of the values. |
| totalCount | Yes | Total values for this dimension and filter, before the limit is applied. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description adds value by explaining paging behavior, deterministic order, and hierarchical filtering with `parent_code`. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four sentences: purpose, use case, pointer to sibling, and paging behavior. No wasted words, front-loaded with core function.
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 output schema exists (so return details are covered) and the description explains purpose, usage, paging, and hierarchical filtering, it is largely complete. The only minor gap is explicit mention of pagination metadata fields like `hasMore` and `totalCount`, but these are likely in the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in schema. The tool description reinforces usage (e.g., referencing `who_list_dimensions` for dimension codes) but does not add significant new meaning beyond the schema's own 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 verb 'List' and resource 'valid codes and labels for a WHO GHO dimension type', distinguishing it from sibling `who_list_dimensions` which lists dimension types rather than values. It also provides example dimension codes and usage context.
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 ('discover valid filter values before calling who_query_indicator_data, confirm correct ISO code') and contrasts with `who_list_dimensions`. It does not mention other siblings like `who_get_indicator_metadata` but provides clear guidance for its primary role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
who_list_indicatorsList WHO GHO IndicatorsABrowse the WHO Global Health Observatory indicator catalog with pagination. Use when you want to explore indicators without a keyword, or to page through the full catalog. Use who_search_indicators when you have a keyword to narrow the results.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of indicators to return per page. Default 50, max 500. | |
| offset | No | Zero-based offset for pagination. Default 0. |
| Name | Required | Description |
|---|---|---|
| hasMore | Yes | True when more indicators exist beyond the current page. |
| pageInfo | Yes | Human-readable page position, e.g. "offset 0, showing 50 of 3059". Use to construct the next offset. |
| indicators | Yes | Indicators for the requested page. |
| totalCount | Yes | Total number of indicators in the GHO catalog. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description does not contradict them. It adds pagination context, but no additional behavioral traits like rate limits or side effects beyond what annotations provide.
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 purpose, and no extraneous information. Every sentence earns 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?
With an output schema present and annotations covering safety, the description is sufficient for a paginated list tool. It could mention that results include indicator codes and names, but output schema likely covers that.
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 schema already fully describes limit and offset (with defaults, min, max). The description does not add any additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Browse the WHO Global Health Observatory indicator catalog with pagination', which is a specific verb+resource. It also distinguishes from the sibling tool who_search_indicators by contrasting use cases.
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: 'when you want to explore indicators without a keyword, or to page through the full catalog' and when to use the alternative: 'Use who_search_indicators when you have a keyword.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
who_query_indicator_dataQuery WHO GHO Indicator DataAQuery data rows for a single WHO GHO indicator with optional spatial, temporal, and dimension filters. Returns rows with numeric values, uncertainty intervals (Low/High), and spatial/time metadata. This is the primary data-fetching tool in the find-then-query workflow: use who_search_indicators to find the indicator code, optionally call who_get_indicator_metadata to confirm which filter dimensions are valid, then call this tool. Spatial filters are mutually exclusive per call: provide only one of country_codes, region_codes, or income_group_codes — mixing them triggers an error. Omitting all spatial filters returns all geographies (may be large; use limit to cap). The sex filter only applies when the indicator uses SEX as its first cross-cutting dimension — if not, the filter returns empty rows; check who_get_indicator_metadata first if uncertain. Rows are returned in a deterministic order (most recent first by default), so a capped result is the top of a defined slice rather than an arbitrary sample; page through the rest with offset.
| Name | Required | Description | Default |
|---|---|---|---|
| sex | No | Filter on sex dimension: SEX_BTSX (both sexes), SEX_FMLE (female), SEX_MLE (male). Only applies when the indicator uses SEX as its first cross-cutting dimension. | |
| sort | No | Row ordering: "year_desc" (default) returns the most recent years first, "year_asc" the earliest first. Ties are broken by spatial code, then dimension, then row id. | year_desc |
| limit | No | Maximum number of data rows to return. Default 200, max 1000. | |
| offset | No | Zero-based row offset for pagination. Default 0. Pages are stable because rows are returned in a deterministic order — read hasMore and nextOffset from the response to continue. An offset at or beyond totalRows returns an empty rows array, not an error. | |
| year_to | No | End year (inclusive) for the time range filter, e.g. 2023. | |
| year_from | No | Start year (inclusive) for the time range filter, e.g. 2015. | |
| dim1_value | No | Value filter for indicators whose first cross-cutting dimension is not SEX (e.g. an AGEGROUP code like "YEARS05-14"). Ignored when sex is also provided. | |
| region_codes | No | WHO region codes to filter on, e.g. ["AFR","EUR","AMR","EMR","SEAR","WPR"]. Returns the aggregate row for each named WHO region — not per-country rows within it. To get country-level data for a region, use who_list_dimension_values with dimension="COUNTRY" and parent_code set to the region code to retrieve the ISO codes for countries in that region, then pass those to country_codes. Use who_list_dimension_values with dimension="REGION" to see all valid region codes. Mutually exclusive with country_codes and income_group_codes. | |
| country_codes | No | ISO 3166-1 alpha-3 country codes to filter on, e.g. ["JPN","USA","BRA"]. Mutually exclusive with region_codes and income_group_codes. | |
| indicator_code | Yes | Indicator code to query, e.g. "WHOSIS_000001". Use who_search_indicators to find codes. | |
| income_group_codes | No | World Bank income group codes, e.g. ["WB_HI","WB_LMI","WB_LI","WB_UMI"]. Use who_list_dimension_values with dimension="WORLDBANKINCOMEGROUP" to see all valid codes. Mutually exclusive with country_codes and region_codes. | |
| include_uncertainty | No | Include Low and High uncertainty interval bounds in output. Default true. |
| Name | Required | Description |
|---|---|---|
| rows | Yes | Data rows matching the query. |
| notice | No | Present when rows were withheld or the requested offset ran past the end of the result set. Explains how to reach the remaining rows. |
| offset | Yes | Zero-based row offset this page started at. |
| hasMore | Yes | True when rows remain beyond this page. Pair with nextOffset to continue. |
| pageInfo | Yes | Human-readable page position, e.g. "offset 0, showing 200 of 12936". Use to construct the next offset. |
| totalRows | Yes | Total row count matching the query on the server (before the limit is applied). |
| truncated | No | True when the result was capped at the requested limit. |
| nextOffset | No | Offset to request for the next page. Absent when this page reached the end of the result set. |
| totalCount | Yes | Alias of totalRows for cross-tool consistency — total rows before the limit. |
| appliedFilters | Yes | Filters that were applied to the query. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, openWorldHint), the description discloses key behaviors: deterministic ordering, pagination stability, spatial filter mutual exclusivity, the effect of sex filter conditional on indicator dimension, and that region filters return aggregate rows not country-level data. 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 yet comprehensive, front-loading the purpose and workflow, then addressing specific parameter behaviors. Every sentence adds unique information—no filler or tautology. Despite its length, it is well-organized and easy to parse for an AI agent.
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 (12 parameters, 1 required, output schema exists), the description covers the full workflow, parameter constraints, pagination, sorting, uncertainty, spatial and sex filters, and error conditions. It anticipates and addresses common pitfalls, making it complete for effective agent usage.
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?
With 100% schema description coverage, the description still adds significant value by providing behavioral context not in the schema: for sex, it explains when the filter applies; for region_codes, it clarifies it returns aggregates and recommends other tools for country data; for limit and offset, it explains deterministic pagination. This far exceeds the baseline of 3.
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 queries data rows for a single WHO GHO indicator with filters and returns numeric values, uncertainty intervals, and metadata. It distinguishes itself from siblings by explicitly positioning it as the primary data-fetching tool in the find-then-query workflow, listing the prerequisite tools (who_search_indicators, who_get_indicator_metadata).
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 explicit guidance on when to use this tool ('the primary data-fetching tool'), when not to ('mixing spatial filters triggers an error'), and how to prepare (use search then optionally metadata). It also explains the conditional behavior of the sex filter and suggests alternatives via who_get_indicator_metadata and who_list_dimension_values.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
who_search_indicatorsSearch WHO GHO IndicatorsASearch the WHO Global Health Observatory indicator catalog by keyword in the indicator name. Returns indicator codes and names for use with who_query_indicator_data. The search uses a substring match on indicator names — try terms like "life expectancy", "immunization", "mortality", "diabetes", or "HIV". If results are truncated, refine the query or page further into the same filtered result set with offset.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of indicators to return. Default 20, max 100. | |
| query | Yes | Keyword to search in indicator names, e.g. "life expectancy" or "tuberculosis". | |
| offset | No | Zero-based offset into the matches for this query. Default 0. Read hasMore and nextOffset from the response to continue paging. An offset at or beyond totalCount returns an empty indicators array, not an error. |
| Name | Required | Description |
|---|---|---|
| notice | No | Present when matches were withheld or the requested offset ran past the end of the result set. Explains how to reach the remaining matches. |
| offset | Yes | Zero-based offset this page started at. |
| hasMore | Yes | True when more matches remain beyond this page. Pair with nextOffset to continue. |
| pageInfo | Yes | Human-readable page position, e.g. "offset 0, showing 20 of 3003". Use to construct the next offset. |
| indicators | Yes | Matching indicators up to the requested limit. |
| nextOffset | No | Offset to request for the next page. Absent when this page reached the end of the matches. |
| totalCount | Yes | Total indicators matching the query in the catalog, before the limit is applied. |
| effectiveQuery | Yes | Keyword used for the catalog search, as received by the server. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral detail beyond the annotations: it specifies substring matching, truncation handling, paging behavior with offset, and that an offset beyond totalCount returns an empty array (not an error). The annotations already declare readOnly and idempotent hints, so the description enriches the safety profile 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, front-loaded with the core purpose, and includes only essential details. Every sentence adds value: first sentence states action and output, second sentence explains the matching mechanism and paging behavior. 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 tool's complexity (3 parameters, output schema exists, annotations present), the description is complete. It covers purpose, relationship to a sibling tool, matching behavior, paging, and example terms. The output schema handles return value details, so no further description is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add new parameter semantics beyond what the schema already provides for 'query', 'limit', and 'offset'. It contextualizes offset usage (paging) but does not describe parameter formats or constraints 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 verb 'search', the resource 'WHO GHO indicator catalog', and the method 'by keyword in the indicator name'. It also specifies the output ('indicator codes and names') and links to a sibling tool, distinguishing it from the sibling 'who_list_indicators' which likely lists all indicators without search.
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 explicit guidance on when to use the tool (search by keyword), example search terms, and how to handle truncated results (refine query or page with offset). It also mentions the output is for use with 'who_query_indicator_data', giving context. However, it does not explicitly state when not to use it or mention alternatives like 'who_list_indicators' for a full catalog.
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!
Sign in to create a connector for this server.