medical-codes-mcp-server
Server Details
Offline US medical code lookup and crosswalk — ICD-10-CM/PCS, HCPCS Level II, RxNorm. Keyless.
- 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.5/5 across 6 of 6 tools scored.
Each tool targets a distinct operation (browse, check, get, list, map, search) on medical codes. There is no overlap in purpose; even browse_hierarchy and map_codes differ in that browse discovers structure while map navigates explicit relationships.
All tools follow a consistent 'medcode_verb_noun' pattern with clear verbs (browse, check, get, list, map, search). No mixing of conventions, all snake_case.
Six tools cover the core operations for a medical code reference server: browsing, validation, decoding, system listing, mapping, and searching. The count is well-scoped for the domain without being overwhelming.
The tool surface provides comprehensive coverage for working with US medical codes: hierarchical exploration, validation, batch decoding, system metadata, crosswalk/mapping, and full-text search. There are no obvious gaps for the intended use case.
Available Tools
6 toolsmedcode_browse_hierarchymedical-codes-mcp-serverARead-onlyIdempotentInspect
Walk a US medical code system's hierarchy for discovery without a search term. With no node, returns the top-level entries (ICD-10-CM categories, HCPCS range buckets, or ICD-10-PCS first-axis values). With a node, returns its immediate children. ICD-10-CM and HCPCS use a prefix hierarchy (a shorter code is the parent of a longer one); ICD-10-PCS is axis-based — each of its 7 characters is an independent axis (section, body system, root operation, body part, approach, device, qualifier), but only the top-level Section axis is browsable (omit node): positions 2–7 are context-dependent on the preceding axis path and are not enumerable from a flat partial code. Lets an agent orient in an unfamiliar system or enumerate a category's specific codes.
| Name | Required | Description | Default |
|---|---|---|---|
| node | No | A node to expand. For ICD-10-CM/HCPCS, a code whose children to list. ICD-10-PCS supports only top-level Section browsing (omit `node`) — a partial PCS code does not expand to next-position axis values. Omit for the top level. | |
| limit | No | Max entries to return. Defaults to MEDCODE_MAX_RESULTS (50), ceiling 200. | |
| system | Yes | The code system to browse. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | Yes | The limit that was applied. |
| axes | Yes | The top-level ICD-10-PCS Section axis values (only the Section axis is enumerable). Empty when kind is "codes". |
| kind | Yes | "codes" for prefix-hierarchy children (ICD-10-CM/HCPCS); "axes" for ICD-10-PCS axis values. |
| codes | Yes | Child codes under the requested node or top level. Empty when kind is "axes". |
| shown | Yes | Number of entries returned (codes or axes). |
| notice | No | Guidance when a node has no children/axes — suggests the top level or a valid node. |
| truncated | Yes | True when the returned list was capped at the limit. |
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 context beyond that, such as the axis-based hierarchy for ICD-10-PCS and the prefix hierarchy for other systems, which is crucial for correct usage. 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 fairly long but well-structured. It front-loads the core purpose and then provides system-specific details. Every sentence adds value, though some repetition could be trimmed. Overall, it justifies its length given the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so the description doesn't need to detail return values. It covers key aspects: what the tool does, how to use it for each system, and important limitations. For a browse tool with multiple systems, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning beyond the schema by explaining how 'node' behaves differently across systems (prefix vs axis) and notes that 'limit' defaults to MEDCODE_MAX_RESULTS with a ceiling of 200. This helps the agent understand parameter semantics in context.
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: walking a US medical code system's hierarchy for discovery without a search term. It specifies the verb ('walk'), resource ('hierarchy'), and distinguishes from sibling search tools. It also explains behavioral differences between code systems, making the purpose 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 tells when to use the tool (for discovery without a search term) and provides guidance on how to use it with different systems, including limitations (e.g., ICD-10-PCS only top-level browsing). It doesn't explicitly state when not to use, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
medcode_check_codemedical-codes-mcp-serverARead-onlyIdempotentInspect
Validate whether a US medical code exists, is current, and is billable in the active bundled release. Returns a discriminated status — valid_billable, valid_not_billable, valid_header, or terminated — with a whyNot explaining non-billable and terminated cases (e.g. "valid ICD-10-CM category but not billable — submit a more specific child code"). This is the detail a coder needs before submitting a claim. Auto-detects the system from the code's shape; pass an explicit system to disambiguate. A non-billable or terminated code is a successful result with a whyNot, not an error — only a code that exists in no bundled system raises unknown_code.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The code to validate, with or without dots. | |
| system | No | Force the lookup into this system. Omit to auto-detect from the code's shape. |
Output Schema
| Name | Required | Description |
|---|---|---|
| code | Yes | The code in display form (ICD-10-CM carries the dot). |
| status | Yes | Validity status. valid_billable = submit as-is; valid_header/valid_not_billable = needs a more specific code; terminated = retired. |
| system | Yes | The system the code was resolved in, echoed for chaining. |
| whyNot | Yes | Explanation for non-billable/terminated statuses, or null when valid_billable. |
| billable | Yes | True only when status is valid_billable. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnly and idempotent hints. Description adds detailed behavior: discriminated status values, whyNot explanations, and that unknown_codes raise errors. 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 a single dense paragraph but front-loads the core purpose. It could be slightly more structured (e.g., bullet points), but each sentence is informative and 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 tool with 2 params and an output schema, the description covers all necessary context: purpose, behavior, interpretation of results, and parameter usage. Output schema handles detailed return structure.
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?
Both parameters are fully described in schema (100% coverage). Description adds guidance on auto-detection vs explicit system, which adds value beyond the schema's static 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 validates whether a US medical code exists, is current, and is billable. It distinguishes from siblings (browse, get, list, map, search) by focusing on billing validation and specific statuses.
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 auto-detection of system from code shape and when to use explicit system parameter. Also clarifies that non-billable/terminated results are successful, not errors, guiding correct interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
medcode_get_codemedical-codes-mcp-serverARead-onlyIdempotentInspect
Decode one or more US medical codes to their official descriptions across ICD-10-CM (diagnoses), ICD-10-PCS (inpatient procedures), HCPCS Level II (supplies/drugs/services), and RxNorm (drugs, by RXCUI). Also decodes a National Drug Code (NDC) — hyphenated or 10/11-digit — directly to its RxNorm product offline, tagged source: "NDC". Auto-detects the system from each code's shape; pass an explicit system only when a value is genuinely ambiguous. Accepts 1–50 codes and returns partial success: resolved codes in found, unresolved in notFound with a per-code reason, so one bad code never fails the batch. Set includeHierarchy to attach each code's parent and immediate children. The resolved system is echoed on every result for chaining into medcode_map_codes or a billability check.
| Name | Required | Description | Default |
|---|---|---|---|
| codes | Yes | Codes to decode (1–50). Mixed systems are fine — each is detected independently. An NDC (hyphenated or 10/11-digit) decodes to its RxNorm product. | |
| system | No | Force every code to be looked up in this system. Omit to auto-detect per code. | |
| includeHierarchy | No | When true, attach each found code's parent and immediate children. |
Output Schema
| Name | Required | Description |
|---|---|---|
| found | Yes | Successfully decoded codes, in request order. |
| notFound | Yes | Codes that did not resolve, with per-code reasons. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description adds critical behavioral details: partial success with found/notFound fields, per-code reasons for failures, auto-detection of code systems, NDC decoding tagged with source, and the effect of includeHierarchy. It fully discloses error handling and output structure.
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 comprehensive but somewhat lengthy. It front-loads the core purpose and adds details in a logical order. While each sentence serves a purpose, a slight trim could improve conciseness without losing 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?
Given the tool's complexity (multiple code systems, batch processing, partial success, hierarchy support), the description covers all necessary aspects: input, output, error handling, parameter usage, and integration with sibling tools. The existence of an output schema (not shown) further reduces burden on 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?
Schema coverage is 100%, and the description adds significant value by explaining code format flexibility (dots allowed), mixed systems, NDC specifics (hyphenated or 10/11-digit), the system parameter's auto-detect behavior, and the hierarchy parameter's effect. This enriches the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool decodes US medical codes to official descriptions across multiple systems, including ICD-10-CM, ICD-10-PCS, HCPCS, RxNorm, and NDCs. It distinguishes itself from siblings by focusing on decoding and mentioning chaining into medcode_map_codes or billability checks.
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 for when to use the tool (decoding codes) and specific guidance on when to pass an explicit system (only when ambiguous). It suggests chaining for further operations but does not explicitly exclude when not to use or compare with all sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
medcode_list_systemsmedical-codes-mcp-serverARead-onlyIdempotentInspect
List the bundled US medical code systems with their release identifiers, effective dates, and code counts. Confirms which ICD-10-CM fiscal year, ICD-10-PCS fiscal year, HCPCS Level II release, and RxNorm Prescribable Content snapshot are active before acting on any decode, search, or crosswalk result. The corpus is offline and built at package-build time — this call reports exactly which release is baked into the running server. ICD-10-CM/PCS are the US clinical modifications, not the ICD-10/ICD-11 base.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| systems | Yes | One entry per bundled code system, in canonical order. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. Description adds that the corpus is offline and built at package-build time, reporting exactly which release is baked in, which is additional 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?
Description is two sentences, front-loaded with the main action. It is concise but could be slightly more terse without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, rich annotations, and existence of an output schema, the description fully covers what the tool does and why it matters, leaving 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?
Input schema has no parameters and coverage is 100%, so description does not need to add parameter details. The lack of parameters is self-evident.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists US medical code systems with specific attributes (release identifiers, effective dates, code counts), and distinguishes itself from sibling tools by focusing on system listing rather than browsing, checking, or mapping codes.
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?
Description explains the tool is used to confirm which release is active before acting on decode, search, or crosswalk results, providing context for when to use it. It does not explicitly state when not to use or mention alternatives, but the intended usage is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
medcode_map_codesmedical-codes-mcp-serverARead-onlyIdempotentInspect
Crosswalk a US medical code or drug across systems and within a hierarchy. Hierarchy directions: parents and children walk a code's prefix hierarchy one level per call — immediate parent/children only (depth-1); call iteratively for the full ancestor or descendant path (ICD-10-CM/HCPCS; ICD-10-PCS codes have no prefix parent). A resolvable code with no edge in the requested direction is a successful empty result with a notice, not an error. Drug directions (RxNorm): name_to_rxcui (drug name → RXCUI), ndc_to_rxcui and rxcui_to_ndc (NDC ↔ RXCUI; NDCs accepted hyphenated or 10/11-digit), rxcui_to_ingredients and rxcui_to_brands (RXCUI → ingredient/brand RXCUIs). Every result carries source provenance (which system or edge answered) so a chained call (e.g. into openfda with a resolved NDC) uses the right identifier.
| Name | Required | Description | Default |
|---|---|---|---|
| from | Yes | The source value: a code (for parents/children), a drug name, an NDC, or an RXCUI. | |
| system | No | For parents/children, force the source code into this system. Omit to auto-detect. | |
| direction | Yes | What to map to. parents/children return the immediate parent or children only (depth-1) — call iteratively to walk a full path; the rxcui/ndc/name directions are RxNorm drug crosswalks. |
Output Schema
| Name | Required | Description |
|---|---|---|
| from | Yes | The source value, echoed back. |
| hits | Yes | Crosswalk results, each tagged with the edge that produced it. |
| notice | No | Guidance when a resolvable code has no edge in the requested direction (e.g. a top-level code has no parent; a leaf has no children; ICD-10-PCS codes have no prefix parent). |
| direction | Yes | The mapping direction that was applied. |
| resolvedSystem | Yes | The system the source resolved in, or null when not system-scoped. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and idempotentHint=true. The description adds behavioral context beyond annotations: it explains that a resolvable code with no edge in the requested direction returns a successful empty result with a notice (not an error), and that hierarchy calls return only depth-1. It also mentions provenance information in results. There is no contradiction 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 given the complexity, with every sentence adding value. It is well-structured: first sentence defines the overall purpose, then explains hierarchy directions (with depth-1 limitation and iterative usage), followed by drug directions (with specific examples), and finally provenance information. It is front-loaded and avoids redundancies, though it is slightly lengthy but justified by the tool's multiple modes.
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, 7 enum directions, multiple modes), the description is complete. It covers all directions, explains the iterative pattern for hierarchy, mentions the empty result behavior, and notes provenance. It does not detail the output format, but an output schema exists (not shown), so that is acceptable. The description addresses edge cases and usage nuances adequately.
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 each parameter has a description. The description enriches understanding by explaining the meaning of each direction enum value, including that parents/children are depth-1 and drug directions are for RxNorm crosswalks. It also clarifies that NDCs can be entered with hyphens or as 10/11-digit strings, and that the 'from' parameter can be a code, drug name, NDC, or RXCUI, adding context beyond the 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 opens with 'Crosswalk a US medical code or drug across systems and within a hierarchy,' clearly stating the verb (crosswalk), resource (codes/drugs), and scope (across systems and hierarchy). It distinguishes itself from sibling tools by detailing the specific mapping directions (parents, children, drug crosswalks) and explains that hierarchy directions are depth-1, requiring iterative calls for full paths. This level of specificity differentiates it from, e.g., medcode_browse_hierarchy, which likely handles browsing the hierarchy without mapping.
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: for crosswalking codes or drugs, including specific uses like mapping between NDC and RXCUI. It provides guidance on the depth-1 nature of hierarchy directions and advises calling iteratively for full paths. It also clarifies that an empty result is not an error but a successful response with a notice. However, it does not explicitly mention when not to use or list alternative tools, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
medcode_search_codesmedical-codes-mcp-serverARead-onlyIdempotentInspect
Find US medical codes whose official descriptions match a described concept, via full-text search over the bundled index. Every search term must appear (prefix-matched), so "diabetic neuropathy" returns codes mentioning both. Filter by system (ICD10CM/ICD10PCS/HCPCS/RXNORM), billableOnly to exclude headers/categories, and chapter. Use when you have a clinical description and need the code — the reverse of medcode_get_code. Results echo the resolved system per row for chaining, and disclose truncation when the result hits the cap.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max codes to return. Defaults to the server's MEDCODE_MAX_RESULTS (50), ceiling 200. | |
| query | Yes | Clinical description to match, e.g. "type 2 diabetes with neuropathy". | |
| system | No | Restrict results to one system. Omit to search all bundled systems. | |
| chapter | No | Restrict to a chapter/range bucket (the value from a code's `chapter` field). | |
| billableOnly | No | When true, return only billable leaf codes (exclude headers/categories). |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | Yes | The limit that was applied. |
| codes | Yes | Matching codes, ranked by full-text relevance. |
| shown | Yes | Number of codes returned. |
| notice | No | Guidance when nothing matched — echoes the query and suggests how to broaden. |
| truncated | Yes | True when results were capped at the limit. |
| appliedFilters | Yes | Filters the server applied to the search. |
| effectiveQuery | Yes | The query as the server parsed it for matching. |
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 beyond these: it explains full-text search behavior, prefix matching, resolved system per row in results, and truncation disclosure. No contradiction 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 at 4 sentences, with the most important information (purpose and matching logic) in the first sentence. Every sentence adds essential detail without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all necessary behavioral aspects for a search tool with good annotations and a full output schema. It explains result features (resolved system, truncation) and filter options. No gaps remain given the rich supporting artifacts.
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 context for each parameter: it explains the matching logic for query, the available systems for system, the effect of billableOnly, the chapter filter, and the limit default and ceiling. This adds meaningful semantics 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's purpose: finding US medical codes via full-text search over a bundled index. It specifies the matching requirement (every term must appear, prefix-matched) and contrasts with the sibling tool medcode_get_code, which is the reverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool: when you have a clinical description and need the code. It also names the sibling tool medcode_get_code as the alternative for reverse lookup. However, it does not explicitly list all sibling tools or detail when not to use this tool, so it loses 1 point for completeness.
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!