Meridian Trace — Medical Device Registrations

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?

Discloses no API key requirement, the 3-result cap for anonymous callers, exclusion of consultants/representatives, and regional coverage strengths. Warns about caveats in the response, covering behavior beyond basic function.

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 relatively long with rhetorical emphasis and all-caps phrases, but each sentence delivers value about behavior, coverage, or usage. Slightly verbose but not padded.

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, but the description outlines response contents (distributors, importers, clinical areas, market counts, sample lines) and mentions caveats, giving a clear picture of what the caller will receive.

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 already covers all parameters; description adds examples for market (ISO2 or name), clarifies device_type with partial-match semantics, and explains limit default and cap. Enhances schema with practical usage details.

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?

Clearly states the tool finds distributors/importers for a market, explicitly contrasts with get_license_holders as the inverse, and frames the use case for companies entering a market.

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 identifies the inverse relationship with get_license_holders and provides the scenario (entering a market). Notes regional strength (Asia) and cautions to read caveats, offering concrete guidance on when and how to use.

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 present, the description carries the full behavioral disclosure burden. It does a decent job: it states that the tool runs without an API key, takes no arguments, returns the actual coverage data of what Meridian Trace holds, and emphasizes freshness/currentness. It doesn't describe failure modes or output formatting, but for a simple, safe, read-only query it provides meaningful behavioral transparency.

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 little wordy with promotional phrasing like 'call it right to check us before signing up for anything', but it front-loads the key behavioral fact (no API key) and then clearly lists the returned data. Most sentences earn their place; only slight redundancy prevents a 5.

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 description is complete enough for a tool with no parameters, no output schema, and no annotations. It explains the exact data it returns, address no-auth behavior, and provides concrete usage intent. An agent can successfully decide when to call it and what to expect from it.

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 are zero parameters, so the schema already fully describes the input surface. The description redundantly confirms 'No arguments', which is helpful but adds no new parameter information. With no parameters to document, the baseline score of 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 clearly states what the tool does: it returns the current coverage of Meridian Trace — every source registry, market, number of registrations, and last-crawl time. It is transparent about this being a no-argument query. However, it never distinguishes itself from the very similar sibling get_market_coverage, so an agent cannot fully separate the two based on purpose alone.

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 strong when-to-use guidance: 'call it right now' to verify coverage and freshness, 'before relying on other tools', and to answer questions like 'do you cover market X, and how current is it?'. It does not explicitly say when to use a sibling instead, such as get_market_coverage, so exclusion/routing is incomplete.

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?

Given that no annotations are present, the description carries the full burden of behavioral disclosure and largely succeeds. It explicitly outlines the `marketAccess` block's semantics, distinguishes it from a registration, and clarifies its exclusion from counts when Japan is involved ('both are true and the distinction matters'). The explanation is helpful, but slightly verbose; however, it does add crucial operational context beyond what structured data would capture. A slight deduction because the 'both are true' explanation, while clear, could be tightened.

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 effectively with the core value proposition, and the prose is mostly efficient. However, the marketAccess explanation rambles a bit, especially the clause about 'precedes product approval and outlives individual products', which, while informative, feels a bit tangential. The description could be tightened by about 20% without loss of 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?

For a tool with no annotations and no output schema, the description does a strong job of clarifying return semantics (per-market counts, source registries, absent markets list). It clearly handles the common edge case of the `marketAccess` block. It doesn't describe the response header or pagination, but for a tool of this nature, the description provides enough context for an agent to use it correctly. A small deduction for not explicitly stating that the absence of all three parameters returns an error or a full list, although it's implied.

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%, covering all three parameters, so the baseline is a 3. The description reiterates the 'use exactly one of' pattern implicitly by calling it 'THE cross-market question', but doesn't add new semantics beyond the schema. Indeed, the parameters are straightforward aliases for manufacturer identification, so the description need not add more. Meets the baseline.

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?

Clearly identifies the tool's purpose: answering a cross-market question with a specific verb and scope ('every market where this manufacturer IS registered and every market where they are NOT'). The description efficiently differentiates it from the sibling get_registrations by mentioning 'Prefer this over get_registrations...' It also provides a concrete example ('registered in Indonesia and Thailand, missing in the Philippines') to clarify the intended use case.

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 directs when to use this tool over a sibling: 'Prefer this over get_registrations when the question is about market presence rather than individual products.' It also gives a clear exclusion condition ('a marketAccess block... is NOT a registration') and provides a cautionary note for a specific edge case. Very actionable.

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?

Since no annotations are provided, the description carries full responsibility. It discloses ordering (by first-seen date), exclusions (US PMA supplements), and performance characteristics (filtering speed), which are significant behavioral details that inform the caller's expectations.

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 four sentences, front-loaded with the main purpose and filters, then logically adding ordering, exclusions, and performance notes. It uses em dashes effectively and contains no fluff, making it 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?

Given the absence of an output schema, the description adequately covers the essential aspects: purpose, filters, ordering, exclusions, and performance. It does not mention pagination or error scenarios, but these are not critical given the tool's simplicity and the presence of parameter constraints in 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?

The schema descriptions cover 100% of parameters, providing a baseline of 3. The description adds context by clarifying that market, risk class, and device type are optional filters, and highlights the performance impact of filtering by market, which slightly enhances understanding beyond the schema alone.

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: retrieving recently added registrations in Meridian, with optional filters. It distinguishes itself as a competitor-monitoring feed, explicitly excluding US PMA supplements and ordering by first-seen date, which sets it apart from other listing tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for competitor monitoring and notes performance differences when filtering by market, giving practical guidance. However, it does not explicitly contrast with sibling tools like search_manufacturer or get_registrations, so the 'when-to-use' aspect is partially 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 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?

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.