materials

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

Annotations already declare read-only, idempotent, non-destructive and closed-world, so the baseline bar is lower. The description still adds real behavior: values are normalized into the property's canonical unit and mismatched measurement conditions are never averaged, which materially affects how an agent interprets results.

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, front-loaded with what the tool produces, then the canonical-unit guarantee, then the non-averaging caveat. No sentence repeats the schema or the title.

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 carries the return-shape burden and does so: per-material value, conditions and source, plus value_canonical. What's left unsaid — ordering, behavior for unknown properties or properties lacking canonical units — is minor for a read-only comparison tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with both parameters documented (including an example property and 'Ids from search_materials' with 2–12 bounds). The description adds no parameter-level detail beyond implying 'property' is singular and 'materials' plural; 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 gives a concrete verb and scope: it lines up several materials on a single property and returns each value with conditions and source. That clearly distinguishes it from single-material siblings like get_material, though no sibling is named explicitly.

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

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

Usage is implied by 'line several materials up on one property' — a multi-material, single-property read — but there is no explicit when-to-use vs. when-to-use-an-alternative guidance. The note that differently-conditioned values are listed separately rather than averaged is useful expectation-setting rather than routing 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?

Goes well beyond the readOnly/idempotent annotations: it defines the three verdicts, the evidence-strength ladder, the default result ordering and filtering, and the temperature-matching rule that silently excludes values. The exclusion of zero-data materials with a pointer to what_is_missing is exactly the kind of hidden behavior an agent needs 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?

Front-loads the essence in four words, then layers the verdict model, defaults, context knobs, and the exclusion rule in tight order. Dense but every clause carries information; nothing is repeated from the schema verbatim.

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, yet the description fully describes the return shape (per-material verdicts, per-constraint status, evidence level) and the default ordering. For a nested-parameter tool with a nontrivial result model, an agent has everything needed to call and interpret 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?

Schema coverage is 100%, so the baseline is 3, and the description earns above that by framing context as "narrows which values count" and spelling out the at_temperature and flown_only exclusion semantics. It says nothing about the constraint object's operator, unit conversion, or value2 fields, leaving those entirely to the schema.

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?

"Requirements in, candidates out" plus the verdict model states a specific verb and resource that is clearly distinct from search_materials or get_material. The description also scopes what counts as a candidate (no materials with zero data), which an agent could not infer from the name 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?

Explicitly states the default filter (passes and unknowns only, passes first) and routes the coverage question to what_is_missing. It does not, however, name search_materials as the alternative for name/keyword lookup, which is the most likely sibling confusion for a tool called "find".

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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so safety is covered. The description adds real value beyond that by disclosing what the record contains — sourced numbers plus their conditions, method and source location — which tells the agent this is provenance-carrying data, not bare values.

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 dense sentences with no filler; the core record contents are front-loaded and the narrowing option is placed last as a secondary note. Slightly list-heavy but every item earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description carries the burden of describing the return shape, and it does so adequately by naming the record's sections. It stops short of explaining how 'include_facts' interacts with 'topic'/'property' filtering or what an empty result looks like.

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 all four parameters are already documented in the schema, including the example id and the topic enum. The description adds modest framing by treating 'property' and 'fact topic' as two separate narrowing axes, but no syntax or interplay detail beyond the schema.

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 resource ('the sourced record of one material') and enumerates the content it returns (sourced numbers with conditions, method, source location, uses, hazards, failure modes, corrosion, supply). Retrieval-vs-search is distinguishable from siblings like search_materials/find_materials, though the description never names a sibling explicitly.

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

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

Usage is implied rather than stated: the id is 'from search_materials' and the record can optionally be narrowed. There is no explicit when-to-use-this-vs-another-tool guidance (e.g., when to use get_material vs compare or list_claims for the same facts).

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?

Annotations already declare readOnly, idempotent, non-destructive and openWorld=false, so the safety profile is covered. The description adds the domain restriction (terms appearing on material pages) and hints at return content, but says nothing about behavior for unknown terms or how lookups are matched.

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 tight sentence with the core purpose front-loaded and examples at the end where they aid recognition. Slight awkwardness in the mid-sentence qualifier 'used on material pages' but no wasted content.

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 single-parameter read-only lookup with no output schema, the description does state the shape of the return value ('plain-language definition'). Only edge-case behavior (term not found, ambiguity between expansions) is left unstated.

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?

With 100% schema description coverage and a single required parameter, the schema already documents the input fully, including the same ARC/SoC/adiabatic examples. The description adds no format or matching guidance beyond what the schema provides, 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?

States a concrete outcome — a plain-language definition of a technical term or abbreviation — and scopes it to material pages with examples (ARC, SoC, adiabatic). It is distinguishable from get_material and list_properties, though the overlap with resolve_designation is not addressed.

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 by the resource type; there is no explicit 'use this when…' or routing against siblings like resolve_designation, which a reader could easily confuse with a term lookup. No exclusions or prerequisites are given.

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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: results are 'current' values in canonical units, each carrying an evidence level and a claim_id, and it explains the follow-up path via prove_claim.

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 tight sentences, front-loaded with what is returned, followed by the actionable next step. 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 no output schema, the description does the work of naming the return fields (value, canonical units, evidence level, claim_id), which is sufficient to call and interpret the tool. Minor gap: no mention of result volume or ordering for a material with many claims.

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 both parameters are documented in the schema with examples (peek, density). The description only restates that property is optional and that values are canonical; it adds no syntax or format detail beyond the schema, 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?

States a specific verb and resource ('Every current sourced value for one material') plus scope (optionally one property, canonical units) and the returned fields. It is clearly distinguishable from get_material and compare, which do not enumerate sourced values with evidence levels.

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 routes the agent onward: 'Use the claim_id with prove_claim to see the exact source and passage,' naming the sibling and the condition. It does not state when to prefer get_material or compare instead, so it stops short of full when/when-not 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?

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior. The description adds useful context about what the listing contains: property names, canonical units, and sort direction. It does not discuss pagination or exact return shape, but with annotations covering safety the bar is lower.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the returned data and then the intended downstream use. No filler; every clause adds useful 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-only catalog with no output schema, the description gives enough return-value context to call it correctly. The optional query filter is left to the schema, which is acceptable given 100% schema coverage. Only minor details about exact result format are omitted.

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%, including documentation for the optional query filter, so parameter meaning is already fully provided by the schema. The description never mentions the query filter or its behavior, adding no parameter information beyond the schema. 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 identifies the resource (property names) and the metadata returned (canonical unit, whether higher or lower is better), making it clear this is a property catalog rather than a material search. It also points to get_material and compare, helping distinguish it from those siblings. It lacks an explicit verb like "list," but the purpose is still clear.

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 agent to use the returned names with get_material and compare, establishing the intended downstream workflow. It does not state when not to use this tool or name an alternative listing tool, so it falls short of a 5.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety and repeatability are covered. The description's contribution is enumerating the returned payload (printed form, conversion, evidence level, conditions, source locations/passages), which is genuinely useful given there is no output schema, but it is phrased loosely and omits behavior for an unknown or unprovable claim_id.

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?

It is a single sentence, which is efficient, but the front-load ('Everything behind one value') is vague and the trailing list — especially '(and the passage where we have it)' — is hard to parse. Compactness is achieved at the cost of readability.

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 does attempt to sketch the return payload, which is the right instinct for a provenance-lookup tool. It remains too imprecise to tell an agent what fields to expect or how failures (missing claim, no evidence) manifest, so it is adequate rather than complete.

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 claim_id is documented as coming from list_claims, so the schema carries the semantics. The description adds nothing about the identifier, 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 conveys that the tool surfaces all provenance behind a single claim/value (source form, converted form, evidence level, conditions, sources), which is a recognizable purpose. But it never uses a verb like 'retrieve' or 'return' and never names what a 'value'/'claim' is relative to siblings such as list_claims or get_material. An agent can infer the intent, but only after reading the whole list.

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?

There is no statement of when to call this versus compare, get_material, or list_claims, and no prerequisites or exclusions. The only implicit cue is that a claim_id comes from list_claims, which appears in the schema rather than the description.

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?

Annotations only cover the safe-read profile (readOnly, idempotent, non-destructive), and the description adds substantial behavior on top: matching is case/space/hyphen insensitive, short codes trigger prefix expansion, specifications such as ASTM A240 fan out to every citing material, and each row carries a note plus an exactness flag. It also warns that a "nearest equivalent" note is the source's own hedge and should not be treated as grade equivalence — a genuinely non-obvious behavioral caveat.

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?

Purpose is front-loaded in the first sentence, and every subsequent sentence carries a distinct, load-bearing fact (input tolerance, row shape, spec fan-out, equivalence caveat). The enumeration of code systems is dense but not redundant, keeping it just short of 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?

With no output schema and a single parameter, the description carries the return-value burden and does so fully: it names the four row fields (system, code, note, exact flag) and explains the two non-obvious cardinality cases (prefix expansion and specification-driven multi-material results). Nothing an agent needs to call this correctly or interpret the result 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% and the single `code` parameter is already documented with examples, so the baseline is 3. The description adds meaning beyond the schema by listing the full set of accepted governing systems and by specifying the normalization rules (case, spaces, hyphens ignored) and the 60-char scale implied by prefix matching.

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?

Opens with a precise framing ("Which material a code names") and enumerates exactly which identifier systems it accepts, with concrete examples. An agent can tell this is a designation-to-material resolver rather than a keyword search, though it never names the sibling tools (search_materials, find_materials) it sits beside.

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 context is implied through the accepted input forms (UNS, EN, DIN, JIS, AISI/SAE, ASTM/AMS, trade names) and the note that a short code lists codes that start with it, which tells an agent when the tool fits. However, there is no explicit when-not-use rule or pointer to alternatives such as search_materials or get_material for follow-up.

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?

Annotations already establish read-only, idempotent, closed-world, non-destructive behavior, so safety is covered. The description adds that results are ids intended for get_material, which is useful context, but it doesn't disclose match semantics (prefix vs substring, ranking, ranking fallback when no matches) or pagination beyond the schema's limit.

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 tight sentences, front-loaded with the core action and followed by the optional filter and the hand-off note. 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 small read-only search tool with full schema coverage and no output schema, the description covers what searchable fields exist, the optional filter, and where the returned ids lead. The main omission is any statement of matching behavior or how to distinguish it from find_materials.

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 all three parameters are already documented with examples and bounds. The description's examples for category ('polymers, metals, energy') echo the schema, and its mention of searchable fields adds little beyond the query parameter's own description. 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?

States a specific verb and resource ('Find materials') with the searchable fields named (name, abbreviation, formula) and the optional category filter. It distinguishes the tool's purpose, but it does not differentiate it from the sibling find_materials, whose name suggests overlapping functionality.

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 this is a discovery tool and hints at a follow-up path ('Returns ids to use with get_material'), which is mild usage guidance. However, it gives no explicit when-to-use vs when-not, and says nothing about find_materials, the sibling most likely to be confused with it.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description earns credit for disclosing the partial-index state ('passages are still being added') and what an empty result means — a real behavioral caveat an agent would otherwise misread as 'no such content exists'. It also summarizes the return payload 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 short sentences, front-loaded with what the tool does and what it returns, then the caveat. No filler or repetition of the schema.

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 two-parameter read tool with no output schema, the description covers purpose, return shape, and the index-maturity caveat. The only gap is result ordering/relevance ranking, which an agent might reasonably want to know.

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% — both 'query' and 'limit' carry their own descriptions including the 1–20 bound and default of 5. The description adds nothing parameter-specific, so the 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?

Names a specific operation ('full-text search') on a specific resource ('short passages quoted from our sources') and states what comes back: the passage, its source, and the place in it. It is distinguishable from search_materials by the 'quoted passages' framing, though it never names the sibling outright.

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?

There is no when-to-use or when-not-to-use guidance, and no alternative is named despite search_materials and find_materials sitting right beside it. The note about empty answers is about result interpretation, not about tool selection.

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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description still adds real interpretive value by defining 'no_data' as not-yet-covered rather than known-safe, which prevents a dangerous misreading of empty results. It stops short of describing the response shape or how 'strongest evidence' is ranked.

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 tight sentences, with the core capability front-loaded and the 'no_data' caveat immediately after. No padding or restatement of the title.

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 carries the burden of explaining returns, and it does so at a useful level: per-property presence/absence plus strongest evidence. It never specifies the exact field layout or how ties in evidence are resolved, a minor gap for a two-parameter read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both 'material' and 'properties' are documented in the schema, including their originating tools (search_materials, list_properties) and the 40-item cap. The description adds only the framing of 'one material and a list of properties', 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 gives a specific verb-and-resource: for one material plus a property list it reports which properties have sourced data (with strongest evidence) and which have none. That is much clearer than the vague name 'what_is_missing'. It does not, however, explicitly contrast itself with siblings like get_material, whose output presumably overlaps.

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: it's a coverage probe run before or instead of fetching data for a material. There is no explicit statement of when to choose it over get_material or compare, and no prerequisites mentioned beyond the parameter descriptions.

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