sanctions-screening-mcp-server
Server Details
Screen names against OFAC, EU, UK, UN sanctions lists; resolve entities via GLEIF. Screening aid.
- 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 has a clearly distinct purpose: list sources, screen names, get designation details, resolve entity names to LEIs, get entity records, and trace ownership. No two tools overlap in functionality.
All tools follow the consistent 'sanctions_verb_noun' pattern (e.g., sanctions_get_designation, sanctions_screen_name). Verbs and nouns are descriptive and uniform.
With 6 tools, the set is appropriately scoped for the domain of sanctions screening and entity resolution. Each tool serves a necessary step in the workflow without being excessive or insufficient.
The tool surface covers the core screening and entity resolution workflow: listing sources, screening names, resolving entities, retrieving details, and tracing ownership. A minor gap is the lack of a tool to manually trigger data refresh, but the set is otherwise well-rounded for its purpose.
Available Tools
6 toolssanctions_get_designationsanctions-screening-mcp-server: get designationARead-onlyIdempotentInspect
Fetch the full record for one sanctions designation by source list + entry ID — the drill-in after sanctions_screen_name surfaces a candidate. Returns all published aliases, identifiers (passport/national-ID/tax), addresses, dates and places of birth, nationalities, sanctioning program, legal basis, and designation date. The record reflects exactly what the source published; missing fields mean the source omitted them. This is a screening aid — the designation record supports a compliance review, it is not itself a determination.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Which source list the entry belongs to. | |
| entryId | Yes | The source list's own entry ID (the sourceEntryId from sanctions_screen_name). |
Output Schema
| Name | Required | Description |
|---|---|---|
| caveat | Yes | Decision-support caveat — this is a screening aid, not a compliance determination. |
| source | Yes | Source list the entry belongs to. |
| aliases | Yes | All published aliases / name variants. |
| program | No | Sanctioning program / regime, when published. |
| remarks | No | Free-form remarks published by the source, when present. |
| addresses | Yes | Published addresses. |
| entityType | Yes | Entity classification as published. |
| legalBasis | No | Statutory / regulatory basis, when published. |
| identifiers | Yes | Published identifiers (passport, national ID, tax, registration, …). |
| primaryName | Yes | Primary published name. |
| sourceLabel | Yes | Human-readable name of the source list. |
| datesOfBirth | Yes | Published dates and places of birth (persons). |
| nationalities | Yes | Published nationalities / citizenships. |
| sourceEntryId | Yes | The source list's own entry ID. |
| designationDate | No | Designation date, when published. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations indicating readOnlyHint=true and idempotentHint=true, the description explains that the record reflects exactly what the source published and missing fields mean the source omitted them. This adds valuable behavioral context.
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 and front-loaded, with each sentence adding distinct value: purpose, usage context, return content, and data fidelity caveat. 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 output schema exists (not shown but described), the description effectively covers purpose, use case, and return fields. It is complete for a drill-in tool with good annotations and 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 coverage is 100% with descriptions for both parameters. The description adds context by linking entryId to 'the sourceEntryId from sanctions_screen_name,' but does not significantly expand beyond schema definitions.
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 'Fetch the full record for one sanctions designation by source list + entry ID — the drill-in after sanctions_screen_name surfaces a candidate.' It uses a specific verb ('Fetch') and resource ('full record'), and distinguishes from sibling tools like sanctions_screen_name and sanctions_get_entity.
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: 'the drill-in after sanctions_screen_name surfaces a candidate.' It also notes the tool is a screening aid, not a determination. However, it does not explicitly state when not to use or exclude alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sanctions_get_entitysanctions-screening-mcp-server: get entityARead-onlyIdempotentInspect
Fetch the full GLEIF Level 1 record for one LEI: legal name, other/trading names, legal and headquarters addresses, registration status, jurisdiction, registration authority and ID, and last-update date — plus any sanctions hits screened against the same legal name across all loaded watchlists. The screening cross-reference is a screening AID: a hit is a candidate to verify against the official source, and no hit is not a clearance. LEI must be a 20-character GLEIF identifier (18 alphanumerics + 2 check digits).
| Name | Required | Description | Default |
|---|---|---|---|
| lei | Yes | The 20-character GLEIF Legal Entity Identifier to look up. |
Output Schema
| Name | Required | Description |
|---|---|---|
| lei | Yes | The 20-character GLEIF Legal Entity Identifier. |
| caveat | Yes | Decision-support caveat — the screening cross-reference is an aid, not a determination. |
| status | No | Registration status (e.g. ISSUED, LAPSED). |
| legalName | Yes | Registered legal name. |
| lastUpdate | No | ISO 8601 last-update timestamp from the LEI record. |
| otherNames | Yes | Other / trading names published in the LEI record. |
| jurisdiction | No | Legal jurisdiction (ISO code), when published. |
| legalAddress | No | Single-line legal address, when published. |
| sanctionsHits | Yes | Sanctions screening cross-reference on the entity's legal name. |
| headquartersAddress | No | Single-line headquarters address, when published. |
| registrationAuthorityId | No | Registration authority (RA) code, when published. |
| registrationAuthorityEntityId | No | The entity's ID at its registration authority, when published. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds important behavioral context: the screening cross-reference (AID), clarifying that a hit is a candidate to verify and no hit is not clearance. It also specifies the LEI format requirement. 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?
Two concise sentences, front-loaded with the main purpose and data content. The second sentence adds critical context about sanctions screening and LEI format. No unnecessary words, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, annotations, an output schema, and low complexity, the description sufficiently covers the input constraints (LEI format) and output ('full GLEIF record plus sanctions hits'). The screening explanation is adequate. Output schema exists so return values don't need explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single 'lei' parameter described with pattern and description. The description adds minimal extra meaning beyond the schema, stating the LEI must be a 20-character GLEIF identifier, which is essentially the same as the pattern. Baseline 3 applies as schema already does the heavy lifting.
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 fetches a GLEIF Level 1 record for one LEI, listing specific data fields (legal name, addresses, registration status, etc.) and sanctions hits. The verb 'Fetch' and resource 'GLEIF Level 1 record' are specific, and the purpose is well-differentiated from sibling tools like sanctions_get_designation and sanctions_screen_name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have an LEI and need the full record with sanctions screening. However, it does not explicitly state when NOT to use it or compare with alternatives like sanctions_resolve_entity for name resolution. The context is clear but lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sanctions_list_sourcessanctions-screening-mcp-server: list sourcesARead-onlyIdempotentInspect
List the sanctions watchlists (OFAC SDN + Consolidated, EU, UK, UN) and GLEIF datasets currently loaded in the local mirror, each with its record count, source URL, license, and the mirror's readiness and as-of timestamp. Use this for provenance and freshness on any result — results are only as current as the last mirror refresh, and a not-ready mirror means screening cannot run yet. Attribution: UK data is under the Open Government Licence v3.0; all sources are cited here.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| leiAsOf | No | ISO 8601 timestamp of the last completed GLEIF sync, when available. |
| sources | Yes | All loaded sources, sanctions lists then the GLEIF dataset. |
| leiReady | Yes | True once the GLEIF (LEI) mirror has completed at least one full sync. |
| sanctionsAsOf | No | ISO 8601 timestamp of the last completed sanctions sync, when available. |
| sanctionsReady | Yes | True once the sanctions mirror has completed at least one full sync. |
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 valuable context about mirror readiness affecting screening and freshness of data, which goes 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 sentences efficiently cover purpose, content, usage, and caveats. No wasted words; front-loaded with the core action.
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?
Complete for a simple list tool with no parameters and existing output schema. Covers what is listed, why it matters, and a critical caveat about mirror readiness.
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 (0 params, 100% schema coverage). Baseline 4 is appropriate as description doesn't need to add param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists sanctions watchlists and GLEIF datasets with specific details (record count, URL, license, readiness). Verb 'list' and resource are explicit, and it distinguishes from sibling tools like sanctions_screen_name.
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?
Specifies use case for provenance and freshness, and explains that results depend on mirror refresh. Provides clear context for when to use, though no explicit when-not-to-use or alternative comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sanctions_resolve_entitysanctions-screening-mcp-server: resolve entityARead-onlyIdempotentInspect
Resolve a company or organization name (with an optional ISO 3166-1 alpha-2 jurisdiction) to candidate GLEIF Legal Entity Identifiers (LEIs), ranked. This turns a free-text counterparty name into a stable global identifier that sanctions_get_entity and sanctions_trace_ownership key off. Strict mode (default) matches exact-normalized then all-tokens-present; fuzzy mode (or auto when strict is empty) adds Jaro-Winkler scoring labeled approximate with a raw 0–1 score. Returns potential matches to confirm against the GLEIF record — name resolution is a candidate ranking, not an authoritative identification.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The company / organization name to resolve to an LEI. | |
| limit | No | Maximum LEI candidates to return. | |
| status | No | Registration status filter: issued (default), lapsed, or any. | issued |
| minScore | No | Jaro-Winkler floor for fuzzy hits (0–1); defaults to the server's configured floor. | |
| matchMode | No | strict (default): exact then all-tokens-present. fuzzy: also scored Jaro-Winkler. | strict |
| jurisdiction | No | Optional ISO 3166-1 alpha-2 jurisdiction filter (e.g. "US", "GB"). Empty string disables it. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance when no LEI matched and how to broaden. |
| matches | Yes | Ranked LEI candidates, highest-confidence first. |
| totalCount | Yes | Number of LEI candidates returned. |
| matchModeUsed | Yes | The match mode actually applied (strict may upgrade to fuzzy). |
| normalizedQuery | Yes | The name as the server folded it for matching. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the matching algorithm details (exact-normalized, all-tokens-present, Jaro-Winkler scoring), and notes the non-authoritative nature of results. All annotations (readOnlyHint, idempotentHint) are consistent and the description adds value beyond 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 a single dense paragraph; every sentence is informative with no fluff. Minor improvement could be splitting into purpose and behavior sections, but overall it is concise 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?
Given the tool's complexity (6 params, 2 enums) and presence of output schema, the description fully explains the tool's role, matching behavior, and how results should be used. It assumes proper integration with sibling tools, which is correct for an MCP context.
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 adds context by explaining how matchMode and jurisdiction interact (e.g., fuzzy mode auto-triggered when strict empty) and how minScore works, which is beyond the schema's individual parameter 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 it resolves a company/organization name to GLEIF Legal Entity Identifiers (LEIs), and explicitly mentions it feeds into sibling tools sanctions_get_entity and sanctions_trace_ownership, differentiating it from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains strict vs fuzzy matching modes and when each applies, and clarifies that results are candidate rankings not authoritative. However, it does not explicitly state when not to use this tool (e.g., if LEI already known).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sanctions_screen_namesanctions-screening-mcp-server: screen nameARead-onlyIdempotentInspect
Screen a name (person, company, vessel, aircraft) against all loaded sanctions watchlists at once — OFAC SDN + Consolidated, EU, UK, and UN — alias- and fuzzy-aware. Returns scored potential matches with the source list, sanctioning program, designation date, and the matched alias. Strict mode (default) matches exact-normalized then all-tokens-present; fuzzy mode (or auto when strict is empty) adds Jaro-Winkler and phonetic matching and labels hits approximate with a raw 0–1 similarity score. This is a screening AID for a human/compliance review, NOT a compliance determination: a hit means "review this candidate against the official source," and an empty result never means "cleared."
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name to screen (person, organization, vessel, or aircraft). | |
| limit | No | Maximum number of potential matches to return. | |
| sources | No | Restrict to specific source lists. Omit to screen all loaded lists. | |
| minScore | No | Score floor for fuzzy hits (0–1), applied uniformly to every fuzzy candidate regardless of how it was matched (Jaro-Winkler, token, or phonetic). No hit below this score is returned. Applies to fuzzy mode only; defaults to the server's configured floor. | |
| matchMode | No | strict (default): exact-normalized then all-tokens-present. fuzzy: also scored Jaro-Winkler + phonetic. Strict auto-falls-back to fuzzy when it finds nothing. | strict |
| entityType | No | Restrict to one entity class, or "any" (default) to screen across all. | any |
Output Schema
| Name | Required | Description |
|---|---|---|
| hits | Yes | Scored potential matches, highest-confidence first. |
| caveat | Yes | Decision-support caveat — this is a screening aid, not a compliance determination. |
| notice | No | Guidance when no candidate matched — how to broaden, and what an empty result does NOT mean. |
| totalCount | Yes | Number of potential matches returned. |
| matchModeUsed | Yes | The match mode actually applied (strict may auto-upgrade to fuzzy on empty). |
| normalizedQuery | Yes | The name as the server folded it for matching. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description adds critical behavioral context: it is a screening aid for human review, not a compliance determination; a hit means 'review', and an empty result never means 'cleared'.
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 efficiently structured: first sentence states purpose, then explains modes and fallback behavior, then important caveats. Every sentence adds information 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?
Given 6 parameters and an output schema, the description covers the tool's purpose, matching modes, source lists, entity type filtering, score thresholds, and essential disclaimers, providing a complete picture for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the matchMode behaviors (strict exact-normalized then all-tokens, fuzzy adds Jaro-Winkler and phonetic) and the minScore filtering, going beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool screens a name against multiple sanctions watchlists (OFAC, EU, UK, UN) with alias and fuzzy matching, distinguishing it from siblings like sanctions_get_designation or sanctions_get_entity which retrieve individual records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (e.g., screening names against all lists) and explains the strict vs. fuzzy mode behavior, but lacks explicit 'when not to use' guidance relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sanctions_trace_ownershipsanctions-screening-mcp-server: trace ownershipARead-onlyIdempotentInspect
Trace the GLEIF Level 2 corporate-ownership graph for an LEI: direct and ultimate parents and/or children, traversed breadth-first to a bounded depth, with relationship type for each edge. Set screenNodes to also screen every entity in the graph against all loaded watchlists — beneficial-ownership screening that resolves "is anyone in this ownership chain sanctioned." Each per-node screen is a screening AID: hits are candidates to verify, and an empty result for a node is not a clearance of that node. Requires a valid 20-character LEI (use sanctions_resolve_entity to obtain one).
| Name | Required | Description | Default |
|---|---|---|---|
| lei | Yes | The 20-character GLEIF LEI at the root of the ownership graph. | |
| depth | No | Maximum traversal depth from the root entity (1–5). | |
| direction | No | Walk parents (who owns it), children (what it owns), or both (default). | both |
| screenNodes | No | When true, screen every node's legal name against all watchlists for beneficial-ownership screening. |
Output Schema
| Name | Required | Description |
|---|---|---|
| edges | Yes | Directed ownership edges between the nodes. |
| nodes | Yes | All entities reached in the traversal, including the root. |
| caveat | Yes | Decision-support caveat — node screening is an aid, not a determination. |
| rootLei | Yes | The LEI the traversal started from. |
| flaggedNodeCount | Yes | How many screened nodes had at least one potential watchlist match. |
| screenedNodeCount | Yes | How many nodes were screened (0 when screenNodes is false). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world hints. The description adds valuable nuance: screening results are candidates to verify, and empty results are not clearance. 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?
Three efficient sentences front-loading purpose and critical behavioral context. No redundant 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 complex traversal and screening functionality, the description covers ownership graph, depth, direction, screening behavior, and prerequisite. Output schema covers return values, so no gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. The description adds meaning for screenNodes (screening each node, results interpretation) and depth (bounded, breadth-first). Adds value beyond 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 'Trace the GLEIF Level 2 corporate-ownership graph for an LEI', specifying a specific verb and resource, and distinguishes from siblings like sanctions_resolve_entity which obtains LEIs.
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: when to use for ownership tracing and beneficial-ownership screening via screenNodes parameter. It explicitly mentions the prerequisite of a valid LEI and directs to sanctions_resolve_entity, but does not explicitly state when not to use.
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!