Free US data lookups: ZIP demographics, CISA KEV/EPSS CVEs, domain rank, county spending, recalls.
Scored across 7 tools
Each tool targets a distinct data source and action: pairings like latest_kev (list) vs cve_kev_lookup (specific lookup) and latest_recalls (list) vs vehicle_recall (specific lookup) are clearly separated by description. No two tools appear to do the same thing.
Naming is readable but inconsistent: latest_kev/latest_recalls use an adjective prefix for list operations, cve_kev_lookup/vehicle_recall/zip_lookup vary between explicit 'lookup' and bare nouns, and domain_rank/county_federal_spending are descriptive noun phrases. No single verb_noun pattern is sustained.
Seven tools is a well-scoped size for a multi-domain data server. Each tool covers a distinct data source without redundancy, and the count is neither sparse nor overwhelming.
For each major domain, the set provides both a list/feed operation and a detail lookup (KEV and recalls), which avoids dead ends. Minor gaps exist—e.g., no ranking/list for county spending or domain ranks—but these are not essential to the apparent purpose of providing targeted lookups and recent updates.
FY2025 federal prime contract and grant obligations in a US county (USAspending.gov, place of performance): dollars, per-resident values, population and the county's contract rank in its state.
| Name | Required | Description | Default |
|---|---|---|---|
| county_fips | Yes | 5-digit county FIPS code, e.g. "51059" (Fairfax County, VA) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that the tool is read-only and idempotent. The description adds useful context beyond those hints by naming the data source (USAspending.gov), the geographic basis (place of performance), and the exact return content: dollars, per-resident values, population, and state contract rank. It does not discuss error cases or response formatting, but for this read-only single-parameter lookup the disclosure is strong.
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 a single, well-structured sentence with no filler. It front-loads the year and subject, then efficiently enumerates the returned metrics without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one schema-covered parameter and read-only annotations, the description is largely complete for an agent deciding whether to call it. It even compensates for the missing output schema by summarizing what the result contains. Minor ambiguities remain, such as the exact ordering or basis of the 'rank' value, but nothing critical 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?
The input schema fully describes the single parameter county_fips, including its 5-digit pattern and a concrete example. The description adds no parameter-specific semantics beyond the general 'US county' context, so the schema carries the burden and the baseline applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as reporting FY2025 federal prime contract and grant obligations for a US county, and it names the exact metrics returned. It lacks an explicit verb like 'returns' or 'lists', and it does not contrast itself with siblings, so it stops short of 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?
The description implies when to use the tool: when the agent needs FY2025 federal spending data for a US county. However, it provides no explicit when-to-use or when-not-to-use guidance and does not mention any alternative tools or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a CVE is in CISA's Known Exploited Vulnerabilities (KEV) catalog; if so return vendor, product, date added, federal due date, known ransomware use, EPSS probability/percentile, CVSS score/severity/vector, CWE and required action.
| Name | Required | Description | Default |
|---|---|---|---|
| cve_id | Yes | CVE identifier, e.g. "CVE-2021-44228" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses conditional behavior: enriched details are returned only if the CVE is in the KEV catalog. It also lists the returned fields, which is valuable because no output schema exists, while the annotations already cover read-only and idempotent safety. The negative-case response is not explicitly specified, but this is a minor gap for a simple read-only lookup.
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 a single dense sentence with no filler, tautology, or repetition of the input schema. The action and resource are front-loaded, and every listed return field earns its place by informing the agent of the output shape.
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-only lookup with no output schema, the description covers the tool's purpose and the full set of returned fields. It is sufficient for selection and invocation, though it could be more complete with an explicit not-found response description and a pointer to the latest_kev sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already provides the parameter name, type, pattern, and an example. The description adds no additional parameter-level meaning beyond identifying the tool as CVE-focused, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb ('Check whether') and a specific resource ('CISA's Known Exploited Vulnerabilities (KEV) catalog'), and the per-CVE scope is clear from both the tool name and input schema. It is easily distinguished from siblings like latest_kev, which imply a bulk or latest-entry listing, even though that sibling is not named.
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 intended usage is implied: use this when you have a CVE identifier and need to know whether it is in the KEV catalog. However, the description gives no explicit when-to-use guidance, no exclusions, and does not mention alternatives such as latest_kev for browsing recent KEV entries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Link-graph rank of a popular website (top 5,000): Common Crawl harmonic-centrality and PageRank rank, hosts crawled, previous-crawl rank, Majestic Million rank and referring subnets. For any other domain use Linkheft on Apify (apify.com/cybermax/domain-authority).
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Registrable domain, e.g. "github.com" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so no contradiction. The description adds value by disclosing the tool's limited scope (only top 5,000 domains) and the type of data returned (previous-crawl rank, referring subnets), which is not evident from annotations alone. However, it does not detail data freshness or availability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet dense, front-loading the core purpose and scope, then efficiently listing metrics and the alternative. Every sentence adds essential information 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 single-parameter read-only tool with 100% schema coverage and no output schema, the description is quite complete. It clearly defines scope, domain eligibility, and provides an alternative for out-of-scope cases. Minor gap: no mention of output format or potential errors, but this is low risk.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully describes the 'domain' parameter. The description adds semantic richness by specifying what constitutes a valid domain (registrable domain) in the schema and hinting at expected usage (popular websites). This elevates it slightly above baseline.
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 computes link-graph rank for popular websites (top 5,000), listing the specific metrics (harmonic-centrality, PageRank, Majestic Million rank) and explicitly excluding other domains. It distinguishes itself from siblings by specifying a niche scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (popular websites within top 5,000) and when not to (for other domains), directing the agent to an alternative: 'For any other domain use Linkheft on Apify.' This provides clear routing and prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the CVEs most recently added to CISA's Known Exploited Vulnerabilities catalog, newest first, with EPSS, CVSS and due date in the summary.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many items (1-50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds useful behavioral context beyond that: results are sorted newest first and the summary includes EPSS, CVSS, and due date. It does not discuss pagination or rate limits, but those are less critical for this simple read-only feed.
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?
A single sentence that front-loads the action and resource, then packs ordering and key result fields without wasted words. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter, no output schema, and read-only/idempotent annotations, the description is complete: it names the data source, ordering, and summary fields. Nothing essential is missing for an agent to select and invoke it 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 only parameter, limit, is fully documented in the schema with type, default, range, and description, so schema coverage is 100%. The tool description does not add parameter-specific semantics, but it also does not need to; the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a precise resource ('CVEs most recently added to CISA's Known Exploited Vulnerabilities catalog') and states ordering ('newest first') and included fields. This clearly distinguishes it from siblings like cve_kev_lookup, which implies lookup by a specific CVE rather than a feed.
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 intended use is implied by 'most recently added' and 'newest first': an agent can infer to use this when the user wants recent KEV entries. However, the description does not explicitly state when not to use it or name alternatives such as cve_kev_lookup for specific CVE lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the newest US vehicle and equipment recalls from NHTSA, newest first, with risk and remedy.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many items (1-50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds useful behavioral context beyond that: results are sorted newest-first, only US NHTSA recalls/equipment are included, and each item includes risk and remedy information. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence packs in the resource, scope, source, ordering, and output contents. There is no filler, and the most important information is front-loaded. The description earns its place and nothing more is needed.
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 read-only list tool with one optional parameter and no output schema, the description is sufficient: it explains the domain, ordering, and key output fields. It does not enumerate all possible response fields, but the stated 'risk and remedy' coverage is likely adequate for an agent to interpret 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?
The only parameter, 'limit', is fully documented in the input schema with type, default, min, max, and a description. The tool description adds no additional parameter semantics, but with 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('List'), a precise resource ('newest US vehicle and equipment recalls from NHTSA'), and the output characteristics ('newest first, with risk and remedy'). It clearly distinguishes this list tool from the singular lookup tool 'vehicle_recall' and from unrelated siblings like 'latest_kev'.
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 phrasing clearly signals when to use this tool: when the agent needs a list of the most recent NHTSA recalls rather than a specific recall lookup. It does not explicitly name alternatives or exclusions, but the context is clear enough for selection among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up an NHTSA vehicle/equipment recall campaign from the last 12 months: manufacturer, component, units affected, do-not-drive and park-outside flags, summary, risk, remedy and affected make/model/year list.
| Name | Required | Description | Default |
|---|---|---|---|
| campaign | Yes | NHTSA campaign number, e.g. "26V601000" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds a relevant recency constraint and enumerates returned fields, but it does not disclose behavior for missing or out-of-window campaigns or any response envelope details.
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 with no filler; every clause carries information. The long list of fields after the colon is dense, but still scannable, making this concise rather than 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-only lookup with annotations and full schema coverage, the description covers the important output content. It is ambiguous about what happens for campaigns older than 12 months, and there is no output schema, but the returned-field list makes the tool usable.
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 single parameter is fully documented in the schema with a format pattern and example, so the description does not need to repeat it. It adds no further semantics beyond that 100% 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 names the exact action ('Look up an NHTSA vehicle/equipment recall campaign') and enumerates the return fields, so an agent can tell this is a targeted, single-campaign lookup rather than a feed. It does not explicitly contrast with sibling latest_recalls, but the singular 'campaign' and the schema's required campaign ID make the resource clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context: use when you have a specific recall campaign and want its details, including a recency window of the last 12 months. It doesn't name alternatives or state when not to use it, so it falls just short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a US ZIP code: city, state, county, coordinates, time zone and Census ACS 2020-2024 demographics (population, median age, household and per-capita income, median home value, median gross rent, housing units, owner-occupied share).
| Name | Required | Description | Default |
|---|---|---|---|
| zip_code | Yes | 5-digit US ZIP code, e.g. "10001" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint and idempotentHint, so the description correctly does not need to restate that this is a safe, side-effect-free lookup. It adds useful context by naming the Census ACS 2020-2024 data source and enumerating the returned data, which helps an agent understand freshness and scope.
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 a single sentence that front-loads the lookup action and then provides a compact list of returned data. Every clause adds meaning, and there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only lookup, the description plus the schema provide the input format and a thorough list of returned fields. It does not specify behavior for nonexistent ZIP codes, but that is a minor omission given how simple and well-scoped the tool is.
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 covers the only parameter, zip_code, at 100% with a pattern and example. The description therefore does not need to add parameter-level guidance; it appropriately focuses on the output fields instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource, 'Look up a US ZIP code,' and lists the exact output categories: city, state, county, coordinates, time zone, and Census ACS 2020-2024 demographics. This clearly defines what the tool does and makes it easy to distinguish from unrelated siblings such as cve_kev_lookup or domain_rank.
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?
Usage is implied rather than explicitly stated: the description makes clear this is for retrieving US ZIP code information, but it does not explicitly discuss when to prefer it over an alternative or when not to use it. Sibling tools are mostly unrelated, so the lack of explicit routing is a moderate gap rather than a serious one.
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.
county_federal_spendingcve_kev_lookupdomain_ranklatest_kevlatest_recallsvehicle_recallzip_lookupFree US data lookups: ZIP demographics, CISA KEV/EPSS CVEs, domain rank, county spending, recalls.
Ziplore: US ZIP to county, FIPS, time zone, Census demographics; radius and city ZIPs. Free, no key.
Ziplore: US ZIP to county, FIPS, time zone, Census demographics; radius and city ZIPs. Free, no key.
Postal lookups for 120 countries with cited sources; deep US tier: demographics, climate, area codes
Add one secure layer between your agents and this server.