US public-records intelligence for AI agents — companies, SEC, courts, spending, licenses.
Scored across 10 tools
Most tools map to a clearly distinct source or action (get_company_details vs search_companies, get_sec_filing vs search_sec_filings, court/spending/NPI lookups). The main overlap is mcp_lookup_npi versus mcp_search_licenses with license_type='npi'|'medical', which both target provider licensing data and could confuse selection. verify_entity is distinct enough as a cross-source aggregator.
Names follow a predictable mcp_verb_noun pattern (get_*, lookup_*, search_*, verify_*), with verbs used coherently by intent (get=direct fetch, search=query, lookup=registry lookup). Minor deviations exist (lookup vs search split, get_ucc_filings uses plural where others are singular), but readability and consistency remain high.
Ten tools is well-scoped for a public-records aggregator spanning companies, SEC, courts, spending, providers, and licenses. Each tool earns its place by covering a distinct data source or cross-cutting operation (verify_entity).
The surface covers most major public-record sources, but mcp_get_ucc_filings is explicitly a roadmap stub returning not_implemented, creating a dead-end tool, and mcp_search_licenses is only partially realized. Detail/retrieval operations exist for companies and SEC filings but not for courts, spending, or licenses, leaving some workflows that dead-end after search.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses what data is returned, which is useful, but says nothing about authentication, rate limits, cost, or what happens when the company/jurisdiction is unknown or invalid.
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?
Front-loaded with the core purpose in one sentence, followed by a compact Args block. No filler, though the Args formatting is slightly redundant with the schema structure.
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 read-only lookup with no output schema or annotations, the description covers what is fetched and how to identify the company, but omits failure behavior and jurisdiction format constraints. Adequate but with visible 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 description coverage is 0% (only bare titles), so the description must compensate, and it does: it identifies company_id as the 'OpenCorporates company number' and jurisdiction as a code with concrete examples ('us_de', 'us_ca'). This adds real meaning 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?
States a specific verb ('Fetch') and enumerates the exact resources returned (officers, agent, filing history) for a company. The qualifier 'known company' implicitly separates it from sibling search tools like mcp_search_companies, though no sibling is named directly.
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?
'for a known company' hints that this is the lookup step after identification, implying mcp_search_companies would precede it. However, no alternative is named explicitly and no when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose the return shape (metadata plus an index URL) and implies a read-only fetch, but says nothing about failure behavior for an invalid accession, auth needs, or rate limits — modest for a simple read tool but a real 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?
The one-line purpose is front-loaded and wastes nothing, and the Args block is compact. The docstring-style formatting is slightly heavier than needed for a single parameter but not verbose.
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 one-parameter read tool with no output schema, telling the agent it returns metadata and an index URL is adequate. Error handling and the exact metadata fields are unstated, but nothing critical to invoking it correctly is missing.
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 must compensate for the single parameter — and it does, supplying the meaning and a concrete format example ('0001193125-21-000001'). That format hint is genuine added value beyond the schema's bare string type.
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?
States a specific verb ('Fetch') and deliverable ('metadata + index URL') for a single SEC filing identified by accession number. The 'one filing by accession number' scoping implicitly distinguishes it from the sibling mcp_search_sec_filings, though it never names that role contrast explicitly.
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 'by accession number' phrasing implies you must already have an EDGAR identifier rather than a company name, which is mild usage guidance. It does not state when to prefer this over mcp_search_sec_filings or what to do if you lack an accession number, leaving selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does the single most important thing: it discloses that the tool is unimplemented and returns not_implemented. It does not describe auth, rate limits, or result shape, but the key behavioral fact is stated plainly.
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 tight lines with the status caveat front-loaded right after the purpose, so an agent sees the stub warning immediately. Only the Args block, which merely mirrors the schema, is low-value 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 roadmap stub with two required params and no output schema, the description states enough: what it does, that it is unimplemented, and the parameter set. No return-value detail is needed given the not_implemented behavior is spelled out.
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% and both parameters are required, so the description must compensate. It names both parameters and adds one piece of real meaning ('2-letter state code' format), but gives no format or matching semantics for debtor_name. Minimal but non-zero value 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?
Names a specific resource (UCC lien filings) and the lookup action, which clearly separates it from siblings like mcp_search_court_cases and mcp_search_sec_filings. It is a noun phrase rather than a verb-led statement, but the intent is unambiguous.
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 parenthetical '(Roadmap; returns not_implemented per state.)' is an explicit when-not-to-use signal: the agent learns the tool is a stub and will yield no data. It does not point to an alternative tool for the same need, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it discloses only the data source and award types. It says nothing about authentication, rate limits, pagination, result ordering, or error behavior for a network search against a public 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?
Purpose sentence is front-loaded, followed by a tight Args list. No redundant filler, though the Args block mostly mirrors schema property names rather than adding much beyond the parentheticals.
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 search tool with no output schema and no annotations, the definition is adequate on inputs but silent on the return shape, pagination, and total-count behavior an agent would need to interpret results. Minimum viable rather than 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%, so the description must compensate, and it largely does: it documents all four parameters, clarifies that year is a fiscal year, supplies example values for agency and year, and adds a 1-100 range for limit that the schema omits. Only recipient_name lacks added detail.
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?
States a specific verb (Search) plus resource (USASpending.gov awards) and narrows scope to contracts + grants. It is clearly distinguishable from sibling tools like mcp_get_company_details or mcp_search_sec_filings by its federal-spending domain, though it never names or contrasts a sibling.
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 gives no when-to-use context, no prerequisites, and no routing advice relative to the many sibling search tools. An agent must infer that this is the right tool for federal awards purely from the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, yet it says nothing about authentication needs, rate limits, pagination behavior, or result format. It does implicitly signal a safe read operation, but that is the bare minimum for a 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?
Front-loaded with the tool's function, then a compact Args block. Efficient with no filler, though the inline parameter list is slightly more verbose than a prose form would be.
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 and no annotations, the description covers inputs adequately but omits what a caller gets back (fields, pagination, empty-result behavior). For a read tool of this complexity, that leaves a real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does: it documents all four parameters, including a taxonomy example for specialty, the 2-letter format for state, and the 1-200 range and default for limit.
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?
States a specific verb ('Look up') and resource ('healthcare providers in the NPPES NPI registry'), which is unambiguous and clearly distinct from corporate/filing siblings like mcp_search_companies or mcp_get_sec_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?
There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. Usage must be inferred entirely from the name and parameter list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden yet only discloses the source (OpenCorporates) and the limit bounds (1-100, default 25). It says nothing about result ordering, fuzzy vs exact matching, pagination, rate limits, or what happens when no match is found.
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?
One front-loaded sentence states the purpose and source, followed by a tight four-line Args block with zero filler. Given the schema has no property descriptions, the argument list is not redundant but necessary.
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 search tool with no output schema and no annotations, the definition is adequate on inputs but silent on outputs — no indication of returned fields, result-count metadata, or how to page beyond the limit. An agent can invoke it, but cannot anticipate the response shape.
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%, so the Args block does the entire job, and it does it well: each of the four parameters gets meaning, a format example ('CA', 'active'), and the limit's range and default. It stops short of edge-case behavior, but clearly compensates for the empty 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?
States a specific verb and resource ('Search US business entities by name') and names the data source (OpenCorporates). It implicitly distinguishes itself from siblings like get_company_details or verify_entity by being a name-based search, though it never explicitly contrasts with 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?
There is no explicit when-to-use or when-not-to-use guidance, and no alternative is named despite nine sibling tools including get_company_details and verify_entity that an agent could confuse with this one. Param hints ('narrow jurisdiction') are the only contextual signals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, yet it only says which service is queried. It does not disclose pagination behavior, whether an API token/auth is required for CourtListener, rate limits, what fields are returned, or whether this searches full text versus case metadata.
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 one-line purpose is front-loaded and the Args list is compact. Given the 0% schema coverage, enumerating the four parameters earns its place rather than being pure repetition of structured data.
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 four-parameter search with one required field, no output schema, and no annotations, the description covers inputs well but leaves the result shape, auth needs, and result-volume behavior unstated. It is the minimum viable level for this complexity.
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%, so the description must compensate, and it largely does: it explains party_name, gives concrete court id examples ('nyed', 'txsd'), specifies the date format (YYYY-MM-DD), and states the limit range and default (1-50, default 25). These are meaningful additions beyond the bare schema types.
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 first sentence states a specific verb and resource ('Search federal court cases') and names the data source (CourtListener/RECAP), which clearly separates it from the sibling tools that deal with companies, SEC filings, licenses, and NPI lookups. It stops short of explicitly naming those siblings, but the domain is unambiguous.
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?
There is no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The Args block only documents parameters, not selection conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden and falls short. It never states whether this is read-only, whether results are paginated or rate-limited, what a match returns, or how partial name matches behave — all material for an agent invoking a search.
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?
Front-loaded one-line purpose followed by a compact Args list; nothing is padded. The Args block partly repeats schema titles but earns its place through the license_type enum and state format.
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 and no annotations, the description should do more than enumerate inputs — it says nothing about result shape, coverage limits per source, or match semantics. Adequate for calling the tool correctly, incomplete for interpreting results.
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%, so the description has to compensate, and it mostly does: it defines entity_name as licensee name, gives the accepted license_type values ('npi' | 'medical' | 'fcc' | 'radio' | 'all') that appear nowhere in the schema, and specifies state as a 2-letter code. It omits defaults/nullability behavior.
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?
States a specific verb and resource — searching professional/business licenses — and hints at scope with the source list (NPI + FCC). It doesn't differentiate itself from the sibling mcp_lookup_npi, so an agent has no guidance on which license tool to pick.
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 when-to-use or when-not-to-use guidance, no prerequisites, and no mention of alternatives despite a crowded sibling set including mcp_lookup_npi and mcp_verify_entity. The parenthetical 'more sources roadmap' is informational, not routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
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 never mentions SEC EDGAR rate limits (a well-known constraint), authentication needs, pagination, or result ordering. Without annotations, a mutation-free search still needs more behavioral context than 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?
Front-loaded purpose sentence followed by a compact Args block; every line earns its place. The args-list formatting is boilerplate but not wasteful, and nothing is buried.
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 four-param search with no output schema and no annotations, the parameter documentation is adequate, but the description says nothing about the return shape, result ordering, or how results relate to the sibling filing-retrieval tool. Minimum viable but with clear 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%, so the description must document all parameters, and it does: company_name as issuer/keyword, form_type with concrete examples ('10-K', '10-Q', '8-K'), date_from format (YYYY-MM-DD), and limit range/ceilings (1-100, default 25). This meaningfully compensates for the empty schema descriptions, though it omits what company_name accepts beyond keyword.
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?
States a specific verb and resource: 'Search SEC EDGAR full-text for filings.' An agent understands this is a full-text search over SEC filings, distinguishing it from sibling retrieval tools like mcp_get_sec_filing. It stops short of explicitly naming which sibling to use instead, so it doesn't reach a 5.
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 versus mcp_get_sec_filing, mcp_search_companies, or the other lookup tools. There are no stated prerequisites or exclusions despite the description sitting next to nine siblings, several of which are also SEC/entity searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations and description lacks behavioral details. It mentions scoring confidence but doesn't explain what sources are checked, what the score means, rate limits, or output format. For a verification tool, these details are crucial.
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?
Short and front-loaded, with no unnecessary text. However, the 'Args:' block is somewhat redundant given the schema, but it's 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?
Given no annotations, no output schema, and 0% schema coverage, the description is incomplete. It doesn't explain what sources are cross-referenced, how confidence is scored, or what the output contains, making it inadequate for an agent to use effectively.
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 description must compensate. It briefly explains 'name' and 'state' parameters, but missing details like format constraints (e.g., state must be 2-letter code is given) and what 'jurisdiction filtering' means. The description adds some value but is minimal.
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?
States a verb (cross-reference) and resource (entity) but is vague about what 'cross-reference across multiple sources' entails. Does not differentiate from siblings like search_companies or lookup_npi, which also retrieve entity data.
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. With siblings like search_companies and lookup_npi, it's unclear whether this is a verification step after a search or a standalone lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
mcp_get_company_detailsmcp_get_sec_filingmcp_get_ucc_filingsmcp_lookup_federal_spendingmcp_lookup_npimcp_search_companiesmcp_search_court_casesmcp_search_licensesmcp_search_sec_filingsmcp_verify_entityPublic data intelligence for AI agents — CVE, compliance, patents, contracts, domains.
Private company data, entity-resolved news, targeted lists, and alternative signals for AI agents.
US public data for AI agents: recalls, gov contracts, IRS ZIP income, TX leads, WHOIS, tech stack
Keyless, read-only US public records for agents: SEC, FDA, enforcement, sanctions, market data.
Add one secure layer between your agents and this server.
