npn_check
FREE. Verify a Natural Product Number (NPN/DIN-HM) is licensed by Health Canada: product, company, form, status.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| npn | Yes |
FREE. Verify a Natural Product Number (NPN/DIN-HM) is licensed by Health Canada: product, company, form, status.
| Name | Required | Description | Default |
|---|---|---|---|
| npn | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden; it discloses the cost ('FREE') and what data comes back, and 'Verify' implies a read-only lookup. It omits permissions/auth needs, rate limits, and crucially what the response looks like when the number is NOT licensed (empty result vs negative status).
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 front-loaded sentence with the cost signal first and the value proposition immediately after; no filler. The 'FREE.' fragment is terse but earns its place as a selection differentiator.
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 and no annotations, so the description must carry the full burden. It compensates by enumerating the returned fields and the identifier domain, but leaves out the not-found behavior and identifier formatting, which an agent needs to call 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?
Schema coverage is 0% for the single required 'npn' param, so the description must compensate. It does partially by naming the accepted identifier types (NPN and DIN-HM), but gives no format, length, or normalization guidance for what is likely a digits-only or prefix-formatted string.
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 (Verify) and resource (NPN/DIN-HM licensing by Health Canada), and enumerates the returned attributes (product, company, form, status). It does not explicitly name how it differs from npn_detail or batch_npn_check, but the single-identifier verification framing is 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?
No when-to-use or when-not guidance against the two siblings. 'FREE' is a useful cost signal that may steer selection away from metered alternatives, but there is no statement of when to prefer npn_detail (full record) or batch_npn_check (multiple identifiers) over this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.