pubrecords
Server Details
US public-records intelligence for AI agents — companies, SEC, courts, spending, licenses.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- bch1212/mcp-pubrecords
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 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.
Available Tools
10 toolsmcp_get_company_detailsAInspect
Fetch 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the data fetched (officers, agent, filing history) but does not disclose behavioral traits like read-only nature, authentication needs, or rate limits.
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 (one sentence plus two param descriptions) with no wasted words. It is front-loaded with the main 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?
Given two required params, no output schema, and no annotations, the description adequately explains what data is returned. However, it lacks details on return format, pagination, or any behavioral constraints, leaving some 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?
Schema coverage is 0%, but the description explains company_id as 'OpenCorporates company number' and jurisdiction with an example format ('us_de', 'us_ca'). This adds significant meaning beyond the 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?
Description clearly states it fetches officers, agent, and filing history for a known company. The verb 'fetch' and resource 'company details' are specific, and the tool is distinct from siblings like mcp_get_sec_filing or 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 implies usage when you have a known company_id and jurisdiction, but does not explicitly state when to use or not use this tool compared to alternatives. No exclusions or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mcp_get_sec_filingAInspect
Fetch 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It says 'Fetch,' implying a read operation, but it does not disclose permissions, rate limits, or side effects. The lack of explicit read-only or safety cues reduces 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 concise with two sentences plus a parameter description. It is well-structured and front-loaded with the core purpose. The 'Args' section is redundant but not harmful.
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 simplicity (one required parameter, no output schema, straightforward purpose), the description is largely complete. It specifies the input format and output components (metadata + index URL), though it could elaborate on what 'metadata' includes.
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?
Only one parameter exists, and the description provides an example of the accession number format ('0001193125-21-000001'), which adds meaning beyond the schema's basic string type. The schema coverage is 0%, so the description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch metadata + index URL for one SEC filing by accession number,' specifying the verb, resource, and input. This distinguishes it from sibling tools like 'mcp_search_sec_filings' which would be used for searching without a specific accession number.
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 an accession number is available, but does not explicitly state when to use this tool versus alternatives like the search tool. No usage exclusions or preconditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mcp_get_ucc_filingsCInspect
UCC 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states that the tool is on the roadmap and returns 'not_implemented per state', which discloses a key behavioral limitation. However, no other behavioral details (e.g., error handling, permission needs) are provided.
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 the beginning 'UCC lien lookup' efficiently states the purpose. However, the contradictory roadmap note adds unnecessary confusion, making it less 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 2-parameter tool with no output schema, the description lacks details about return values, error cases, or state support. The roadmap note suggests it might be a stub, but completeness is still poor.
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's docstring adds minimal meaning to the two parameters: 'Name of the debtor' for debtor_name and '2-letter state code' for state. This is better than nothing but still basic.
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 indicates the verb and resource, but the parenthetical '(Roadmap; returns not_implemented per state)' contradicts this by suggesting the tool is not functional. This ambiguity reduces clarity.
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 siblings. Sibling tools like mcp_search_companies and mcp_search_licenses could overlap, but no differentiation or context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mcp_lookup_federal_spendingAInspect
Search 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose whether the operation is read-only, any authentication needs, rate limits, or side effects. This is a significant gap.
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 very concise: a single purpose sentence plus a simple list of parameters. Every sentence adds value 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?
No output schema, but description does not mention what results contain (e.g., award IDs, amounts). It covers parameters adequately but leaves return format unspecified. Acceptable for a simple search tool 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?
Schema description coverage is 0%, but description adds meaning for each parameter: recipient_name, agency (with example), year (with example), and limit (range 1-100, default 25). This compensates well for missing 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?
Description clearly states 'Search USASpending.gov for awards (contracts + grants)', specifying the resource and verb. This 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?
No guidance on when to use this tool versus alternatives. There is no explanation of when to search USASpending vs. other search tools, leaving the agent without decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mcp_lookup_npiAInspect
Look 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description implies read-only operation but lacks details on data source behavior, rate limits, or empty result handling.
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 minimal and well-structured, listing parameters in a clear Arg-style format without any extraneous 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?
For a tool with 4 optional parameters, no output schema, and no annotations, the description adequately covers purpose and parameter hints, though could mention search behavior details.
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?
Parameters are briefly described with helpful context (e.g., 'Taxonomy description' for specialty, '2-letter state code' for state), compensating for 0% schema 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?
Description clearly states the tool looks up healthcare providers in the NPPES NPI registry, distinguishing 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 guidance on when to use this tool vs alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mcp_search_companiesAInspect
Search 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it's a search (read operation) but lacks details on limitations, pagination, rate limits, or return format. The behavioral traits are basic and standard for a search 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 concise: one purpose line and four parameter lines. No extraneous text. Front-loaded with the action. Each sentence 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 no output schema and only simple parameters, the description covers the essentials: what it does, required parameter, optional filters. It lacks guidance on return structure or error cases, but is sufficient for a basic search 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%, meaning descriptions are essential. The description adds brief but clear explanations for each parameter (e.g., '2-letter US state code', 'Max results (1-100, default 25)'). This adds value beyond the schema's type/title definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search US business entities by name (OpenCorporates)', which is a specific verb+resource. It distinguishes from siblings like mcp_get_company_details (for details) and other search tools by narrowing to US business entities.
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 searching by name, but provides no explicit when-to-use, when-not-to-use, or alternatives. Among siblings, e.g., mcp_get_company_details exists for details after search, but this is not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mcp_search_court_casesAInspect
Search 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It does not mention rate limits, authentication requirements, or whether the search is read-only. The description only states the data source and parameters, lacking transparency about operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: a concise one-line purpose followed by a clean parameter list with each entry on its own line. No extraneous information, every sentence adds value. Ideal length for quick scanning.
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 output schema and annotations, the description provides parameter explanations but lacks context about return format, pagination, error handling, or result limits. It covers the bare necessities for a simple search but leaves uncertainties about what the agent will receive.
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 0% description coverage, so the description compensates by listing each parameter with a brief explanation (e.g., 'party_name: Plaintiff or defendant name'). This adds meaning beyond the schema's bare titles, though some details (e.g., court ID format) are missing.
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 'Search federal court cases via CourtListener (RECAP),' specifying the action (search), resource (federal court cases), and data source. This distinctly separates it from sibling tools like mcp_search_companies or mcp_search_sec_filings, which search different domains.
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 is given on when to use this tool versus alternatives. The parameter list implies usage context (e.g., needing a party name), but there is no mention of when not to use it or comparisons to other search tools. The description is purely functional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mcp_search_licensesAInspect
Search 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavioral traits. It describes the search scope but lacks details like rate limits, authorization needs, pagination, or what happens on no results. The behavior is partially transparent but incomplete.
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 docstring format, but it could be more structured (e.g., separating purpose and args). It front-loads the main purpose, but the Args section could be formatted better.
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 3 parameters and no output schema, the description adequately explains inputs but does not describe what the tool returns (e.g., list of matching licenses, result count). This gap reduces completeness for a search 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 description explicitly defines the license_type parameter with allowed values ('npi', 'medical', 'fcc', 'radio', 'all') and state as a 2-letter code. Since schema coverage is 0%, this fully compensates and adds meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches professional/business licenses, lists specific license types (NPI, FCC, etc.), and mentions a roadmap for more sources. The verb 'search' and resource 'licenses' are specific, and it distinguishes from siblings like mcp_lookup_npi.
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 for searching licenses but provides no guidance on when to use this tool versus siblings like mcp_lookup_npi or mcp_verify_entity. No explicit when-not or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mcp_search_sec_filingsAInspect
Search 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not explicitly state that the tool is read-only or disclose any behavioral traits such as rate limits, authentication requirements, or side effects. The parameter constraints (limit 1-100) provide some transparency, but it's minimal.
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 first sentence and a structured list of arguments. No redundant information, and it is appropriately sized.
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 output schema, the description explains the purpose and parameters adequately but does not describe the return format or structure. For a search tool, details on what the response contains (e.g., filing URLs, metadata) would enhance completeness.
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%, so the description adds significant value by explaining each parameter (e.g., date_from format YYYY-MM-DD, limit range 1-100, company_name as issuer name). However, form_type lacks enumeration of possible values beyond examples.
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 'Search SEC EDGAR full-text for filings' with specific verb and resource. It distinguishes from siblings like mcp_get_sec_filing (retrieve a specific filing) and mcp_search_companies (search for 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 implies usage through parameter listing but lacks explicit when-to-use or when-not-to-use guidance. It does not contrast with siblings like mcp_get_sec_filing for retrieving a specific filing versus searching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mcp_verify_entityCInspect
Cross-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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It mentions cross-referencing sources and confidence scoring but omits details like which sources are consulted, expected latency, or any side effects.
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 purpose statement followed by parameter explanations. No superfluous content.
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 likely returns complex confidence data, but the description neither specifies output format nor provides examples. Without an output schema, this leaves the agent uncertain about what to expect.
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 the parameters by explaining 'state' as jurisdiction filtering. With 0% schema description coverage, this is helpful but not extensive; the meaning of 'name' is obvious.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's main action: cross-referencing an entity across multiple sources and scoring confidence. This distinguishes it from sibling tools that retrieve specific details or search 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?
No guidance on when to use this tool versus siblings like mcp_search_companies or mcp_get_company_details. The description implies a verification use case but does not explicitly state when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!