Hosted, zero-install MCP for source-provenanced US federal healthcare provider data. Resolve any NPI or CCN across NPPES, OIG LEIE, SAM.gov, state Medicaid exclusions, PECOS, Care Compare, and Open Payments — every field carries a 14-field provenance contract, with an "excluded or compromised anywhere" check on every lookup.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.4/5 across 9 of 9 tools scored.
Most tools have clearly distinct purposes, but there is potential confusion between check_exclusion, search_sanctions, and lookup_npi since all touch exclusion data. However, descriptions clarify the entry point (NPI vs name) and specific sources, making misselection unlikely but possible for agents unfamiliar with the domain.
Every tool follows the consistent prefix_verb_noun pattern (e.g., fonteum_lookup_npi, fonteum_search_providers). The verbs are varied but appropriate to the action, and the naming convention is uniform throughout.
With 9 tools, the server is well-scoped for a healthcare provider data and compliance lookup service. Each tool covers a distinct operation, and the count is within the ideal range for such a domain.
The surface covers core workflows: provider lookup, search, exclusion checking, sanctions screening, contractor lookup/history, dataset info, and snapshot verification. Minor gaps exist such as no historical NPI lookup or batch search, but these are not critical for the server's purpose.
fonteum_check_exclusionACheck whether a US healthcare provider by NPI appears in available exclusion or integrity sources: OIG LEIE, SAM.gov exclusions, available state Medicaid lists, OIG Corporate Integrity Agreements, and CMS Civil Money Penalties. Returns dated source context and fail-closed coverage; source_file and snapshot_digest may be null for the multi-source result. Use for exclusion screening, provider or vendor due diligence, or any ‘is this NPI excluded?’ question.
| Name | Required | Description | Default |
|---|---|---|---|
| npi | Yes | 10-digit NPI to check against OIG LEIE, SAM.gov, available state Medicaid exclusion lists, OIG CIA, and CMS penalties. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the readOnlyHint annotation: it returns 'dated source context and fail-closed coverage' and notes that 'source_file and snapshot_digest may be null for the multi-source result.' This helps set expectations about output and edge cases. It does not contradict the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and source enumeration, then the return behavior and use cases. Every sentence carries meaningful information and there is no redundancy or filler.
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 a single simple parameter, no output schema, and a readOnlyHint, the description conveys the inputs, coverage, return characteristics, and intended use cases. It is sufficiently complete for an agent to decide when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the single npi parameter with 100% coverage, including '10-digit NPI' and the source lists. The description adds use-case context but no additional parameter-specific details, so it meets the baseline without going beyond.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Check whether') and the resource ('US healthcare provider by NPI appears in available exclusion or integrity sources'), enumerating the specific source lists. It does not explicitly contrast with similar sibling tools like search_sanctions or lookup_npi, so it misses the full 'distinguishes from siblings' bar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use context: 'Use for exclusion screening, provider or vendor due diligence, or any “is this NPI excluded?” question.' This is clear usage guidance, but it does not mention when not to use this tool or suggest alternatives, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fonteum_get_dataset_infoAGet Fonteum API and MCP methodology, provenance-field definitions, generated source catalog, and separately dated platform coverage. Field population varies by source and response. Use for interpreting Fonteum outputs, citation fields, dataset limitations, or integration planning.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation. The description adds valuable caveats: 'Field population varies by source and response' and 'separately dated platform coverage,' which inform users about data completeness and temporal variability.
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 concise, purposeful sentences. The main function is front-loaded, followed by a caveat and usage guidance. No fluff or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter metadata tool, the description covers what is returned (methodology, provenance fields, source catalog, coverage dates), usage scenarios, and a limitation. It lacks an explicit mention of output format, but the content list compensates reasonably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the baseline of 4 applies. The description correctly avoids inventing parameter details and instead focuses on the content returned, which 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 clearly states the tool retrieves Fonteum API/MCP methodology, provenance-field definitions, source catalog, and platform coverage. This distinguishes it from data-lookup siblings like fonteum_lookup_npi or fonteum_search_providers, though it could be more pointed about being a metadata-only endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states usage context: 'Use for interpreting Fonteum outputs, citation fields, dataset limitations, or integration planning.' It does not name alternatives or give when-not-to-use guidance, but the intended scenarios are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fonteum_list_sourcesAList Fonteum’s public-record source catalog with available authority, vertical, cadence, official URL, and separately dated platform coverage. Catalog presence does not prove loaded, fresh, or complete coverage. Use for source discovery, coverage questions, or choosing a dataset before a lookup.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses an important nuance: catalog presence does not prove loaded, fresh, or complete coverage, and platform coverage is separately dated. This adds meaningful behavioral context that the annotation alone does not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and every clause adds value. It avoids redundancy and clearly communicates both functionality and limitations without unnecessary verbosity.
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 simple list tool with no parameters and no output schema, the description covers the tool's purpose, the content of the catalog, and important caveats about data freshness. It also gives concrete use cases, making it complete enough for an agent to select and invoke 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?
The tool has no parameters, and the schema coverage is 100%, so there are no parameter semantics to clarify. The baseline for zero-parameter tools is 4; the description also mentions the output fields, which helps set expectations even though it is not about parameters.
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 identifies the tool as listing Fonteum's public-record source catalog, specifying what fields are included (authority, vertical, cadence, official URL, platform coverage). This distinguishes it from sibling lookup/search tools, which target specific records or datasets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'for source discovery, coverage questions, or choosing a dataset before a lookup.' It also provides a key caveat that catalog presence does not guarantee loaded or fresh coverage, helping the agent decide if this tool is appropriate versus other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fonteum_lookup_contractorALook up a US federal contractor by UEI or CAGE in available SAM.gov, USASpending, FAPIIS, and FAR 4.18 records. Returns dated source context; source_file and snapshot_digest are nullable when no single retained snapshot represents the response. Use for contractor identity, registration, award, responsibility, or ownership due diligence.
| Name | Required | Description | Default |
|---|---|---|---|
| uei | No | 12-character GSA Unique Entity ID. Provide this or cage. | |
| cage | No | 5-character CAGE/NCAGE code. Provide this or uei. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that results include 'dated source context' and that 'source_file and snapshot_digest are nullable when no single retained snapshot represents the response.' Since annotations already declare readOnlyHint=true, this additional edge-case behavior about nullable fields is valuable and goes beyond the annotation, helping the agent handle incomplete responses without contradicting the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and sources, followed by return behavior and use cases. Every clause carries weight; there is no redundancy, and the structure allows quick parsing by an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately covers the essential return semantics ('dated source context', nullable 'source_file' and 'snapshot_digest') and gives clear use cases. Given the simple 2-parameter schema and read-only annotation, this is nearly complete. A brief note pointing to the history sibling for past records would make it fully complete, but it is already strong.
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%, with both parameters fully described (character lengths and mutual exclusivity). The tool description only restates 'by UEI or CAGE' and adds no new parameter-level meaning. It stays at the baseline for high schema coverage, as the description does not compensate for missing info or add examples 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 opens with a specific verb and resource: 'Look up a US federal contractor by UEI or CAGE' and names concrete data sources (SAM.gov, USASpending, FAPIIS, FAR 4.18). This clearly defines the tool's scope and differentiates it from siblings like history or sanctions, as it focuses on current contractor records across these sources.
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 explicitly states the intended use: 'Use for contractor identity, registration, award, responsibility, or ownership due diligence.' This gives clear context for when to apply the tool, though it does not explicitly name alternatives or state when not to use it. The mention of 'available records' implies current lookup versus historical, but a direct sibling reference would strengthen this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fonteum_lookup_contractor_historyALook up a US federal contractor record as of a requested date using UEI or CAGE. Retained history is currently limited to USASpending award rows; other fields may be current, absent, or nullable. Returns dated source context. Use for historical award research or contractor change questions.
| Name | Required | Description | Default |
|---|---|---|---|
| uei | No | 12-char GSA Unique Entity ID. Provide this OR `cage`. | |
| cage | No | 5-char CAGE / NCAGE code; resolved to the entity's UEI. Provide this OR `uei`. | |
| as_of | Yes | Requested date as YYYY-MM-DD. Production history is source-specific and currently retained for USASpending award rows; this does not reconstruct every procurement block. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses important behavioral details: the retained history scope (USASpending award rows only), the potential for fields to be 'current, absent, or nullable', and that it 'Returns dated source context.' This gives the agent a clear picture of data reliability and what to expect, which is especially valuable for a historical lookup tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, followed by a concise caveat about data limitations and an explicit use-case sentence. Every sentence adds value and there is no fluff.
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 three parameters, one required, no output schema, and only a read-only annotation, the description adequately covers what the tool does, its limitations, and when to use it. The phrase 'Returns dated source context' hints at the output structure but does not elaborate on the response format, which is a minor gap for an agent invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for all three parameters. The description adds clarity on the OR relationship between 'uei' and 'cage' (though schema implies it, the description states 'using UEI or CAGE' and later 'Provide this OR `cage`' in the schema). It also contextualizes 'as_of' by linking it to the retention limitation, which goes beyond the schema text.
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 identifies the action ('Look up'), the resource ('US federal contractor record'), the temporal scope ('as of a requested date'), and the lookup keys ('UEI or CAGE'). The 'historical' framing and the explicit statement about USASpending award rows distinguish it from the sibling tool 'fonteum_lookup_contractor', which likely serves current 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 states when to use the tool: 'Use for historical award research or contractor change questions.' It also warns about a key limitation ('currently limited to USASpending award rows'), which helps set expectations. However, it does not explicitly name the alternative tool for current lookups or state when not to use it, though the presence of 'fonteum_lookup_contractor' implies the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fonteum_lookup_npiALook up a US healthcare provider by 10-digit NPI in CMS NPPES and return the available provider record plus exclusion and program-integrity context. Returns dated source context; source_file and snapshot_digest are nullable when no single retained snapshot represents the response. Use for NPI lookup, provider identity, taxonomy, practice-location, or provider due-diligence questions.
| Name | Required | Description | Default |
|---|---|---|---|
| npi | Yes | The healthcare provider's 10-digit National Provider Identifier (NPI). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description is consistent with that. Beyond annotations, it adds behavioral details about the return format: 'Returns dated source context; source_file and snapshot_digest are nullable when no single retained snapshot represents the response.' This informs agents about optional fields and source-dependent behavior.
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 three concise sentences: purpose, return detail, and usage guidance. It is front-loaded with the primary function and every sentence adds value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description appropriately explains what is returned (provider record, exclusion/integrity context, dated source context, nullable fields). It covers the key aspects of the tool given its relatively simple parameter schema, though it could elaborate on the structure of the exclusion 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 coverage is 100% and the parameter description in the schema already clearly defines 'npi' as the 10-digit NPI. The tool description repeats this info but adds no new semantic details (e.g., format constraints, alternative identifiers). 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 clearly states the tool looks up a US healthcare provider by 10-digit NPI in CMS NPPES and returns provider record plus exclusion and program-integrity context. It distinguishes itself from siblings like search_providers (search by criteria) and check_exclusion (exclusion-specific) by specifying the NPI-based lookup and combined context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: 'Use for NPI lookup, provider identity, taxonomy, practice-location, or provider due-diligence questions.' It gives clear context for when this tool is appropriate, but does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fonteum_recheck_snapshotARecheck a Fonteum snapshot by snapshot id and return its as_of_date, snapshot_digest, public verifiable_url, and source_file only when explicit retained-artifact metadata is available. Without an id, returns chain status without treating the chain head as a snapshot digest. Use for snapshot integrity checks, citation support, or reproducing a retained source file.
| Name | Required | Description | Default |
|---|---|---|---|
| snapshot_id | No | Optional snapshot id. When given, returns the identified snapshot object's content commitment, hash version, nullable source metadata, separately scoped witness evidence when it validates, and the deep /verify/{id} link. Omit for the live attestation-chain head. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses important conditional behavior: fields are returned only when retained-artifact metadata exists, and omitting an id yields chain status rather than treating the head as a snapshot digest. It also mentions separately scoped witness evidence and validation, adding meaningful 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 compact and information-dense: the first sentence states the action and conditional return fields, the second clarifies the no-id behavior, and the third gives use cases. Every sentence contributes meaningful guidance 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 that the tool has only one optional parameter, no output schema, and a read-only annotation, the description thoroughly covers conditional outputs, the no-id edge case, and appropriate use cases. It leaves no obvious gap for an agent to select and invoke 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?
Schema coverage is 100%, and the snapshot_id parameter's own description already explains the difference between providing and omitting the id. The tool description restates this behavior but does not add new syntax, formatting, or parameter-specific nuance beyond what the schema provides, so it meets the baseline but does not exceed it.
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 a specific verb ('Recheck') and names the resource (Fonteum snapshot), then lists the returned fields and use cases. It clearly differentiates from sibling tools by focusing on snapshot integrity, citation, and source-file reproduction rather than provider/sanction lookups or dataset info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases ('snapshot integrity checks, citation support, or reproducing a retained source file') and explains the behavior without an id (chain status, not a digest). It lacks explicit exclusionary guidance about alternatives, but the sibling tools are semantically distinct enough that this is not a major gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fonteum_search_providersASearch US healthcare providers in loaded CMS NPPES specialty caches by vertical and state, with optional county context. Returns dated source context and up to 100 records; source_file and snapshot_digest may be null. Use for provider discovery by specialty and geography.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max records to return (default 25, max 100). | |
| state | Yes | 2-letter USPS state code (e.g. 'CA', 'TX'). | |
| county | No | Optional county filter (preserved on the result; NPPES does not publish county-of-practice). | |
| vertical | Yes | Healthcare vertical slug. One of: chiropractors, dermatologists, plastic-surgeons. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only behavior, and the description adds context about the data source (loaded caches) and output behavior (up to 100 records, source_file and snapshot_digest may be null). This goes beyond the annotation without contradicting it.
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: the first states purpose and scope, the second adds output details and usage guidance. Every clause is informative, with no redundancy or waste.
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 absence of an output schema, the description provides a high-level return summary (dated source context, up to 100 records) and notes nullability of specific fields. It is sufficiently complete for a read-only search tool, though it does not enumerate all result fields or error conditions.
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's parameter-related statements ('by vertical and state', 'optional county') largely mirror the schema and add no new meaning beyond emphasizing the primary filtering dimensions.
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 searches US healthcare providers in loaded CMS NPPES specialty caches by vertical and state, with optional county. This specifies the action (search), resource (providers), and scope, and is distinct from sibling tools like lookup_npi or search_sanctions.
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 says 'Use for provider discovery by specialty and geography,' providing clear when-to-use guidance. It also implies reliance on loaded caches, which is a contextual prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fonteum_search_sanctionsASearch a person or organization name across available sanctions and watchlist data from OFAC, the EU, the UK, and the UN, plus named exclusion sources held by Fonteum. Returns dated matches with source context; source_file and snapshot_digest may be null for the multi-source result. Use for sanctions screening, entity due diligence, or any ‘is this entity sanctioned?’ question.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Person or organization name to search across available OFAC, EU, UK, UN, and named exclusion sources. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses return behavior: 'Returns dated matches with source context; source_file and snapshot_digest may be null for the multi-source result.' This adds meaningful expectations about the output format and potential null fields, which is valuable for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a distinct purpose: what it does, what it returns, and when to use it. No fluff, front-loaded with the action, and appropriately concise.
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 single-parameter search tool with no output schema, the description fully covers the purpose, usage scenarios, and return behavior. It provides enough context for an agent to decide when and how to invoke the tool without needing supplemental documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already thoroughly describes the only parameter ('name') with the same source context. The description adds no additional parameter-level detail, so the schema coverage baseline of 3 applies.
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 a specific verb ('Search') and clearly identifies the resource (sanctions and watchlist data) with explicit sources (OFAC, EU, UK, UN, plus Fonteum named exclusions). It goes beyond a generic phrase and is well-positioned to be distinguished from siblings, even though it doesn't explicitly compare to them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use for sanctions screening, entity due diligence, or any “is this entity sanctioned?” question.' This provides clear context, but it doesn't mention when not to use it or offer alternatives, so it falls short of a 5.
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!
