Free read-only lookups of Oregon contractor licenses and FDA food recalls for AI agents. No key.
Scored across 2 tools
The two tools cover entirely different domains — FDA food recall enforcement reports versus Oregon contractor license records — so there is no plausible way to confuse them. Each description also clearly states its own scope limits (FDA food only, not USDA meat; Oregon only), reinforcing the boundary.
Both names follow the same snake_case '<jurisdiction/source>_<subject>_check' pattern, and the shared '_check' suffix signals that both are read-only lookups. The structure is predictable and would scale cleanly if more checks were added.
Two tools is on the thin side for a server framed as general 'public-records checks'; the surface feels like a starting point rather than a scoped toolkit. Each tool does earn its place, but there is little breadth to justify the generic server name.
Each tool is internally complete for its single lookup (matches, status, dates, and explicit caveats about what a hit or miss means). However, the overall surface is narrow — only FDA food recalls and only Oregon contractor licenses, with no USDA recalls, other states, or discipline/complaint data despite being flagged as relevant.
Find FDA food recall (enforcement) reports whose recalling firm matches a supplier or manufacturer name, in openFDA's food/enforcement data (FDA Enforcement Reports published since 2012). Words like Inc, LLC and Co are ignored; every remaining word must appear in the firm name. For each name returns the total number of matching reports and the 10 most recent: firm, location, product, reason, classification, status, dates and recall number. A match on name alone may be a different firm with a similar name, and no match does not mean a firm or product is safe. Covers FDA-regulated food only (not meat or poultry, which USDA handles).
| Name | Required | Description | Default |
|---|---|---|---|
| names | Yes | Supplier or manufacturer names, one per item, up to 10. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld, and the description adds substantive context beyond them: the matching algorithm (stopwords like Inc/LLC ignored, all remaining words must appear in the firm name), the exact fields returned, the 10-most-recent cap, and explicit false-positive/false-negative warnings. It also discloses the 2012 coverage boundary and the FDA vs USDA jurisdictional limit.
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 action and data source, followed by the matching rule, then return shape, then caveats, then scope. Every sentence carries distinct information; nothing is redundant with annotations or schema.
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, the description fully specifies the return payload (total count plus the 10 most recent reports with firm, location, product, reason, classification, status, dates, recall number). It also covers the matching semantics, data vintage, and domain boundaries an agent needs to call and interpret this 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?
Schema coverage is 100%, which sets a baseline of 3, but the description goes further by explaining how each name string is matched (ignored corporate suffixes, conjunctive word matching). The schema already caps the array at 10 names, so the description's added matching semantics are the real value here.
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 (find), resource (FDA food recall/enforcement reports), matching key (recalling firm name), and data source (openFDA food/enforcement since 2012). This is unambiguous and cannot be confused with the unrelated sibling oregon_license_check.
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 clear conditions for use: supplying supplier/manufacturer names, with explicit caveats that a name match may be a different firm and that no match does not imply safety, plus scope limits (FDA food only, not USDA meat/poultry). It does not name any alternative tool or when not to call it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up Oregon Construction Contractors Board (CCB) licenses by license number or business name in the state's public "CCB Active Licenses" dataset on data.oregon.gov. For each match returns the business name, city, endorsements, and the expiry dates of the license, the bond and the liability insurance on file (with company and amount), days left counted from today in Oregon, and a status: expired, due (within 30 days) or ok. Not found means not on the active list today: the license may be inactive, expired or suspended, or the number or spelling may differ. Does not show complaints or discipline history and does not check what a policy covers. Oregon only. The CCB's own records (https://search.ccb.state.or.us/search/) are the official source.
| Name | Required | Description | Default |
|---|---|---|---|
| queries | Yes | CCB license numbers (e.g. "123456") or business names (at least 3 characters), one per item. Up to 20 items, of which up to 5 business names. A name returns up to 10 matching businesses. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial context beyond them: the returned fields, the status derivation (expired/due/ok) with days counted from today in Oregon time, and the critical interpretation of a not-found result. It also points to the official CCB source for authoritative verification.
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 what it does and what it returns, then caveats. Dense but mostly earned; 'Oregon only' and the state-dataset phrasing mildly duplicate the opening sentence, costing a little tightness.
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, the description carries the return-value burden and does so fully — fields, status semantics, and match-count behavior. For a single-parameter read tool, nothing an agent needs to call it or interpret results 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 100%, so the query format, length limits, batch caps and per-name match limits are already documented in the schema. The description only restates that lookup works by license number or business name, adding no syntax or format detail beyond it. 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 verb (look up) and resource (Oregon CCB licenses) and names the exact upstream dataset, so the tool is unambiguous. It is clearly distinguishable from the unrelated sibling fda_recall_check.
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 clear scope conditions ('Oregon only', license number or business name) and explicit exclusions ('does not show complaints or discipline history and does not check what a policy covers'), which tell the agent when this tool cannot answer. It does not name an alternative tool for those out-of-scope questions, so it stops 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
fda_recall_checkoregon_license_checkKeyless, read-only US public records for agents: SEC, FDA, enforcement, sanctions, market data.
Public data for agents: CVEs, SEC filings, housing, wildfire, contractor licenses, EPA labels.
Free web search, 130M+ business records, local search, weather and travel data for AI agents.
US public-records intelligence for AI agents — companies, SEC, courts, spending, licenses.
Add one secure layer between your agents and this server.