India's medicines: NPPA prices and ceilings, cheaper same-composition brands, CDSCO failed batches.
Scored across 6 tools
Each tool targets a distinct question: search_medicines for name resolution, get_brand for single-brand detail, compare_prices for cross-brand price spread, above_ceiling for pricing violations, company_profile for corporate aggregation, and failed_batches for quality alerts. The only mild overlap is search_medicines vs get_brand, but the 'start here' hint and the different return shapes make the boundary clear.
All names are snake_case and readable, but conventions are mixed: verb_noun patterns (get_brand, search_medicines, compare_prices) coexist with bare noun phrases (above_ceiling, company_profile, failed_batches). The split roughly reflects entity lookups vs filtered listings, so it is defensible rather than chaotic, but not a single predictable pattern.
Six tools is tightly scoped to the domain of Indian medicine pricing and quality data. Every tool answers a different question with no redundant entries, and none feels like filler.
The surface covers discovery, per-brand pricing, cross-brand comparison, ceiling violations, company rollups, and quality failures — a solid lifecycle for the stated purpose. Minor gaps remain: no way to browse or list ceiling orders / scheduled formulations directly, and no batch-level lookup by batch number.
Price-controlled packs whose filed MRP per unit is above NPPA's own ceiling price plus GST, by brand, company or molecule, most above first, with the ceiling order cited.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | brand, company or molecule |
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). The description adds useful behavioral detail – results are sorted 'most above first' and the ceiling order is cited – but says nothing about empty-result behavior, result limits, or pagination, leaving real 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?
A single, front-loaded sentence with no filler; the ordering guarantee is placed at the end where it belongs. Slightly dense but every clause carries information.
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 simple one-parameter read tool with no output schema, the description covers the domain, the sort order, and a key output element (cited ceiling order). It would be stronger with a note on result limits or what happens when no packs exceed the ceiling.
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%, and the single parameter's schema description ('brand, company or molecule') is essentially repeated by the tool description. No additional semantics such as matching rules or examples are provided, 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?
The description names a precise resource – price-controlled packs whose filed MRP per unit exceeds the NPPA ceiling plus GST – which an agent can distinguish from siblings like compare_prices or get_brand. It lacks an explicit action verb (list/report), but the domain scope is specific enough to be unambiguous.
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?
Usage is implied by the domain (compliance/pricing checks), but there is no explicit when-to-use or when-not-to-use guidance and no reference to the alternative siblings such as compare_prices. The 'by brand, company or molecule' phrasing hints at input modes but does not instruct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
An Indian pharmaceutical company group in NPPA's filings: the names it files under, counts of packs, brands and molecules, its largest molecules, batches CDSCO declared not of standard quality, and packs filed above the price ceiling.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | company name, e.g. 'Cipla', or its counterfoil.in page URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, closed-world, non-destructive, so the safety profile is covered. The description adds valuable provenance (NPPA filings, CDSCO declarations) and scope of aggregation. It does not disclose what happens on ambiguous or unresolved company names, which matters because the parameter accepts either a name or a URL.
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 dense sentence with no filler, front-loaded with the entity type and data source. The trailing list of included aggregates is long but each item earns its place as a return-value preview.
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 must stand in for return values, and the enumeration does that reasonably well. It leaves gaps around response shape, name-resolution behavior, and error cases, which is meaningful for a lookup tool keyed on free-text company names.
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% and the single parameter documents both accepted forms (bare name like 'Cipla' or a counterfoil.in page URL). The phrase 'the names it files under' hints that aliases are resolved, which is a small addition, but nothing about matching behavior or fallback is specified.
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?
Names the resource precisely ('An Indian pharmaceutical company group in NPPA's filings') and enumerates exactly what the profile aggregates: filing names, pack/brand/molecule counts, top molecules, NSQ batches, above-ceiling packs. The verb is implicit ('profile' as a noun phrase) rather than an explicit 'returns/fetches', which keeps it just short of a 5, but an agent can tell this apart from get_brand or search_medicines.
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 statement of when to use this versus the siblings above_ceiling, failed_batches, compare_prices, get_brand, or search_medicines, even though several overlap in subject matter (price ceiling, failed batches). Usage is inferable only from the enumerated contents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every brand of one composition sold in India, lowest price per unit first, with the lowest, median and highest per-unit price for each strength and form. Use for 'cheapest ' or 'how much should cost'.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| molecule | Yes | generic name or combination, e.g. 'telmisartan' or 'amoxycillin + clavulanic acid' | |
| strength | No | optional, e.g. '40 MG' or '500/125' |
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 beyond that: the result ordering (lowest per-unit price first) and the per-strength/form aggregates (lowest, median, highest), which is real behavioral context. It never mentions the limit cap (max 25) or what happens when no brands match, so a 5 isn't warranted.
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, no filler, with the result shape front-loaded ahead of the usage examples. The first sentence is long and crams ordering plus three aggregate stats together, which slightly hurts scanability but nothing is wasted.
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 exists, and the description handily fills that gap by describing ordering and aggregate values; annotations carry the safety profile. The only material omission for a 3-parameter tool is the limit parameter's role and cap, so an agent may not realize how to control result size.
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?
At 67% schema coverage, molecule and strength are already documented in the schema, and the description's mention of composition and strength/form echoes them. The limit parameter is undocumented in both place and behavior — the description never explains that it caps the number of brands returned. Baseline 3 fits given partial coverage.
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 (every brand of one composition, priced per unit) plus the exact ordering and aggregates returned, which clearly separates it from get_brand (one brand) and search_medicines (lookup). An agent can decide between them without opening any 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?
Concrete trigger phrases ('cheapest <generic>', 'how much should <generic> cost') give a clear context for use. It stops short of naming the sibling tools or stating when-not to use it, so the routing is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Drug batches that Indian government laboratories declared not of standard quality (CDSCO monthly alerts): product, batch, manufacturer, what it failed on, and the laboratory. Search by product or manufacturer, and/or a month.
| Name | Required | Description | Default |
|---|---|---|---|
| month | No | optional alert month, YYYY-MM | |
| query | No | product or manufacturer, e.g. 'paracetamol' or 'Hind Pharma' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare this as a read-only, idempotent, non-destructive search. The description adds useful context about the authoritative source (CDSCO monthly alerts) and the fields included in the result, though it does not discuss pagination or result limits.
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 compact and front-loaded: it first defines the dataset and source, then explains how to search. Every clause contributes to understanding the tool without unnecessary 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?
For a simple two-parameter read-only search with no output schema, the description provides enough detail: source, scope, search options, and the key result fields. No essential calling information 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 parameter descriptions already define `month` as YYYY-MM and `query` as a product or manufacturer. The description reinforces that either or both may be used, but adds little beyond the schema itself.
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 resource and scope: drug batches declared not of standard quality by Indian government labs under CDSCO monthly alerts. It also lists the returned fields, making it unmistakable against unrelated siblings.
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 clearly states the available search dimensions: product or manufacturer and/or month. There are no overlapping sibling tools to exclude, but it does not spell out when not to use this tool or what to do if no results are found.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One Indian medicine brand: every pack with its MRP and price per unit as filed with NPPA, composition, whether it is price-controlled and its ceiling, and the cheapest other brands with the same composition and strength.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | Yes | brand name (e.g. 'Crocin Advance'), or its counterfoil.in page URL |
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 not burdened with safety disclosure. It adds useful behavioral context by specifying the underlying data source (NPPA filings), the inclusion of price-control ceilings, and the automatic return of cheaper equivalent brands. It does not cover error handling or pagination, but the core data behavior is well disclosed.
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 a single, front-loaded sentence that immediately establishes scope ('One Indian medicine brand') and then lists the returned data in a compact sequence. Every clause maps to a distinct output field or behavior, with 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?
With one parameter, no output schema, and rich annotations, the description carries the right load: it thoroughly enumerates what the tool returns, including the less obvious cheaper-equivalent lookup and NPPA price-control details. An agent has enough information to know what calling it will produce.
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?
There is a single required 'brand' parameter, and schema coverage is 100%—the schema itself explains that a brand name or a counterfoil.in URL is accepted. The description does not add parameter-level meaning beyond this, so the baseline 3 is appropriate.
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 the specific resource ('One Indian medicine brand') and enumerates exactly what is returned: packs, MRP, price per unit, NPPA filing, composition, price-control status, ceiling, and cheaper equivalents. It implicitly contrasts with 'search_medicines' through the singular 'One' brand scope, but does not explicitly name or differentiate from any sibling tool.
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?
Usage is only implied: an agent can infer this is for looking up a single known brand. There is no explicit 'use this when...' guidance, no exclusions, and no mention of when to prefer 'search_medicines' or 'compare_prices' instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Indian medicine brands, compositions (molecules) and companies by name in NPPA's price filings. Start here when you have a brand or generic name. Returns names, pack counts and counterfoil.in pages to cite.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | brand, generic name or company; three letters or more |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuine value beyond them: the data source (NPPA price filings) and the shape of the result (names, pack counts, counterfoil.in pages to cite), which matters since no output schema exists.
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 tight sentences with zero filler. The entry-point guidance is front-loaded, then results, then the citation source — each sentence carries distinct information.
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 usefully describes what comes back and where results come from. The one gap is the limit parameter and its hard cap of 10, which an agent must infer entirely from the schema.
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 50%: the query parameter is fully documented (brand/generic/company, three letters or more) in the schema itself, but the limit parameter has no description anywhere. The description adds only that matching is 'by name', which mildly clarifies query semantics but says nothing about the limit or its maximum of 10.
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?
Specific verb ('Find') plus three named resource types (brands, compositions/molecules, companies) scoped to NPPA's price filings. It also signals its role relative to siblings by saying 'Start here when you have a brand or generic name', which distinguishes it from get_brand/company_profile lookups.
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?
'Start here when you have a brand or generic name' gives a clear entry-point condition, and 'by name' rules out ID-based workflows. It stops short of explicitly naming alternatives like get_brand or compare_prices as the next step, so it's clear context but no explicit routing.
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.
above_ceilingcompany_profilecompare_pricesfailed_batchesget_brandsearch_medicinesUS drug price benchmarks — what a pharmacy PAYS and what Medicare PAYS OUT.
Free US drug-price benchmarks from federal data (CMS NADAC): a benchmark, not a price anyone owes.
CMS Medicare drug price negotiation: the Maximum Fair Price (MFP) for every drug CMS has selected…
FDA inspection outcomes, Form 483 observations, compliance actions and import refusals for drug…
Add one secure layer between your agents and this server.