Screen names against OFAC, EU, UK, UN sanctions lists; resolve entities via GLEIF. Screening aid.
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.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.
sanctions_get_designationsanctions-screening-mcp-server: get designationAFetch 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). |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint; description adds that the record reflects published data exactly and missing fields mean omitted by source. No contradictions; useful behavioral 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?
Three sentences, front-loaded with purpose. Every sentence adds value: purpose, return content, caveat about missing fields, and limitation. 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 presence of an output schema, the description adequately covers scope, caveats, and tool relationship. No gaps for a drill-in lookup tool with annotations and 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 coverage is 100% with good descriptions. The description mentions the parameters (source list and entry ID) but adds no new semantic details beyond reinforcing the relationship to screen_name output.
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 the tool's purpose: fetch full record for a sanctions designation by source list and entry ID. Identifies it as the drill-in after sanctions_screen_name, distinguishing it from sibling 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?
Explicitly says when to use (after screening has surfaced a candidate) and notes it is a screening aid not a determination. Lacks explicit when-not-to-use or alternatives, but the context is clear enough.
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 entityAFetch 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. |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's burden is reduced. It adds valuable context: the tool returns both GLEIF record and sanctions hits, and clarifies that screening results are cross-references (not definitive clearances). 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 two sentences with no wasted words. The first sentence front-loads the core purpose and returned fields; the second adds essential nuance about screening interpretation. Every part 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?
Given that an output schema exists (indicated in context), the description does not need to detail return format. It covers all key aspects: what entity data is returned, that sanctions hits are included, and how to interpret those hits. For a simple fetch tool, this is fully 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% and there is only one parameter (lei). The description restates the format constraint ('20-character GLEIF identifier') already in the schema pattern, adding minimal extra value. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' and identifies the resource as 'full GLEIF Level 1 record for one LEI', listing the exact fields returned. It clearly distinguishes from sibling tools like sanctions_screen_name (which screens a name without an LEI) and sanctions_get_designation (which fetches designation 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 implies usage when you have a valid 20-character LEI and need both GLEIF entity data and sanctions screening results. It explains that a hit is a candidate to verify and no hit is not clearance, guiding interpretation. However, it does not explicitly contrast with siblings (e.g., when to use sanctions_screen_name instead).
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 sourcesAList 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 | |||
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent. Description adds critical behavioral info: mirror readiness affects screening capability, and provides attribution for data sources. No 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?
Two sentences, front-loaded with key data, followed by usage advice and attribution. 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 no parameters, rich annotations, and output schema, the description fully covers purpose, usage, behavioral readiness, and attribution. Complete for this tool's simplicity.
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 baseline 4 applies. Description adds no param info (unnecessary) but effectively covers the tool's zero-input nature.
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 sanctions watchlists and GLEIF datasets with specific details (record count, source URL, license, readiness, as-of timestamp). It distinguishes from sibling tools which focus on entities and screening.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises use for provenance and freshness checking, and notes that a not-ready mirror blocks screening. Could be more explicit about when not to use (e.g., for actual screening) but provides clear context.
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 entityAResolve 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. |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds substantial behavioral context: matching algorithm details (exact-normalized, all-tokens-present, Jaro-Winkler), scoring, candidate ranking nature, and that it's not authoritative identification. 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 (4 sentences) and front-loaded with the main purpose. Every sentence adds necessary information without redundancy. Well-structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, enums, multiple modes, output schema), the description covers the matching logic, ranking, relationship to sibling tools, and caveats. The presence of an output schema reduces the need to explain return values here. Completeness is high.
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 algorithmic purpose of parameters like matchMode, minScore, and status, and how jurisdiction and limit affect results. This goes beyond mere 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 resolves a company/organization name to candidate GLEIF LEIs, with optional jurisdiction filter. It uses specific verbs like 'resolve' and 'turns a free-text counterparty name into a stable global identifier', and it distinguishes from siblings like sanctions_get_entity which keys off 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 explains the tool's role as a precursor to sanctions_get_entity and sanctions_trace_ownership, and describes when to use strict vs fuzzy modes. It provides clear context on the matching algorithm but does not explicitly state when not to use the tool or list alternatives beyond the mentioned siblings.
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 nameAScreen 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 |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description extensively details behavioral traits such as strict vs fuzzy matching, alias handling, scoring, and fallback logic, going well beyond the readOnlyHint and idempotentHint annotations. It also warns that empty results are not clearance, adding crucial 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 well-structured: it opens with the core function, explains matching modes, and ends with a critical caveat. No superfluous sentences.
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 parameters, output schema exists), the description covers all essential aspects: purpose, matching behavior, output interpretation, and usage warnings. It is fully adequate for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description adds value by explaining the matching algorithm for matchMode, the scoring for minScore, and how modes interact. This provides deeper understanding than the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool screens a name against all loaded sanctions watchlists, using verbs like 'Screen' and specifying resources (person, company, vessel, aircraft). It distinguishes itself from sibling tools like sanctions_get_entity by focusing on screening rather than retrieving specific designations.
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 context on when to use the tool (as a screening aid for compliance review) and cautions about its limitations (not a compliance determination). However, it does not explicitly compare with sibling tools to guide selection, though the context is largely implied.
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 ownershipATrace 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. |
| 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). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations (readOnlyHint, idempotentHint, openWorldHint). It explains that each node screen produces a screening AID, that hits are candidates to verify, and that empty results are not clearances. It also clarifies the beneficial-ownership screening purpose. 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 substantive but efficient, front-loading the main purpose and then explaining optional screening behavior and caveats. It is structured logically: core action, screening explanation, caution on interpretation, prerequisite. A few words could be trimmed, but it earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (4 params, output schema exists), the description covers key aspects: traversal direction and depth, optional screening, result interpretation, and LEI prerequisite. The output schema is not described verbatim but exists separately. It omits details on relationship type representation but is otherwise 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%, so baseline is 3. The description does not add significant meaning beyond the schema for parameters like lei, depth, direction, screenNodes. It mentions 'relationship type for each edge' but that pertains to output, not parameters. No additional param guidance is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool traces GLEIF Level 2 corporate-ownership graphs for an LEI, listing direct and ultimate parents/children with breadth-first traversal and relationship types. It clearly differentiates from sibling tools like sanctions_get_entity (single entity lookup) and sanctions_screen_name (name screening) by focusing on ownership graph traversal and optional beneficial-ownership screening.
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 tells when to use the tool (trace ownership graph) and requires a valid 20-character LEI, directing users to sanctions_resolve_entity to obtain one. It implies when not to use (e.g., for simple entity lookup or name screening) but does not explicitly exclude alternatives or state when-to-use vs. when-not-to-use, leaving some implicit context.
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.