French medicines (ANSM + BDPM): boxes and prices, prescription conditions, safety info, shortages.
Scored across 6 tools
Each tool has a reasonably distinct role: single-entity lookups (get_availability, get_medicine_info, is_major_therapeutic_interest), a fuzzy search (search_medicine), and two listing tools (list_current_shortages, recent_changes). The main overlap is between get_availability, get_medicine_info and search_medicine, which all surface shortage data for a medicine, but their input shapes (exact identifier vs. name/substance query) and payloads differ enough to guide selection.
Most names follow a verb_noun pattern (get_availability, get_medicine_info, list_current_shortages, search_medicine), with is_major_therapeutic_interest as a readable predicate-style exception. recent_changes is the one outlier that drops the verb entirely, a minor inconsistency in an otherwise predictable scheme.
Six tools is well matched to a focused domain of French medicine data and ANSM shortages: one search, two entity lookups, one attribute check, and two shortage feeds. No tool looks redundant or tacked on, and nothing essential seems to be crammed into an overloaded catch-all.
The surface covers the core lifecycle: find a medicine, get its boxes/pricing/reimbursement, check shortage status, list active shortages, track recent changes, and check MITM status. Minor gaps exist, such as browsing by therapeutic area/ATC class or retrieving composition/leaflet details, but agents can work around these via search_medicine and get_medicine_info.
Current ANSM shortage status of one medicine, given exactly one of: its CIS code, an ANSM shortage id or a name. Returns the status, the expected return in ANSM's wording, the change history and possibly related unlinked entries. Information only: never use this to recommend a substitute, an alternative or an equivalent medicine, a dosage change or stopping a treatment. Other medicines in the results are not alternatives.
| Name | Required | Description | Default |
|---|---|---|---|
| cis | No | 8-digit BDPM medicine code (CIS). | |
| name | No | Medicine name; resolved to one CIS or a list of candidates. | |
| shortage_id | No | ANSM shortage id: the numeric id of an ANSM shortage entry. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| safety | Yes | |
| source | Yes | |
| warning | No | |
| disclaimer | Yes | |
| coverage_note | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a safe, read-only, idempotent operation, and the description adds useful behavioral context beyond that. It discloses what is returned (status, expected return in ANSM's wording, change history, possibly related unlinked entries) and includes an explicit safety boundary against using the result for clinical recommendations. It does not contradict any annotation.
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 front-loaded with the core purpose and input constraint, then covers return contents and safety restrictions in compact sentences. The final note that other medicines in results are not alternatives reinforces the safety boundary without excessive 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?
Given rich annotations, an output schema, full schema description coverage, and three optional identifier parameters, the description supplies everything an agent needs to call the tool correctly. It covers purpose, identifier selection, return behavior, and the key safety limitation.
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 parameter meanings are already documented in the schema. The description still adds an important semantic constraint not encoded in the schema: exactly one of cis, shortage_id, or name must be supplied. That is meaningful beyond the structured parameter descriptions.
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 and resource: getting the current ANSM shortage status of one medicine. It also distinguishes the scope from list-oriented siblings by specifying exactly one medicine and exactly one identifier. An agent can identify the intended operation without opening another schema.
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 gives clear usage conditions: exactly one of CIS code, ANSM shortage id, or name, and it explicitly says the tool is information-only and must not be used to recommend substitutes, alternatives, dosage changes, or stopping treatment. It does not explicitly route the agent among siblings such as search_medicine or list_current_shortages, so it falls short of the strongest usage-guidance score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Boxes of a medicine in the French public medicines database (BDPM), its prescription and dispensing conditions and its current ANSM safety information, given exactly one of its CIS code, a CIP13 barcode or its name. Each box has its CIP13, marketing status, price and reimbursement rate. Information only: never use this to recommend a substitute, an alternative or an equivalent medicine, a dosage change or stopping a treatment. Other medicines in the results are not alternatives.
| Name | Required | Description | Default |
|---|---|---|---|
| cis | No | 8-digit BDPM medicine code (CIS). | |
| name | No | Medicine name; resolved to one CIS or a list of candidates. | |
| cip13 | No | 13-digit CIP13 code of a box (presentation), as printed on its barcode. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| safety | Yes | |
| source | Yes | |
| warning | No | |
| disclaimer | Yes | |
| coverage_note | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds real context beyond them: the exactly-one-identifier constraint (important since required_parameters is 0), the advisory-only framing, and the caution that co-occurring medicines are not substitutes. It doesn't state what happens when no candidate matches a name.
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?
Three sentences, front-loaded with what is returned before the constraints, and every sentence carries either scope, a disambiguation rule, or a safety boundary. It is dense and runs as a single paragraph, but nothing is redundant.
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 an output schema present, return values needn't be described, and the description instead covers the things the schema and annotations cannot: identifier exclusivity, advisory-only use, and the non-equivalence of co-listed medicines. Nothing an agent needs to invoke it correctly 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 baseline would be 3, but the description adds the mutual-exclusivity rule ('given exactly one of') that the schema does not encode via oneOf, plus name resolution to 'one CIS or a list of candidates'. Format details (8-digit, 13-digit barcode) are left to the schema, appropriately.
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 a concrete resource (boxes of a medicine in the BDPM, plus prescription/dispensing conditions and current ANSM safety information) and the exact access keys (CIS, CIP13, or name), which lets an agent separate it from a name-based search tool. It stops short of naming search_medicine or any sibling, so routing among lookups is inferred rather than stated.
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 an explicit prohibition — never use for substitute/alternative/dosage-change/stopping-treatment advice — and clarifies that other medicines in results are not alternatives. What is missing is positive routing guidance: when to pass a name here versus calling search_medicine first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Whether a medicine, given exactly one of its CIS code or its name, is on the BDPM list of medicines of major therapeutic interest (MITM), with its ATC code. Information only: never use this to recommend a substitute, an alternative or an equivalent medicine, a dosage change or stopping a treatment. Other medicines in the results are not alternatives.
| Name | Required | Description | Default |
|---|---|---|---|
| cis | No | 8-digit BDPM medicine code (CIS). | |
| name | No | Medicine name; resolved to one CIS or a list of candidates. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| safety | Yes | |
| source | Yes | |
| warning | No | |
| disclaimer | Yes | |
| coverage_note | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, so the description is free to add what they cannot: the one-of param exclusivity, the fact that name input resolves to candidates, and the critical caveat that other medicines appearing in results are not alternatives. That last point is genuine behavioral context beyond any structured field.
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, front-loaded with the core predicate and scope, followed by a compact safety clause. No filler, and the most safety-critical warning is unambiguous.
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?
An output schema exists, so return values need not be explained, and the description still flags that ATC code comes back with the answer. Combined with the input rule and the non-alternative caveat, an agent has enough to call this correctly and interpret results safely.
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 baseline is 3, but the description adds the mutual-exclusivity constraint ('exactly one of') that the schema's empty required list does not convey. That is meaningful semantic guidance not present in the structured data.
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 predicate (is the medicine on the BDPM MITM list) and the payload (ATC code), which is far more specific than the title. It does not explicitly contrast itself with siblings like get_medicine_info or search_medicine, so sibling differentiation is left to inference.
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 states the input rule ('given exactly one of its CIS code or its name') and gives hard prohibitions on downstream use (no substitute/alternative/equivalent recommendations, no dosage change, no stopping treatment). It stops short of naming when to prefer a sibling tool instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List medicine shortages currently published by ANSM, latest update first, filtered by status, scope, therapeutic area and update date, with the CIS codes of the matched medicines. Information only: never use this to recommend a substitute, an alternative or an equivalent medicine, a dosage change or stopping a treatment. Other medicines in the results are not alternatives.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| scope | No | ville (city pharmacies), hopital (hospitals), ville_hopital or inconnu. | |
| offset | No | ||
| status | No | ||
| updated_since | No | Only entries updated by ANSM on or after this date (YYYY-MM-DD). | |
| therapeutic_area | No | Therapeutic area as written by ANSM, e.g. "cardiologie". |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| safety | Yes | |
| source | Yes | |
| warning | No | |
| disclaimer | Yes | |
| coverage_note | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds value beyond that: result ordering (latest ANSM update first), the fact that CIS codes of matched medicines are returned, and a hard clinical-use constraint. It doesn't mention pagination behavior or the default status filter, which is the remaining gap.
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 operation, filters and ordering, then the safety constraint. The closing sentence "Other medicines in the results are not alternatives" partially repeats the preceding prohibition, a minor redundancy in an otherwise tight definition.
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 an output schema present, return-format detail is unnecessary, and annotations cover the safety profile, so the description covers what an agent needs to call it safely and correctly. Missing only the implicit default status filter and page-size/cursor behavior, which affect the results an agent receives.
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 names four of the six filters (status, scope, therapeutic area, update date), but those same four are already documented in the schema, so it adds little beyond restating them. limit and offset carry no schema description and get no coverage from the prose, and the default status set (rupture, tension) is never explained.
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 and resource (list medicine shortages published by ANSM) plus ordering (latest update first) and the filter dimensions, so the operation is unambiguous. It does not name or contrast any sibling tool (e.g. get_availability, recent_changes), so an agent must infer which of the six tools to pick.
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 when-not-to-use guidance: "Information only: never use this to recommend a substitute, an alternative or an equivalent medicine, a dosage change or stopping a treatment." That is a concrete exclusion, though it doesn't route the agent to a sibling tool for availability or per-medicine lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shortage changes detected in the last days (new entries, status changes, expected-return changes, delisted and relisted entries), latest first, with counts per change type. Information only: never use this to recommend a substitute, an alternative or an equivalent medicine, a dosage change or stopping a treatment. Other medicines in the results are not alternatives.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| limit | No | ||
| change_types | No |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| safety | Yes | |
| source | Yes | |
| warning | No | |
| disclaimer | Yes | |
| coverage_note | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds ordering ('latest first'), aggregation ('counts per change type'), and an important interpretation caveat about co-occurring medicines in results — meaningful context beyond the 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?
Front-loaded with the scope and content of the result set in a single dense sentence, followed by the safety constraint. The caveat is restated twice ('never use this to recommend a substitute...' and 'Other medicines in the results are not alternatives'), which is mildly redundant but defensible for a clinical safeguard.
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?
An output schema exists, so return-shape explanation is not required, and annotations cover the read-only profile. The remaining gap is that an agent gets no hint about result volume, defaults, or how to narrow output via limit, which would matter when results are large.
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 carry parameter meaning. It implies the time window ('in the last days') and lists the five change types (matching the change_types enum), but never mentions the limit parameter, nor defaults (7 days / 50 results), nor the 1–90 and 1–50 bounds.
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 and resource — shortage changes detected over a recent window — and enumerates exactly which change classes are included (new, status_change, return_date_change, delisted, relisted), which implicitly separates it from the snapshot-oriented list_current_shortages. It never names a sibling or explicitly contrasts with it, so it falls 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?
Gives an explicit hard prohibition — 'never use this to recommend a substitute, an alternative or an equivalent medicine, a dosage change or stopping a treatment' — and clarifies that other medicines appearing in results are not alternatives, which is genuine routing/interpretation guidance. It does not say when to use this instead of list_current_shortages or get_availability, so it stops at 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search French medicines (BDPM) by name or active substance and show the ANSM shortage linked to each, plus listed shortages not linked to any medicine that match the query. Medicines in rupture or tension come first. Information only: never use this to recommend a substitute, an alternative or an equivalent medicine, a dosage change or stopping a treatment. Other medicines in the results are not alternatives.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Medicine name (brand) or active substance, e.g. "doliprane" or "amoxicilline". | |
| only_in_shortage | No | Keep only medicines whose current shortage status is rupture or tension. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| safety | Yes | |
| source | Yes | |
| warning | No | |
| disclaimer | Yes | |
| coverage_note | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real behavioral context beyond them: results are ranked with rupture/tension medicines first, and the response mixes in standalone shortages not attached to any medicine — a non-obvious shape an agent must anticipate. The safety framing about not inferring substitutability is a substantive use constraint, not a restatement.
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 result composition, then the ordering rule, then the safety guardrail. The only mild redundancy is the closing 'Other medicines in the results are not alternatives', which re-states the earlier prohibition — defensible given the medical risk, but it is a repeat.
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?
An output schema exists, so return values need not be described, and annotations cover the safety profile. What the description does supply — ranking, mixed shortage records, and the no-substitution rule — addresses the highest-risk ambiguities. Remaining gaps (empty-result behavior, matching fuzziness, how limit interacts with the two result groups) are minor for a 3-parameter read tool.
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 67%: query and only_in_shortage are documented in the schema, limit is self-evident from default/min/max. The description restates that the query targets name or active substance, which duplicates the schema rather than adding syntax, accent, or matching-behavior detail. Baseline 3 is appropriate given the schema does most of the work.
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 (search), a specific resource (French medicines / BDPM) and the two axes queried (name or active substance), plus what the result set contains (linked ANSM shortage per medicine, plus unlinked shortages matching the query). It is clearly a search tool rather than a detail lookup, so get_medicine_info and list_current_shortages are distinguishable, though no sibling is named explicitly.
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 an explicit and emphatic when-not-to-use rule: never use it to recommend substitutes, alternatives, equivalents, dosage changes, or stopping treatment. It also explains ordering behavior (rupture/tension first), which helps interpret results. It does not, however, route the agent between this and get_medicine_info or list_current_shortages when those might be the better call.
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_availability1 field changedInput schema / properties / shortage_id / descriptionPrevious value: -"ANSM shortage id, as returned by the other tools."New value: +"ANSM shortage id: the numeric id of an ANSM shortage entry."get_availability2 fields changedOutput schema / properties / source / properties / bdpm_imported_atAdded value: +{
+ "anyOf": [
+ {
+ "format": "date-time",
+ "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / source / requiredPrevious value: -[
- "ansm",
- "bdpm",
- "ansm_last_ingest",
- "bdpm_release"
-]New value: +[
+ "ansm",
+ "bdpm",
+ "ansm_last_ingest",
+ "bdpm_release",
+ "bdpm_imported_at"
+]get_medicine_info2 fields changedOutput schema / properties / source / properties / bdpm_imported_atAdded value: +{
+ "anyOf": [
+ {
+ "format": "date-time",
+ "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / source / requiredPrevious value: -[
- "ansm",
- "bdpm",
- "ansm_last_ingest",
- "bdpm_release"
-]New value: +[
+ "ansm",
+ "bdpm",
+ "ansm_last_ingest",
+ "bdpm_release",
+ "bdpm_imported_at"
+]is_major_therapeutic_interest2 fields changedOutput schema / properties / source / properties / bdpm_imported_atAdded value: +{
+ "anyOf": [
+ {
+ "format": "date-time",
+ "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / source / requiredPrevious value: -[
- "ansm",
- "bdpm",
- "ansm_last_ingest",
- "bdpm_release"
-]New value: +[
+ "ansm",
+ "bdpm",
+ "ansm_last_ingest",
+ "bdpm_release",
+ "bdpm_imported_at"
+]list_current_shortages2 fields changedOutput schema / properties / source / properties / bdpm_imported_atAdded value: +{
+ "anyOf": [
+ {
+ "format": "date-time",
+ "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / source / requiredPrevious value: -[
- "ansm",
- "bdpm",
- "ansm_last_ingest",
- "bdpm_release"
-]New value: +[
+ "ansm",
+ "bdpm",
+ "ansm_last_ingest",
+ "bdpm_release",
+ "bdpm_imported_at"
+]recent_changes2 fields changedOutput schema / properties / source / properties / bdpm_imported_atAdded value: +{
+ "anyOf": [
+ {
+ "format": "date-time",
+ "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / source / requiredPrevious value: -[
- "ansm",
- "bdpm",
- "ansm_last_ingest",
- "bdpm_release"
-]New value: +[
+ "ansm",
+ "bdpm",
+ "ansm_last_ingest",
+ "bdpm_release",
+ "bdpm_imported_at"
+]search_medicine2 fields changedOutput schema / properties / source / properties / bdpm_imported_atAdded value: +{
+ "anyOf": [
+ {
+ "format": "date-time",
+ "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / source / requiredPrevious value: -[
- "ansm",
- "bdpm",
- "ansm_last_ingest",
- "bdpm_release"
-]New value: +[
+ "ansm",
+ "bdpm",
+ "ansm_last_ingest",
+ "bdpm_release",
+ "bdpm_imported_at"
+]get_medicine_info1 field changedOutput schema / properties / data / oneOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "kind": {
- "const": "info",
- "type": "string"
- },
- "medicine": {
- "additionalProperties": false,
- "properties": {
- "cis": {
- "pattern": "^\\d{8}$",
- "type": "string"
- },
- "form": {
- "type": [
- "string",
- "null"
- ]
- },
- "holder": {
- "type": [
- "string",
- "null"
- ]
- },
- "is_mitm": {
- "type": "boolean"
- },
- "marketing_status": {
- "type": [
- "string",
- "null"
- ]
- },
- "name": {
- "type": "string"
- },
- "routes": {
- "type": [
- "string",
- "null"
- ]
- }
- },
- "required": [
- "cis",
- "name",
- "form",
- "routes",
- "holder",
- "marketing_status",
- "is_mitm"
- ],
- "type": "object"
- },
- "presentations": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "admin_status": {
- "type": [
- "string",
- "null"
- ]
- },
- "cip13": {
- "pattern": "^\\d{13}$",
- "type": "string"
- },
- "cip7": {
- "type": [
- "string",
- "null"
- ]
- },
- "declared_at": {
- "anyOf": [
- {
- "format": "date",
- "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "dispensing_fee_eur": {
- "type": [
- "number",
- "null"
- ]
- },
- "hospital_approval": {
- "type": [
- "boolean",
- "null"
- ]
- },
- "label": {
- "type": "string"
- },
- "marketing_status": {
- "type": [
- "string",
- "null"
- ]
- },
- "price_eur": {
- "type": [
- "number",
- "null"
- ]
- },
- "public_price_eur": {
- "type": [
- "number",
- "null"
- ]
- },
- "reimbursement_indications": {
- "type": [
- "string",
- "null"
- ]
- },
- "reimbursement_rates": {
- "items": {
- "maximum": 9007199254740991,
- "minimum": 0,
- "type": "integer"
- },
- "type": "array"
- }
- },
- "required": [
- "cip13",
- "cip7",
- "label",
- "admin_status",
- "marketing_status",
- "declared_at",
- "hospital_approval",
- "reimbursement_rates",
- "price_eur",
- "public_price_eur",
- "dispensing_fee_eur",
- "reimbursement_indications"
- ],
- "type": "object"
- },
- "type": "array"
- }
- },
- "required": [
- "kind",
- "medicine",
- "presentations"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "candidates": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "cis": {
- "pattern": "^\\d{8}$",
- "type": "string"
- },
- "name": {
- "type": "string"
- }
- },
- "required": [
- "cis",
- "name"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "kind": {
- "const": "candidates",
- "type": "string"
- }
- },
- "required": [
- "kind",
- "candidates"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "kind": {
- "const": "not_found",
- "type": "string"
- },
- "possibly_related_shortages": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "ansm_updated_at": {
- "anyOf": [
- {
- "format": "date",
- "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "ansm_url": {
- "format": "uri",
- "type": "string"
- },
- "dci": {
- "type": [
- "string",
- "null"
- ]
- },
- "expected_return": {
- "additionalProperties": false,
- "properties": {
- "earliest": {
- "anyOf": [
- {
- "format": "date",
- "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "latest": {
- "anyOf": [
- {
- "format": "date",
- "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "part": {
- "anyOf": [
- {
- "enum": [
- "debut",
- "mi",
- "fin"
- ],
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "passed": {
- "type": "boolean"
- },
- "precision": {
- "anyOf": [
- {
- "enum": [
- "day",
- "month",
- "quarter",
- "year"
- ],
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "raw": {
- "type": [
- "string",
- "null"
- ]
- }
- },
- "required": [
- "earliest",
- "latest",
- "precision",
- "part",
- "raw",
- "passed"
- ],
- "type": "object"
- },
- "match_confidence": {
- "type": [
- "number",
- "null"
- ]
- },
- "match_note": {
- "const": "probable match",
- "type": "string"
- },
- "name": {
- "type": "string"
- },
- "returned_at": {
- "anyOf": [
- {
- "format": "date",
- "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "scope": {
- "enum": [
- "ville",
- "hopital",
- "ville_hopital",
- "inconnu"
- ],
- "type": "string"
- },
- "scope_raw": {
- "type": [
- "string",
- "null"
- ]
- },
- "shortage_id": {
- "type": "string"
- },
- "status": {
- "enum": [
- "rupture",
- "tension",
- "arret_commercialisation",
- "remise_a_disposition",
- "autre"
- ],
- "type": "string"
- },
- "status_label_fr": {
- "type": "string"
- }
- },
- "required": [
- "shortage_id",
- "name",
- "dci",
- "status",
- "status_label_fr",
- "scope",
- "scope_raw",
- "expected_return",
- "returned_at",
- "ansm_updated_at",
- "ansm_url",
- "match_confidence"
- ],
- "type": "object"
- },
- "type": "array"
- }
- },
- "required": [
- "kind",
- "possibly_related_shortages"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "kind": {
+ "const": "info",
+ "type": "string"
+ },
+ "medicine": {
+ "additionalProperties": false,
+ "properties": {
+ "cis": {
+ "pattern": "^\\d{8}$",
+ "type": "string"
+ },
+ "form": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "holder": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "is_mitm": {
+ "type": "boolean"
+ },
+ "marketing_status": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "routes": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "cis",
+ "name",
+ "form",
+ "routes",
+ "holder",
+ "marketing_status",
+ "is_mitm"
+ ],
+ "type": "object"
+ },
+ "prescription_conditions": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "presentations": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "admin_status": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "cip13": {
+ "pattern": "^\\d{13}$",
+ "type": "string"
+ },
+ "cip7": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "declared_at": {
+ "anyOf": [
+ {
+ "format": "date",
+ "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "dispensing_fee_eur": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "hospital_approval": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "label": {
+ "type": "string"
+ },
+ "marketing_status": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "price_eur": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "public_price_eur": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "reimbursement_indications": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "reimbursement_rates": {
+ "items": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "cip13",
+ "cip7",
+ "label",
+ "admin_status",
+ "marketing_status",
+ "declared_at",
+ "hospital_approval",
+ "reimbursement_rates",
+ "price_eur",
+ "public_price_eur",
+ "dispensing_fee_eur",
+ "reimbursement_indications"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "safety_information": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "ends_on": {
+ "format": "date",
+ "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
+ "type": "string"
+ },
+ "starts_on": {
+ "format": "date",
+ "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "url",
+ "starts_on",
+ "ends_on"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "kind",
+ "medicine",
+ "presentations",
+ "prescription_conditions",
+ "safety_information"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "candidates": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "cis": {
+ "pattern": "^\\d{8}$",
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "cis",
+ "name"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "kind": {
+ "const": "candidates",
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "candidates"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "kind": {
+ "const": "not_found",
+ "type": "string"
+ },
+ "possibly_related_shortages": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "ansm_updated_at": {
+ "anyOf": [
+ {
+ "format": "date",
+ "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "ansm_url": {
+ "format": "uri",
+ "type": "string"
+ },
+ "dci": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "expected_return": {
+ "additionalProperties": false,
+ "properties": {
+ "earliest": {
+ "anyOf": [
+ {
+ "format": "date",
+ "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "latest": {
+ "anyOf": [
+ {
+ "format": "date",
+ "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "part": {
+ "anyOf": [
+ {
+ "enum": [
+ "debut",
+ "mi",
+ "fin"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "passed": {
+ "type": "boolean"
+ },
+ "precision": {
+ "anyOf": [
+ {
+ "enum": [
+ "day",
+ "month",
+ "quarter",
+ "year"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "raw": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "earliest",
+ "latest",
+ "precision",
+ "part",
+ "raw",
+ "passed"
+ ],
+ "type": "object"
+ },
+ "match_confidence": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "match_note": {
+ "const": "probable match",
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "returned_at": {
+ "anyOf": [
+ {
+ "format": "date",
+ "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "scope": {
+ "enum": [
+ "ville",
+ "hopital",
+ "ville_hopital",
+ "inconnu"
+ ],
+ "type": "string"
+ },
+ "scope_raw": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "shortage_id": {
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "rupture",
+ "tension",
+ "arret_commercialisation",
+ "remise_a_disposition",
+ "autre"
+ ],
+ "type": "string"
+ },
+ "status_label_fr": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "shortage_id",
+ "name",
+ "dci",
+ "status",
+ "status_label_fr",
+ "scope",
+ "scope_raw",
+ "expected_return",
+ "returned_at",
+ "ansm_updated_at",
+ "ansm_url",
+ "match_confidence"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "kind",
+ "possibly_related_shortages"
+ ],
+ "type": "object"
+ }
+]get_medicine_infoget_availabilityis_major_therapeutic_interestlist_current_shortagesrecent_changessearch_medicinefrance-bdpm-medicines — France's official public medicines database (BDPM:
AEMPS CIMA — the Spanish Agency for Medicines and Health Products' public register of every…
French company data from public registers (Sirene, RNE, BODACC) and French legal notices.
US medication lookup: drug search, forms and strengths, NDC/RxCUI, recalls, shortages.
Add one secure layer between your agents and this server.