Meridian Trace — Medical Device Registrations

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations the description carries the full burden, and it does disclose real behavioral constraints: an API key is required and only the filing key (or another key on the same account) can read the report. It also enumerates the possible states and the 'Already reported' case with repeated reference. Missing only rate limits/error behavior.

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 but front-loaded sentence that leads with what is returned, then the state list, then the permission caveat. No filler, though the parenthetical and nested clauses make it slightly harder to scan than a clean multi-sentence version.

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, so the description compensates by enumerating the return states and noting the reply field, plus auth requirements. That is sufficient for a single-parameter read tool; only edge cases like missing/invalid references are left unaddressed.

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 already documents the MT-1042 format, so the schema does the heavy lifting. The description adds only the indirect hint that the ref is the same reference report_data_issue returned, which is useful linkage but not new format detail.

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+resource (check the status of a filed issue) and names the sibling tool that creates the report (report_data_issue), so an agent can tell the pair apart without opening either schema. It even enumerates the possible status values, which no other sibling covers.

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?

Clearly frames the usage context: this is the follow-up to report_data_issue, using the reference that tool returned. It does not explicitly state when *not* to use it or name a competing status-lookup path, but no such alternative exists among the siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries the full transparency burden and does it well: it discloses API-key gating, the subset of results anonymous callers see, risk-class non-portability across markets, the observed-practice caveat, and count-based name resolution. These are behavioral traits a caller could not infer from the schema alone.

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 long but dense, with every sentence carrying distinct value and the most operationally urgent fact about API-key access front-loaded. It could be broken into clearer sections for scannability, but there is no filler or 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 tool with no output schema and no annotations, the description covers the main returned elements (resolution, product codes, risk table, sample sizes), the key caveats, and the accepted input forms. The notable gap is that all parameters are optional in the schema while the description never explicitly states that exactly one of the three inputs should be supplied.

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 input schema already documents all three parameters, but the description adds substantial meaning: naming conventions, US/UK spelling resolution, no-brand/no-use guidance, how ambiguous names are resolved and reported, and the suggested follow-up call with gmdn_code. This goes well beyond the schema's example values.

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 verb and resource: it gives a classification view of a device type, enumerating the GMDN hierarchy, FDA product-code mappings with counts, and per-market risk classes with sample sizes. This is specific enough to distinguish the tool from all sibling tools without requiring additional schema inspection.

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 tells the caller exactly what inputs are acceptable (a plain device name, GMDN code, or FDA product code) and how to phrase device_type, including avoiding brand names or use descriptions. It also explains how to follow up on ambiguous resolution via gmdn_code, but it does not explicitly name sibling tools or state when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 anonymous rate/limit behavior ('anonymous callers see the top 3 per market'), the two-count model with exact field names ('matching', 'matchingLicenceOrTenderOnly'), the 'basis' marker, ranking behavior, and a caveat about reading 'caveats' before quoting numbers. This is rich behavioral context beyond the schema.

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 long and front-loaded with a parenthetical about API keys, but many sentences are necessary for the complex behavior. However, some redundancy exists (e.g., repeating the two-count explanation already in the schema) and the density could be improved. It is not overly concise but serves a complex tool.

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 no annotations and no output schema, the description provides all necessary context: anonymous limits, the two-count model with field names, ranking, exclusions, geographic strengths, and a pointer to caveats. An agent has enough information to call this correctly and interpret results.

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 schema already documents all parameters. The description adds value by explaining the two-count distinction and the holder_basis option in narrative form, which reinforces the schema and clarifies semantics. It does not add much beyond that, but the schema is comprehensive, so a 4 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 a specific verb and resource ('WHO COULD SELL A DEVICE IN A MARKET ... returns the local distributors and importers who hold registrations there') and explicitly distinguishes it from the sibling get_license_holders ('This is the INVERSE of get_license_holders'). An agent can tell exactly what this tool does and how it differs from its closest sibling.

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 explicit: 'Give it a market and, optionally, a device type or clinical area'. It contrasts with get_license_holders ('which starts from a manufacturer you can already name'). It also explains exclusions (regulatory consultants, authorised reps, manufacturers' subsidiaries) and the two-count logic, including when to pass holder_basis 'licence_or_tender_only'. This is unusually detailed guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It transparently discloses the data source (predicates cited in each clearance's own summary), the time/number range (64,567 clearances, 1992-2026), and the exact output for both k_number (forward and reverse citations) and product_code (ranked predicates and recent clearances). It does not mention pagination or error behavior, but the data source and direction of results are well disclosed, adding significant context beyond what a generic query tool would provide.

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 information-dense yet efficiently structured. It opens with a clear one-line definition, then elaborates on the two query modes in separate clauses, and closes with use cases. Every sentence adds value, and there is no fluff or repetition. The structure is easy to scan and parse.

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?

Since there is no output schema, the description adequately explains what the tool returns for each parameter mode: k_number yields cited predicates and reverse citations, while product_code yields ranked predicates and recent clearances. It also mentions the limit parameter controls row count. Given the tool's complexity and the absence of an output schema, this description is comprehensive enough for the agent to know what to expect and how to use the tool effectively.

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?

Although schema coverage is 100%, the description adds substantial semantic meaning to each parameter. For k_number, it explains both forward ('what that device cited') and reverse ('which later devices cited IT') lineage. For product_code, it describes the output as 'predicates that code leans on most, ranked by how often they are cited, plus recent clearances.' This goes far beyond the schema's simple labels and gives the agent a clear understanding of what each parameter does and what results to expect.

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 states the tool's purpose: 'US 510(k) predicate lineage' with specific details about the data source (actual citations from summaries) and the two query modes (by k_number and by product_code). It explicitly distinguishes from similarity-based tools by noting it's 'not a similarity guess' and describes the reverse direction of citations, which clearly sets it apart from sibling tools like find_similar_devices.

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 explicit use cases: 'Use when choosing a predicate, assessing substantial equivalence, or mapping who is clearing devices in a classification.' It implicitly contrasts with similarity tools by stating it's based on actual citations, but does not name specific alternatives or state when not to use it. This is clear guidance but could be stronger with explicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 key behaviors: matching on GMDN, excluding the same manufacturer, spreading results across markets, and each result carrying a match band. It does not mention rate limits or auth, but given the tool's nature, these disclosures are quite informative for agent selection.

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. Three sentences cover purpose, exclusions, use cases, and prerequisite. No wasted words.

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 tool is moderately complex with 4 optional parameters and no output schema. The description explains the matching methodology, what results to expect (competitive set, match band), and typical use cases. It could mention edge cases (e.g., no results if no matching GMDN), but the core behavior is well covered.

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% with parameter descriptions, so baseline is 3. The description adds notable value by explaining the relationship between device_name and registration_id (device_name is an alternative that finds the closest registration), and clarifies that market is used to restrict the reference lookup. This goes beyond the schema's brief 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 clearly states the tool's purpose: finding competing and comparable devices for a registration, matched on GMDN type rather than product-name text. It distinguishes itself from siblings by specifying the matching basis (GMDN) and the competitive set nature (excludes same manufacturer, spreads across markets).

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 explicitly guides when to use this tool: for competitive landscape, classification precedent in other markets, and understanding how a device type is described elsewhere. It also contrasts with alternatives by noting it matches on GMDN rather than product-name text, and mentions getting a registration_id from get_registrations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does meaningful work: it discloses that the tool runs without an API key, that it requires no arguments, and that it returns freshness metadata. It stops short of explicitly declaring the operation read-only/side-effect-free, but the nature of the tool makes that low-risk.

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 highest-value fact ('RUNS WITHOUT AN API KEY') and then scoped tightly. Slightly promotional in tone, but every sentence carries information and 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?

For a zero-argument read tool with no output schema, the description covers inputs, return contents, and motivation, which is nearly complete. The one unresolved item is the relationship to the very similarly named sibling get_market_coverage.

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?

Zero parameters, which sets the baseline at 4. The description reinforces this with 'No arguments,' so there is nothing left for an agent to guess about invocation.

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 ('get coverage') and enumerates exactly what the payload contains: every source registry, its market, registration counts, and last-updated timestamp. However, it never distinguishes itself from the sibling get_market_coverage, whose name is nearly identical, leaving real ambiguity about which one 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 implied usage ('call this to verify coverage and freshness for yourself before relying on other tools') and an example question it answers, which is better than nothing. But there is no when-not guidance and no explicit routing against get_market_coverage, the most likely alternative an agent would consider.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses important behavioral context about regional data semantics (local party vs. OEM) and the insights derivable from the output, but it does not address response shape, error behavior, pagination, or any access prerequisites. Given the simple read-only nature of the tool, this is adequate but not comprehensive.

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 sentences, front-loaded with the core definition of the output and followed by a purposeful explanation of regional importance and use cases. Every clause adds value—no filler or redundant repetition of the tool name.

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 the tool has one parameter, no output schema, and no annotations, the description provides adequate context for selecting the tool but not full detail on the return structure. It explains the type of entities returned and the geographic nuance, but an agent invoking it would not know the exact fields per license holder. The description is sufficient for selection, only partially for 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?

The schema provides no description for manufacturer_id (0% coverage), so the description must compensate. The description indirectly defines the parameter by referring to 'a foreign manufacturer's registrations', implying manufacturer_id identifies that manufacturer. However, it does not specify the ID format, source of the ID, or any constraints beyond the schema's required flag, which is only a partial compensation.

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 identifies the tool's output—local entities (importers, distributors, regulatory consultants) that hold a foreign manufacturer's registrations. It explicitly distinguishes this tool from siblings by explaining that in Malaysia, Indonesia and Thailand the registry names local parties rather than the OEM, and positions this as 'the only way' to see market access control and partnerships.

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 states when to use the tool: when you need to know who controls market access, who a competitor is partnered with, or whether a manufacturer uses one or many local partners. It implies that other registration tools return OEM-level data and therefore should not be used for this local-entity insight, but it does not explicitly name alternative tools or provide exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden and does so thoroughly: it explains that marketAccess is excluded from marketCount and every count, that PMDA accreditation does not mean Japanese registration, and that notJudged markets such as Chile must not be reported as 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?

The answer is front-loaded with the core purpose, then layered with important caveats. It is longer than typical but most sentences carry interpretive value; some phrasing around marketAccess and notJudged could be tightened without losing meaning.

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 is provided, so the description must explain the response shape and does: per-market counts, source registries, absent markets, marketAccess, and notJudged. An agent has enough context to call and interpret the tool 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 description coverage is 100%, so the schema already documents all three parameters and their alternatives. The description adds no parameter-level meaning beyond what is in the schema, so 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?

States a specific verb-and-resource outcome: every market where a manufacturer is registered and every market where it is not, with per-market counts and source registries. It explicitly distinguishes itself from get_registrations by framing the scope as market presence rather than individual products.

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 routing guidance: prefer this over get_registrations when the question is about market presence rather than individual products. It also explains how to treat the marketAccess and notJudged blocks, which prevents common interpretive misuse.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so well: it discloses sort semantics, exclusion rules for PMA supplements and bulk loads, and the latency profile. It stops short of covering what happens when limit truncates results or whether there is pagination, which is the remaining behavioral 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 purpose and scope, and every sentence carries actionable content — exclusions, meta reporting, and performance. It is dense and the final sentence runs long, but nothing is padding.

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?

There is no output schema, so the description must explain the return shape, and it does: ordering, the meta.basis.bulkLoadsExcluded field, and the instruction to repeat meta.basis.note rather than claim completeness. That is exactly the guidance an agent needs to report results honestly.

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 is 3, but the description adds real meaning on top: it explains that `markets` filtering has a large performance payoff and that `days` is defined by first-seen date rather than approval date. `risk_level` and `device_type` gain no extra context beyond their schema enums.

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+resource ('Registrations newly added to Meridian in the last N days') with the competitor-monitoring framing, which distinguishes it from the broader get_registrations sibling. The ordering rule ('by when we first saw the record, not approval date') further pins down what the tool actually returns.

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?

Explicitly says what is out of scope (US PMA supplements, bulk-loaded records) and why, and names the meta fields that report the exclusions. It also gives a concrete selection rule for the markets filter: unfiltered is ~15s, one or two markets ~1s.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden and does well: it discloses that reading one device costs the same as a list read, that re-reading is free, and that sourceUrl points to the authority's own record for verification. It does not mention error behavior or rate limits, but for a simple getter this is reasonably transparent.

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 is information-dense rather than padded. The enumeration of market-specific fields is long but earns its place by clarifying exactly what richer data is available. It could be trimmed, but every sentence contributes.

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 only one parameter, no output schema, and no annotations, the description covers the return payload meaningfully—list fields, registryFields, and sourceUrl—and adds cost semantics. It does not explain what happens on invalid IDs, but the parameter provenance and high schema coverage make this adequate for a single-record getter.

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 registration_id is already documented in the schema with its provenance from get_registrations, find_similar_devices, or get_recent_registrations. The description adds little parameter-level meaning beyond referring to 'that row,' so the baseline of 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 title and opening 'One registration, complete' state a specific verb and resource, and the description explicitly contrasts with get_registrations by saying it returns everything from the list row plus registry-specific fields. This clearly distinguishes it from sibling tools like get_registration_timeline and get_recent_registrations.

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 makes it clear this is the exhaustive single-record counterpart to list operations, mentioning fields that 'fit a list row' versus full detail. It implies when to use it, though it does not explicitly name alternative tools or state when not to use it. The context is strong but exclusions are left implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and it delivers a detailed trust model: it discloses an enrichment block of Meridian-derived fields, a provenance block naming derived fields with confidence bands, and explicitly states that any field not listed is the registry's own unmodified value. This directly informs the agent's reasoning about data reliability.

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 longer than average but every sentence earns its place: core row content, enrichment behavior, provenance model, usage guidance, and sibling routing are separated into clear blocks. It is front-loaded with the resource definition; the long first sentence is dense but not wasteful.

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 five-parameter tool with no output schema or annotations, the description supplies most needed output semantics: row fields, enrichment/provenance blocks, confidence bands, and filtering. It could be more complete about ordering, pagination beyond the schema, or distinction from get_recent_registrations, but the essential selection and invocation information is present.

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 80%, so the high-coverage baseline applies; page, limit, market, and status are already documented in the schema. The description only reinforces that results are filterable by market and status, while required manufacturer_id is un-described but made inferable by 'held by a manufacturer.' No additional parameter syntax or constraints are added.

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 opening clause identifies a specific resource ('Every individual registration held by a manufacturer') and enumerates the key fields returned, making the tool's scope concrete. The closing sentence names get_market_coverage as the tool for a different question, so the agent can distinguish this tool from 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?

The description gives an explicit when-not rule: 'Use get_market_coverage instead when the question is which markets a company is in.' It also gives usage context via filterable by market and status and actionable guidance about leaning on verbatim fields and hedging on derived ones.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 well by explaining the data provenance (registry approval dates), the historyQuality flag with detailed meanings, and the caveat that current_state_only markets undercount withdrawn products. This goes beyond a simple 'get' and informs the agent about data quality and interpretation.

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 three sentences long and packs a lot of information: the metric, data provenance, data-quality caveats, and use cases. Each sentence contributes meaning without fluff, though the density may require careful reading. It is concise but not minimal.

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 6-parameter tool with no output schema, the description covers the core concept, historical depth, the historyQuality flag, and intended analytical use cases. It does not detail the return format or multi-competitor comparison mechanics, but it provides enough context for an agent to understand what the tool offers and its limitations.

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?

All 6 parameters already have schema descriptions, so the baseline is 3. The description does not add parameter-specific guidance, such as the relationship between name, ticker, and manufacturer_id, but it does add context about the output's historyQuality flag, which relates to how the data is generated.

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's output as new registrations per year by market, and distinguishes it from siblings by noting it is built from registry approval dates and reaches back as far as 56 years. Although it lacks an explicit verb like 'returns', the noun phrase is specific and unambiguous about the resource and metric.

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 explicitly states 'Use for entry velocity, launch cadence, and comparing two competitors' expansion over time,' which gives clear context for when to select this tool. It does not name alternative tools or exclusions, but the use cases are sufficient for an agent to differentiate it from a generic listings tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 Meridian manually checks every report, nothing changes until verified, a reference like MT-1042 is returned for later use, an API key is required, and there is a 50 reports/day cap. These are exactly the behavioral traits an agent needs.

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-loads the core action and required data, but is a single long sentence with multiple clauses. Information density is high and every sentence earns its place, though the structure could be tightened with paragraph breaks or bullets.

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 10-parameter mutation-like reporting tool with no annotations and no output schema, the description covers purpose, when-to-use, required inputs, data sources for reference IDs, return value (reference like MT-1042), follow-up usage (check_issue), auth, rate limit, and the manual-review process. Nothing essential 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 is 3. The description goes beyond the schema by explaining how to name a record (registration_id from get_registration/get_registrations, or manufacturer_id, or registry_key such as 'TH_FDA:64-2-1-2-0001234') and that source_quote must be verbatim. It adds practical meaning to several parameters, though not every field is elaborated.

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+resource ('Tell Meridian that a record... looks WRONG') and the exact record types and fields that can be reported. Clearly distinguished from siblings like check_issue, get_registration, and find_predicates, which handle retrieval or follow-up rather than reporting.

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?

Explicitly says when to use it ('wrong data, not for questions about what a field means') and when not to, and names check_issue as the downstream tool that consumes the returned reference. It also states required inputs (what, where) and constraints (API key, 50/day).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses key behaviors: name unification across scripts, subsidiary resolution, and returning up to 5 candidates with confidence and market footprint. However, it does not explicitly state that the tool is read-only or mention any authorization requirements, though as a search tool this is implied. The description adds substantial behavioral context beyond what the name alone suggests.

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 sentences, front-loaded with the core purpose, and every sentence adds value: the first defines what it does and its primacy, the second explains unique behavior and output format. There is no fluff or repetition, making it highly concise and well-structured.

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 2 parameters and no output schema, the description covers the essential context: it explains the core function, the normalization behavior, the return format (up to 5 candidates with confidence and footprint), and contrasts with a generic web search. This is sufficient for an agent to understand when and how to use it, especially given the high schema coverage.

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 input schema covers both parameters (name, country) with clear descriptions, yielding 100% coverage. The description adds meaning to the 'name' parameter by explaining that it supports spelling variants and scripts, which is not in the schema. It does not add detail to 'country', but the schema already explains its usage. This goes beyond the baseline 3 for high schema 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?

The description clearly states the tool resolves a company name to a Meridian manufacturer entity and positions it as the entry point for all other tools, distinguishing it from siblings like classify_device or get_registrations that focus on other aspects. The verb 'resolve' plus the resource (manufacturer entity) makes the purpose specific and 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?

It explicitly says it is 'the entry point for every other tool,' signaling when to use it first. It also contrasts with a plain web search by explaining that a web search cannot unify names across scripts, providing a clear when-not scenario and rationale for using this tool instead of generic search.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.