Federal drug shortages and recalls joined to the federal contracts that buy those drugs.
Scored across 5 tools
Each tool targets a distinct concern: freshness metadata, the derived supplier exposure join, and the three underlying FDA/USAspending list endpoints. get_supplier_exposure is clearly framed as a cross-source join rather than a duplicate of the list tools, so an agent should not confuse them.
All tool names follow a consistent lowercase verb_noun pattern: get_data_freshness and get_supplier_exposure use get_, while list_drug_recalls, list_drug_shortages, and list_federal_drug_contracts use list_. There are no mixed conventions or vague verbs.
Five tools is well-scoped for a niche drug supply-chain data server. Each tool covers a distinct data source or derived query, and none feels redundant or extraneous.
The core read-only workflow is covered: freshness check, source lists for recalls/shortages/contracts, and the derived supplier exposure join. A minor gap is the absence of a way to fetch individual record details or resolve company IDs independently, but agents can work around this with filters and the available list outputs.
Returns when the data was last activated, how many segments are live, and the state of the last run. Call this first when you need to know whether the data is fresh.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full disclosure burden. It transparently states the tool's read-only nature by saying it 'Returns' three specific pieces of information, and it adds a behavioral recommendation (call this first). It stops short of explicitly stating there are no side effects or describing error conditions, but for a zero-parameter getter the behavioral disclosure is largely adequate.
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 exactly two sentences: the first lists the concrete return values, the second tells the agent when to invoke the tool. Every word earns its place, and the most important behavioral detail is front-loaded.
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 no parameters, no input schema, and no output schema, the description is fully self-contained: it tells the agent what the tool returns and in which situation to use it. Nothing essential for correct invocation 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 tool has zero parameters, so the baseline is 4, and there is no parameter ambiguity. The description's mention of 'data' and 'segments' is enough to set context for what the tool reports, though it doesn't need to define parameter meanings.
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 ('Returns') and names the exact resource and output fields: last activated time, number of live segments, and last run state. This clearly distinguishes it from sibling tools like get_supplier_exposure or list_drug_recalls, which retrieve domain data rather than freshness metadata.
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 explicit situational guidance ('Call this first when you need to know whether the data is fresh'), establishing a clear trigger for use. It does not explicitly mention when not to use it or name alternative tools, but the context strongly implies this is the meta-data companion to the domain-data sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The join: a federal contract whose supplier has an FDA shortage or recall. Every row carries company_name, confidence (exact, probable or weak) and match_method. A cross source join is NEVER exact, because FDA and USAspending share no identifier. The claim is: this government supplier has an active FDA shortage or recall. It does NOT claim that this contract delivers that drug. Without a key you get exact and probable matches only, at most 20 rows, without the evidence field.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| award_id | No | federal award identifier | |
| company_id | No | ||
| min_confidence | No | weak needs a paid key |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does it well. It discloses that the join is never exact, explains the absence of a shared identifier, clarifies the claim boundary, and states the row limits and evidence-field behavior without a key.
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 dense but efficient, with every sentence contributing a distinct piece of information. It front-loads the core purpose and then adds necessary caveats without redundancy or 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?
Despite having no output schema or annotations, the description explains row fields, confidence semantics, key requirements, row limits, and the non-causal nature of the claim. It is largely complete for selecting and invoking the tool, though the undocumented company_id and limit parameters remain a minor 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?
The description adds valuable context for min_confidence by explaining exact/probable/weak levels and the paid-key constraint. However, it does not clarify the meaning or interaction of company_id and limit, and schema coverage is only 50%, so the description only partially compensates for missing parameter documentation.
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 defines the tool as a cross-source join between federal contracts and FDA shortages/recalls. It distinguishes the resource and claim precisely, and the explicit 'does NOT claim that this contract delivers that drug' makes its scope unmistakable compared to sibling list tools.
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 by defining what it returns, but it does not explicitly compare it to siblings or state when to choose it over alternatives. The key-dependent behavior provides some context for usage decisions, but no direct when/when-not guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FDA drug recalls and enforcement reports. Filters: classification (Class I, II, III), company_id, limit.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| company_id | No | ||
| classification | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavior. It implies a read-only listing and names filters, but does not disclose pagination behavior, default limits, output shape, data freshness, or whether some filters interact in non-obvious ways.
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 concise sentences with the main action front-loaded and the filter list compact. Every sentence earns its place with no unnecessary 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?
This is a simple list tool with three optional filters, and the description provides enough to attempt a basic call. However, without annotations or an output schema, it lacks detail on return values, defaults, and any filtering constraints, leaving some uncertainty for an agent.
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. It names all three parameters and adds enum values for classification, which is helpful. However, it does not clarify the expected format of company_id or the precise meaning and behavior of 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?
The description states a specific verb ('list') and a clear resource ('FDA drug recalls and enforcement reports'), which distinguishes it from sibling tools that focus on shortages or contracts. It is not vague, though it could more fully specify the scope of 'enforcement reports'.
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 lists filters but provides no guidance on when to use this tool versus the sibling alternatives. No exclusions, use-case context, or conditions are given, so an agent has to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current and resolved US drug shortages as reported by the FDA. Each row carries the generic name, the reporting company and its company_id. Filters: status, generic_name, company_id, limit.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| status | No | for example Current or Resolved | |
| company_id | No | ||
| generic_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose the data source, status coverage (current/resolved), and row fields. It does not cover defaults, pagination, error behavior, or access requirements, but the 'list' verb and filter list make the basic read-only behavior reasonably clear.
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 short sentences convey the resource, scope, row contents, and filter list with no filler. The most important information is front-loaded, and every sentence 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 straightforward list tool with four optional parameters and no output schema, the description covers the core data source, row fields, and filter options. It leaves some ambiguity about default filtering behavior and limit handling, but it is adequate for basic invocation.
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 only 25%, so the description needed to compensate, but it only restates the filter names (status, generic_name, company_id, limit) without explaining formats, constraints, or how they interact. It adds little meaning beyond the schema's parameter names.
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 identifies the resource ('US drug shortages as reported by the FDA') and the row contents (generic name, reporting company, company_id), and the tool name supplies the listing verb. It is distinct from siblings such as list_drug_recalls by subject matter, though it does not explicitly contrast itself 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?
The description implies when to use it: when FDA shortage records are needed, and lists the available filters. It does not explicitly state when to prefer this tool over list_drug_recalls or list_federal_drug_contracts, nor does it give exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
US federal contracts for drugs, product service code 6505, from USAspending. Filters: agency, company_id, limit.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| agency | No | ||
| company_id | 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. It discloses that the operation is a list/filter action sourced from USAspending and identifies the filtering traits. However, it does not disclose pagination behavior, defaults for limit, data freshness, or whether authentication or specific prerequisites apply.
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 concise, front-loaded sentence states the core purpose, then lists the filter parameters. There is no filler or redundancy; every phrase 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?
The definition is incomplete for an agent needing to invoke it correctly. There is no output schema, yet the description does not explain what the response contains. Parameter formats and defaults are unspecified, and there is no guidance on how this tool relates to sibling data sources. The sparse description leaves several operational 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%, so the description must compensate. It does add that agency, company_id, and limit are filters, but it does not define what agency refers to, what company_id represents, what values are accepted, or whether limit has a maximum/default. The parameter names alone carry most of the meaning.
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 specific resource ('US federal contracts for drugs'), the product service code ('6505'), and the data source ('USAspending'). This clearly distinguishes it from sibling tools like list_drug_recalls and list_drug_shortages, which concern different datasets.
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 you need US federal drug contract data from USAspending — but it does not explicitly contrast it with alternatives or state when not to use it. Context from sibling names helps, but the description itself provides no explicit 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.
get_supplier_exposure2 fields changedInput schema / properties / award_id / descriptionAdded value: +"federal award identifier"Input schema / properties / min_confidence / descriptionAdded value: +"weak needs a paid key"list_drug_shortages1 field changedInput schema / properties / status / descriptionAdded value: +"for example Current or Resolved"get_data_freshnessget_supplier_exposurelist_drug_recallslist_drug_shortageslist_federal_drug_contractsFederal government contracts and USAspending procurement exposure for SEC-listed companies.
Federal contracts, SAM notices, congressional trades, PAC money, insider trades, bills, EOs, themes.
US federal contracting data: open solicitations, buying agencies, contractors, price history.
Government contract search and federal procurement data: SAM.gov opportunities + USASpending awards.
Add one secure layer between your agents and this server.
