Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@whetstone-mcp search for Acme Corp in Delaware"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for U.S. public-records data — so AI agents and MCP clients (Claude Desktop, Cursor, etc.) can look up business records, screen names against government watchlists, and pull federal awards directly.
Powered by the Whetstone actors on Apify. All data is official U.S. government public-record data.
Tool | What it does |
| Official Secretary of State business registration (KYB) across 25 states |
| Newly registered businesses from 10 states, windowed by date |
| Screen a name against 12 federal watchlists (OFAC, BIS, State Dept) |
| A company's federal contracts, grants, and loans (USAspending.gov) |
Related MCP server: fedreg-mcp
You need a free Apify API token (apify.com → Settings → API & Integrations). Runs bill to your Apify account under pay-per-result pricing (~$2 per 1,000 result rows; the free tier covers light use).
Add to claude_desktop_config.json:
{
"mcpServers": {
"whetstone": {
"command": "npx",
"args": ["-y", "whetstone-mcp"],
"env": { "APIFY_TOKEN": "apify_api_your_token_here" }
}
}
}Restart Claude Desktop. The four tools then appear and the agent can call them.
Run the server over stdio:
APIFY_TOKEN=apify_api_... npx -y whetstone-mcpHeavy queries can be slow. Business search across all 25 states (or filings across all
runs synchronously and may approach the 300-second limit. Pass a states subset for
faster, cheaper runs.
Name-based matching. Watchlist and federal-award results are matched by name and are not identity confirmation — verify a hit against the official source before acting. Nothing here is legal, compliance, or financial advice.
A free, interactive version of the combined lookup is at whetstonetools.com/company-check, and there's also an n8n community node.
MIT © Whetstone Tools · support@whetstonetools.com
Look up a U.S. company's official Secretary of State business registration across 25 states (KYB). Returns registration records (status, dates, registered agent). Use the full or partial company name.
| Name | Required | Description | Default |
|---|---|---|---|
| states | No | Two-letter state codes to query (e.g. ["NY","TX"]). Omit for all 25 supported states. | |
| exactMatch | No | Only return exact name matches (case-insensitive). Default false. | |
| companyName | Yes | Business name (or part of it) to search for | |
| maxResultsPerState | No | Cap on records per state (1-200, default 25). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does well by disclosing the output: 'registration records (status, dates, registered agent)' and clarifying matching behavior. It does not cover potential rate limits, data freshness, or error conditions, but for a read-only search tool these are minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences pack the core purpose, scope, output, and name-matching behavior with no filler. The most important information is front-loaded, making it easy for an agent to scan and act on.
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 a well-defined schema, the description is reasonably complete: it covers purpose, scope, return content, and name matching. It lacks an output schema, so the explicit mention of returned fields helps, but it could still clarify state coverage details or absence-of-results behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all 4 parameters with descriptions, so the baseline is 3. The description adds only minor value beyond the schema by restating that full or partial names are accepted; it does not clarify states, exactMatch, or maxResultsPerState beyond what the schema already provides.
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 specifies a clear action ('Look up'), a precise resource ('U.S. company's official Secretary of State business registration'), and a bounded scope ('across 25 states (KYB)'). This differentiates it from sibling tools like new_business_filings and watchlist_screen, which clearly serve different purposes.
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 this tool (when you need official business registration records and status), but it does not explicitly state when not to use it or mention alternatives. It gives a useful hint with 'Use the full or partial company name,' but lacks direct routing among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a U.S. company's federal contracts, grants, and loans (USAspending.gov) with amounts, agencies, and dates. Useful for B2G sales intel and due diligence.
| Name | Required | Description | Default |
|---|---|---|---|
| awardTypes | No | Categories: contracts, grants, loans, direct_payments, idvs, other_financial_assistance. Omit for all. | |
| maxResults | No | Max total award records (1-500, default 50). | |
| recipientName | Yes | Company or organization name to search | |
| sinceFiscalYear | No | Earliest federal fiscal year (>=2008). Omit for default (5 years back). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the operation is a lookup (implying read-only), names the data source, and lists the returned fields. However, it does not mention data freshness, potential delays, match semantics, or output format beyond the field names, leaving some behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence front-loads the core action, resource, source, and data included; the second adds a relevant use case. Every word contributes to the agent's understanding.
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 low complexity (4 params, 1 required, no nested objects) and full schema coverage, the description is largely complete. It names the data source, what data is returned, and the intended use case. The absence of an output schema is mitigated by the mention of amounts, agencies, and dates, though it could be slightly clearer that the result is a list of award records.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal semantic value beyond the schema: it suggests recipientName refers to a U.S. company and highlights contracts/grants/loans, which partially overlaps with the awardTypes parameter values. It does not clarify maxResults or sinceFiscalYear beyond what the schema already provides.
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 starts with a specific verb ('Look up') and clearly identifies the resource ('U.S. company's federal contracts, grants, and loans') plus the data included (amounts, agencies, dates). It also names the authoritative source (USAspending.gov), making the tool easily distinguishable from sibling tools like business_search and watchlist_screen.
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 specifies a clear context: 'Useful for B2G sales intel and due diligence.' However, it does not provide explicit when-to-use or when-not-to-use guidance, nor does it reference alternative sibling tools for related use cases. The usage context is implied from the use-case sentence, but no exclusions or routing is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pull newly registered U.S. businesses from official state sources (10 states), windowed by date. Useful for sales-lead feeds and monitoring brand-new companies.
| Name | Required | Description | Default |
|---|---|---|---|
| states | No | Two-letter state codes (e.g. ["TX","FL"]). Omit for all 10 supported states. | |
| daysBack | No | Return registrations from the last N days (1-90, default 7). PA lags ~1 week; use 10+ for PA. | |
| sinceDate | No | Fixed start date YYYY-MM-DD (overrides daysBack). | |
| maxResultsPerState | No | Cap on registrations per state (1-2000, default 100). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does add useful context: the data is pulled from official state sources, limited to 10 states, and filtered by a date window, implying a read-only retrieval. However, it does not describe return shape, pagination, or data freshness caveats beyond what the schema already hints at.
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 sentences with no filler: the scope is front-loaded, then the use case follows. Every clause contributes.
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 definition is complete enough to select and invoke the tool given full schema param docs and zero required params. The main gap is the absence of an output schema and any statement about what the returned filings contain, which would improve invocation confidence.
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 all four parameters with descriptions, examples, and constraints (coverage is 100%), so the description adds little param-specific value. Its mention of 'windowed by date' is redundant with the daysBack/sinceDate parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Pull'), a defined resource ('newly registered U.S. businesses'), and concrete scope ('official state sources (10 states)' + date window). The recency and source make it easy to distinguish from siblings like business_search or federal_awards.
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?
Gives explicit intended use cases: sales-lead feeds and monitoring brand-new companies. It does not explicitly say when not to use it or point to an alternative tool, so it falls just short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen a person or business name against 12 U.S. government watchlists (OFAC SDN, BIS Entity/Denied/Unverified/MEU, State Dept Debarred/ISN, and more) via the Consolidated Screening List. Returns fuzzy-matched records. NOTE: name-based matching, NOT identity confirmation — verify any hit against the official source before acting.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Person or business name to screen | |
| lists | No | Restrict to source-list name substrings (e.g. ["SDN","Entity List"]). Omit for all lists. | |
| minScore | No | Minimum fuzzy-match score 0-100 (default 85). | |
| maxResults | No | Cap on matches returned (1-500, default 100). | |
| includeAliases | No | Also match alternate names/AKAs. Default true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It clearly discloses fuzzy matching, name-based matching, return of matched records, and the risk that hits are not identity confirmation. It could add output field or rate-limit details, but the key behavioral caveat is well covered.
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 dense, front-loaded sentences. The first scopes the tool and names its data sources; the second states the return behavior and adds the essential verification caveat. No 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 five-parameter tool with no annotations and no output schema, the description plus fully documented schema is sufficient for an agent to select and invoke it correctly. A minor gap is the lack of an explicit read-only/no-side-effect statement, though 'screen' and 'returns' strongly imply it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already documents all five parameters. The description reinforces the fuzzy-match behavior tied to minScore and includeAliases, but does not add substantial meaning beyond the schema, so baseline 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?
States a specific action (screen) against a specific resource (person/business name against 12 U.S. government watchlists via the Consolidated Screening List). Enumerated list sources make the scope concrete and clearly distinguish it from sibling tools like business_search or federal_awards.
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?
Provides clear context for when to use: name-based watchlist screening. The NOTE adds an important boundary (not identity confirmation, verify before acting), but it does not explicitly name alternative tools or state conditions that should route the agent elsewhere.
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. Dates show when Glama detected each change.
v0.1.2business_searchfederal_awardsnew_business_filingswatchlist_screenEach tool targets a distinct data source and workflow: registration lookup, new-filing lead generation, watchlist screening, and federal awards. business_search and new_business_filings both involve state registrations, but one is a name-based lookup and the other is a date-windowed list, so there is little risk of misselection.
All names are lowercase snake_case and readable, but they do not follow a single verb_noun or object_verb pattern. business_search and watchlist_screen end with action-like words, while new_business_filings and federal_awards are pure noun phrases, creating a mixed but not chaotic convention.
Four tools is a tight, well-scoped set for a business-intelligence server. Each tool covers a distinct area without redundancy, and none feel like filler or unnecessary splits.
The set covers the core U.S. business-intelligence workflows: entity lookup, new-company lead generation, sanctions/debarment screening, and federal award data. Minor additions like beneficial-ownership details or state-level contract data would improve coverage, but the current surface is not incomplete enough to cause agent failures.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Agent-native MCP server over 49M+ US public and government records, privacy-first, always current.
US public-records intelligence for AI agents — companies, SEC, courts, spending, licenses.
Hosted MCP server for real-world data: business registries, sanctions, companies, domains, crypto.
Agent-native MCP over US public + government records, entity- and parcel-keyed.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/whetstone-tools/whetstone-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server