US public-records intelligence for AI agents — companies, SEC, courts, spending, licenses.
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 3.5/5 across 10 of 10 tools scored. Lowest: 2.7/5.
Each tool targets a distinct public records source (company, SEC, UCC, spending, NPI, courts, licenses) with clear differentiation between search and retrieval operations. Minimal overlap and no ambiguity.
All tools follow a consistent 'mcp_verb_noun' pattern using get, lookup, search, and verify. No mixed conventions or irregular naming.
10 tools cover a broad range of public records domains without being overwhelming. Each tool earns its place by targeting a specific source or operation.
The set covers many common public records, but mcp_get_ucc_filings is a roadmap stub returning not_implemented, which is a significant functional gap. Missing sources like property or criminal records are expected, but the non-functional tool hurts completeness.
mcp_get_company_detailsAInspectFetch officers, agent, and filing history for a known company.
Args: company_id: OpenCorporates company number. jurisdiction: Jurisdiction code (e.g. 'us_de', 'us_ca').
| Name | Required | Description | Default |
|---|---|---|---|
| company_id | Yes | ||
| jurisdiction | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not mention read-only nature, side effects, rate limits, or permissions. It only lists what data is returned, lacking behavioral details beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise with two sentences plus parameter explanations, no redundant information, and purpose front-loaded.
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 two-parameter tool with no output schema, the description adequately explains what it does and expects. Lacks output structure info but given low complexity, it is largely 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?
With 0% schema description coverage, description explains both parameters (company_id as OpenCorporates number, jurisdiction as code format), adding essential meaning beyond the schema's empty titles.
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 'Fetch officers, agent, and filing history for a known company', specifying verb and resource. It implicitly distinguishes from sibling search tools (e.g., search_companies) and specific filing tools (e.g., get_sec_filing, get_ucc_filings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage when company_id and jurisdiction are known, but does not explicitly state when to use or not use compared to siblings like search_companies or verify_entity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mcp_get_sec_filingAInspectFetch metadata + index URL for one SEC filing by accession number.
Args: accession_number: EDGAR accession number (e.g. '0001193125-21-000001').
| Name | Required | Description | Default |
|---|---|---|---|
| accession_number | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states it fetches metadata and index URL, omitting any permissions, side effects, or rate limits. Minimal disclosure leaves agent uncertain about safety.
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 plus Args block. Front-loaded with main purpose. Minor verbosity in structured Args format but overall efficient.
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?
Explains fetched data (metadata and index URL) and required parameter. Lacks response structure details, but acceptable given no output schema and simple 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?
Schema coverage is 0%, but description adds example format for accession number (e.g., '0001193125-21-000001'). Provides meaningful guidance beyond bare schema parameter name.
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 specifies verb ('fetch'), resource ('SEC filing'), and key parameter ('accession number'). Distinguishes from sibling 'mcp_search_sec_filings' which searches, while this fetches a specific filing.
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?
Implies usage when accession number is known, but no explicit when-to-use or when-not-to-use compared to siblings like 'mcp_search_sec_filings'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mcp_get_ucc_filingsBInspectUCC lien lookup. (Roadmap; returns not_implemented per state.)
Args: debtor_name: Name of the debtor. state: 2-letter state code.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | ||
| debtor_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool is on a roadmap and returns 'not_implemented per state', which is a key behavioral trait. However, with no annotations provided, the description should also mention other behaviors like authentication requirements or data freshness, which are absent.
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 very short and to the point, with no wasted words. The key information (purpose, roadmap status) is front-loaded. The parameter list follows. It earns its place, but could be slightly more structured with separate sections.
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 no output schema and the description fails to explain what the agent should expect in the response (even a 'not_implemented' message), it lacks completeness. An agent would not know how to handle the result or whether to retry. Additional context about the roadmap status and potential alternatives is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description adds basic meaning by naming the two parameters and providing brief explanations ('Name of the debtor', '2-letter state code'). This is minimal but incremental over the schema which only has titles. More detail like format or examples would improve the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'UCC lien lookup' which clearly identifies the tool's purpose. It distinguishes from siblings like 'mcp_get_company_details' by specifying a different domain (UCC filings). However, the 'Roadmap; returns not_implemented per state' indicates it's not fully functional, slightly reducing clarity for an agent deciding whether to use it.
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?
No explicit guidance on when to use this tool versus alternatives like 'mcp_get_company_details' or 'mcp_search_companies'. The only hint is that it returns 'not_implemented', which implies it should not be used for actual lookups, but no alternative tool is suggested.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mcp_lookup_federal_spendingAInspectSearch USASpending.gov for awards (contracts + grants).
Args: recipient_name: Award recipient name. agency: Awarding agency name (e.g. 'Department of Defense'). year: Fiscal year (e.g. 2024). limit: Max results (1-100, default 25).
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | ||
| limit | No | ||
| agency | No | ||
| recipient_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states it searches and lists parameters but does not disclose behavioral traits such as data freshness, pagination, rate limits, authentication, or whether results are real-time or cached. This is minimal disclosure for a web API 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 extremely concise: one sentence for purpose followed by a clear list of parameters with brief explanations. Every sentence earns its place, and the structure is 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?
For a lookup tool with no annotations and no output schema, the description adequately covers parameters but lacks details on expected return values (e.g., list of awards with summary fields), source reliability, or edge cases. It is minimally viable but could be more 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?
The input schema has only type and title for each parameter, with no descriptions. The tool description adds meaningful explanations for all four parameters (e.g., 'recipient_name: Award recipient name'). This significantly improves clarity beyond the schema, despite the 0% coverage metric being misleading.
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 searches USASpending.gov for awards (contracts+grants). The verb 'Search' and resource 'awards' are specific and unambiguous. No sibling tool covers federal spending, so it is well-distinguished.
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 use when looking for federal grants or contracts, but lacks explicit guidance on when to use versus not use this tool, or any alternatives. With siblings mainly about companies and filings, usage context is reasonable though not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mcp_lookup_npiAInspectLook up healthcare providers in the NPPES NPI registry.
Args: name: Provider individual or organization name. specialty: Taxonomy description (e.g. 'Internal Medicine'). state: 2-letter state code. limit: Max results (1-200, default 25).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| limit | No | ||
| state | No | ||
| specialty | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral aspects. It states a read-only lookup, which is transparent, but does not disclose details like rate limits, data freshness, or authentication requirements.
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 front-loaded with the purpose and uses a compact, structured format (Args section). Every sentence is necessary and informative with no 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?
For a simple lookup tool with 4 parameters and no output schema, the description covers all inputs and the basic action. It could mention the return format (list of providers) but is otherwise sufficient.
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 0%, yet the description adds meaningful context: e.g., 'Provider individual or organization name', 'Taxonomy description', '2-letter state code', and 'Max results (1-200, default 25)'. This goes beyond schema titles.
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 ('look up') and resource ('NPPES NPI registry'), clearly differentiating it from sibling tools like mcp_search_companies or mcp_search_licenses.
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?
No explicit guidance on when or when not to use this tool versus alternatives. The description implies it's for NPI lookups, but does not exclude other registries or mention limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mcp_search_companiesAInspectSearch US business entities by name (OpenCorporates).
Args: name: Company or trade name to search for. state: 2-letter US state code (e.g. 'CA') to narrow jurisdiction. status: Filter by current status (e.g. 'active', 'dissolved'). limit: Max results (1-100, default 25).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| limit | No | ||
| state | No | ||
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides minimal behavioral context. It does not disclose rate limits, pagination, expected response format, error handling, or any side effects. The only behavioral information is that it searches via an external API.
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 very concise: one sentence for purpose followed by a clean list of parameters. Every line earns its place, and the structure is easy to scan.
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?
While the parameter explanations are complete, the description lacks context about the output format (no output schema provided), potential errors, and any caveats about using the OpenCorporates API. For a search tool, the return value is implied but not described.
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?
All four parameters are described with clear explanations and examples (state: 'CA', status: 'active'), adding significant value beyond the schema which has 0% description coverage. The limits parameter even specifies valid range and default.
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 searches US business entities by name, specifies the data source (OpenCorporates), and distinguishes it from sibling tools like mcp_get_company_details which retrieves details for a specific 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?
No explicit guidance on when to use this tool versus alternatives. Does not mention prerequisites, limitations, or typical use cases beyond the basic search functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mcp_search_court_casesAInspectSearch federal court cases via CourtListener (RECAP).
Args: party_name: Plaintiff or defendant name. court: CourtListener court id (e.g. 'nyed', 'txsd'). date_from: Earliest filing date (YYYY-MM-DD). limit: Max results (1-50, default 25).
| Name | Required | Description | Default |
|---|---|---|---|
| court | No | ||
| limit | No | ||
| date_from | No | ||
| party_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only lists parameters without mentioning read-only nature, rate limits, pagination, or result format. This is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear parameter list structure. Every sentence provides value, though it could be slightly more compact by integrating the purpose line with the parameter list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no output schema, and no annotations. The description covers parameter semantics but lacks behavioral context, error handling, or return value expectations. It is minimally adequate.
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 0%, but the description adds meaningful explanations for each parameter (e.g., 'CourtListener court id' for court, 'YYYY-MM-DD' format for date_from, and range '1-50' for limit). This compensates well for the schema gap.
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 searches federal court cases via CourtListener (RECAP). This is a specific verb-resource pair that distinguishes it from sibling tools like mcp_search_companies or mcp_search_licenses.
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 parameter hints but no explicit guidance on when to use this tool versus alternatives, or when not to use it. Usage is implied from the name, but no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mcp_search_licensesBInspectSearch professional / business licenses (NPI + FCC, more sources roadmap).
Args: entity_name: Licensee name. license_type: 'npi' | 'medical' | 'fcc' | 'radio' | 'all'. state: 2-letter state code.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | ||
| entity_name | Yes | ||
| license_type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the burden is on the description. It does not disclose potential behavioral aspects such as pagination, rate limits, or what happens when no results are found. The behavior is implied as a standard search, but details are lacking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the main purpose in the first sentence and a clear list of arguments. The phrase 'more sources roadmap' is somewhat vague but does not detract significantly.
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?
While the description covers parameters, it does not describe the output format, error behavior, or any side effects. For a search tool with no output schema, this information is important for an agent to handle results 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 description adds significant meaning beyond the schema by listing allowed values for license_type (e.g., 'npi', 'medical', 'fcc') and specifying state format as '2-letter state code'. Entity_name is described as 'Licensee name'. This compensates for the 0% schema description coverage.
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 professional/business licenses including NPI and FCC sources. It distinguishes from sibling tools that focus on companies, SEC filings, court cases, etc., but does not explicitly differentiate from mcp_lookup_npi which may overlap.
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?
No guidance is provided on when to use this tool versus alternatives such as mcp_lookup_npi or mcp_search_companies. The description merely lists parameters without context on typical use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mcp_search_sec_filingsAInspectSearch SEC EDGAR full-text for filings.
Args: company_name: Issuer name or keyword. form_type: Filing form (e.g. '10-K', '10-Q', '8-K'). date_from: Earliest filing date (YYYY-MM-DD). limit: Max results (1-100, default 25).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| date_from | No | ||
| form_type | No | ||
| company_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While 'Search' implies a read-only operation, there is no disclosure of side effects, authentication requirements, rate limits, or data freshness. The description is minimal and lacks behavioral context beyond the action itself.
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 extremely concise: one sentence plus a bullet-like argument list. It is front-loaded with the purpose and immediately followed by parameter details, with no redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for basic use but lacks information about the return format or what constitutes a result. Given the absence of an output schema, the agent cannot know if the tool returns filing metadata, URLs, or full text. Context is partially complete but has notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds value by providing concise semantics for each parameter (e.g., 'Issuer name or keyword' for company_name, format hint YYYY-MM-DD for date_from, range 1-100 for limit). This adequately compensates for the lack of schema descriptions, though some details could be more precise.
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 'Search SEC EDGAR full-text for filings,' clearly identifying the resource (SEC EDGAR) and action (search). The parameter list (company_name, form_type, date_from, limit) further clarifies scope, distinguishing it from sibling tools like mcp_get_sec_filing (retrieve specific filing) and mcp_search_companies.
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 no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. It only lists parameters, leaving the AI agent to infer usage context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mcp_verify_entityBInspectCross-reference an entity across multiple sources and score confidence.
Args: name: Entity name to verify. state: Optional 2-letter state code for jurisdiction filtering.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| state | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'cross-reference an entity across multiple sources and score confidence.' It does not disclose behavioral traits like rate limits, authentication needs, or whether it modifies data. Minimal transparency.
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 short but includes an Args block which is somewhat verbose for a tool description. Could be more concise by integrating parameter info into the main sentence.
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?
No output schema, and the description only mentions scoring confidence without specifying format or range. Given the complexity of verification, more detail on return values or behavior is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to both parameters beyond the schema: 'name' is 'Entity name to verify' and 'state' is 'Optional 2-letter state code for jurisdiction filtering.' Schema had no descriptions, so this is valuable.
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 cross-references an entity across multiple sources and scores confidence, using a specific verb and resource. This distinguishes it from sibling search tools like mcp_search_companies.
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?
No guidance on when to use this tool vs alternatives. The description does not mention when to choose verification over search tools like mcp_search_companies or mcp_search_licenses.
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.
