SkoIA Parts

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the baseline burden is lower. The description adds useful behavioral context: generation is restricted to verified/accepted plans, and STEP is currently not supported. There is no contradiction with the annotations; the word 'generates' can reasonably refer to deterministic, read-only artifact generation.

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

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

The description is a single compact sentence with no filler, and the core constraint is front-loaded. The unexplained capitalized terms reduce clarity slightly, so it is not a perfect 5, but it is appropriately concise.

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 output schema and annotations present, safety and return behavior are largely covered, and the precondition is helpful. However, the description lacks parameter semantics, does not name alternatives among the many sibling tools, and leaves 'LIVE' and 'STEP' unexplained, so an agent still has meaningful gaps to resolve.

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

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

Schema description coverage is 0%, so the description needed to compensate, but it does not explain solutionId, format, or entitlement. It only gestures at 'formats' generically, leaving the agent to infer parameter meaning from enum names and property schema. That is insufficient for low-coverage schemas.

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 uses a specific verb ('Generates') and the title supplies the resource ('artifact'), while the text scopes the operation to 'LIVE deterministic formats' and 'after plan acceptance and verification.' It also excludes STEP, which distinguishes the tool from a general generate action, though 'LIVE' and 'deterministic formats' remain jargon-heavy and not fully explicit.

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 precondition ('after plan acceptance and verification') and a clear when-not ('STEP remains unavailable'), and the word 'only' narrows the tool's applicability. It does not explicitly name sibling tools or alternative routing, which keeps it just short of the top level.

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=true and idempotentHint=true, so the safety profile is covered. The description adds useful behavioral context: it explores candidate transformations, focuses on the same PhysicalProblem, and labels only unverified candidates as HYPOTHESIS. The word 'labels' could be slightly ambiguous, but it is consistent with read-only exploration if interpreted as labeling in the returned output rather than persisting state.

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

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

The description is a single, tightly worded sentence that front-loads the core behavior and outcome. There is no redundant filler or repetition of the tool name or 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?

Given the one parameter with zero schema coverage and the need to distinguish among many sibling tools, the description leaves important gaps: it does not explain the input parameter, usage conditions, or how this step relates to verification and synthesis. The output schema exists, so return values need not be detailed, but the input semantics and invocation context are insufficient.

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

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

Schema description coverage is 0%, so the description must explain what the single 'description' parameter means, but it never mentions it. An agent would not know whether 'description' refers to a problem statement, a hypothesis description, or some other input. The description says 'from the same PhysicalProblem' but does not connect that to the parameter.

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 action ('explores candidate transformations') and a clear outcome ('labels every unverified candidate as HYPOTHESIS'), tied to the same PhysicalProblem. It is clear about the tool's role, though it does not explicitly contrast with sibling tools such as verify_solution or synthesize_physical_solution.

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

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

No explicit guidance is given about when to use this tool versus alternatives like verify_solution, resolve_problem, or synthesize_physical_solution. The description implies an exploratory hypothesis-generation step, but it does not state prerequisites, follow-up steps, or situations where another tool should be chosen instead.

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, and non-destructive behavior. The description adds meaningful behavioral context beyond annotations: the tool reports direct compatibility only on a verified interface match, and it operates on canonical ProductTwins, not arbitrary products. No contradiction with annotations.

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

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

Two short sentences with no wasted words; the core action is front-loaded and the qualifying condition follows immediately. Every clause 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?

For a simple two-required-parameter comparison tool with safety annotations and an output schema, the description is largely sufficient. It lacks only a brief pointer to sibling tools or a note about non-match behavior, but those are not essential 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?

Schema descriptions are 0% and parameter names are only productA/productB with syntactic patterns. The description adds semantic meaning by calling them canonical ProductTwins and tying the result to verified interface systems, but it does not explain ID format or how to obtain eligible ProductTwins.

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?

Description uses a specific verb ('Compares') and names the resource ('two canonical ProductTwins'), then clarifies the exact condition for a positive result ('direct compatibility only when their verified interface system matches'). This distinguishes it from broader search/fit/offer siblings even without naming them.

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 intended use is implied: call it to check direct compatibility between two canonical ProductTwins. However, it gives no explicit when-to-use/when-not-to-use guidance or alternatives among the 14 sibling tools, so an agent must infer 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 establish read-only, idempotent, and non-destructive behavior, so the bar is lower. The description adds a valuable behavioral disclosure: the result includes an explicit physical-test warning, and 'deterministic' reinforces the idempotent semantics. No contradiction with annotations.

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

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

The single sentence is tight and front-loaded, with no filler words. It is not bloated, but it may be too terse to be fully 'appropriately sized' for a seven-parameter tool; still, the conciseness itself is strong.

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 output schema reduces the need to describe return values, but the input side is under-specified: seven parameters with no schema descriptions and no parameter mentions in the description. An agent cannot determine the semantics of gender, measurementBasis, or userCalibrationMm, nor is the tool clearly positioned against its siblings.

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

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

Schema description coverage is 0% and the description mentions none of the seven parameters, so it adds no meaning beyond the raw schema. It does not explain nominalMm, fitType, measurementBasis, userCalibrationMm, or the free-text process/material fields.

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 specific action (calculates), a specific object (deterministic manufacturing compensation), and a distinctive output behavior (explicit physical-test warning). It is not a tautology and is distinguishable from siblings like get_compatibility, though it does not explicitly compare with them.

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

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

No explicit when/when-not/alternative guidance is given. The phrase 'deterministic manufacturing compensation' implies the use case, but an agent gets no direction on when to prefer this over get_compatibility or other sibling tools, and no exclusions are stated.

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 readonly, non-destructive, and idempotent behavior. The description adds meaningful behavioral nuance by stating that the tool returns a single missing observation and does not promote hypotheses to facts, which is useful beyond the annotations.

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

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

The description is a single tightly worded sentence that front-loads the action and result. Every phrase earns its place, including the clarifying constraint about not promoting hypotheses.

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 output schema and annotations cover return and safety semantics, and the core behavior is clear. However, the required input parameter is entirely undocumented and usage guidance is only implicit, leaving a moderate gap for correct 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 has one required parameter, 'description', with 0% schema description coverage. The tool description never explains what should go into this parameter, leaving the agent to guess whether it is a problem statement, a query, or contextual text.

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 specific verb ('Returns') and resource ('missing observation'), and adds a distinguishing constraint ('without promoting hypotheses to facts'). This clearly separates it from hypothesis-generation and verification 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 intended use is implied: call it when you need the next highest-value missing observation. However, it does not explicitly state when not to use it or point to alternatives, so the agent must infer the decision context.

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 mark the tool read-only and idempotent. The description adds useful context beyond that: deprecation status, the restriction to provider discovery only, and the fact that verified output is intentionally separated.

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 short sentence front-loads the deprecation warning and immediately points to the replacement. 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 deprecated adapter with safe read annotations and an output schema, the description covers selection, behavior, and alternative routing. It is slightly incomplete only in parameter semantics, which is already accounted for separately.

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

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

Schema description coverage is 0%, so the description needed to explain query and limit semantics but does not mention either parameter. The agent must infer that query is the search text and limit caps the result count from the property names and constraints.

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 it is a deprecated compatibility adapter and explicitly says it returns provider discovery only, which distinguishes it from get_verified_commerce_options. The verb 'returns' plus resource scope makes the tool's function 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?

Names the alternative tool explicitly and gives the condition for it: 'use get_verified_commerce_options for separated verified output.' The 'Deprecated compatibility adapter' label tells agents to avoid this tool unless compatibility is required.

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, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context: it returns a canonical, singular ProductTwin and includes source-level provenance, which tells the agent the response carries traceability beyond basic fields. No contradiction with annotations.

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

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

A single, front-loaded sentence communicates the core behavior, the resource type, and the provenance aspect without filler. It avoids repeating annotation information and earns every word.

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 one-parameter read operation with rich annotations and an output schema, the description is nearly complete. The main missing piece is guidance for when the agent lacks a stable identifier and should use sibling search tools, but that gap is already reflected in usage_guidelines.

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

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

Schema description coverage is 0%, so the description must compensate for the single `id` parameter. It does so meaningfully by calling it a 'stable identifier', clarifying that it is a durable canonical key rather than an arbitrary name or label. The schema's pattern covers format constraints, so together they are adequate.

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 ('Returns'), a specific resource ('canonical ProductTwin'), and a distinguishing feature ('source-level provenance by stable identifier'). This clearly separates it from sibling search/list tools like search_candidates and search_parts.

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

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

No explicit when-to-use or when-not-to-use guidance is provided. The phrase 'by stable identifier' implies the caller already has the identifier, but there is no direction to use search-oriented siblings when the identifier is unknown, and no mention of error or not-found behavior.

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 that the tool is read-only, idempotent, and non-destructive, so the bar for additional behavioral disclosure is lower. The description adds meaningful context beyond the annotations: it splits discovery candidates from RevenueGuard-approved offers and enforces distribution rights per surface, which is not derivable from the schema or annotations. No contradiction 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?

The description is a single compact sentence with no filler. It front-loads the core action ('Returns discovery candidates') and packs the two key qualifiers—RevenueGuard approval and per-surface rights enforcement—into a tight structure. Every phrase contributes meaning, even if the jargon reduces immediate clarity.

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 output schema covers return shape and annotations cover safety, so those aspects do not need description. However, the description omits usage guidance and enough parameter semantics for an agent to reliably invoke it correctly, especially the surface enum and how 'separately' manifests in the response. For a 3-parameter read tool, this is a minimally viable but incomplete definition.

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

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

Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It does not explain the 'query' format, how 'limit' behaves, or the meaning of the 'surface' enum values beyond implying surface affects distribution rights. The phrase 'per surface' gives surface some contextual meaning, but limit and query remain purely name-based.

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 uses a specific verb ('Returns') and identifies concrete resources: 'discovery candidates' and 'RevenueGuard-approved monetizable offers.' It also conveys a distinguishing trait—separating these categories and enforcing per-surface distribution rights—which sets it apart from broader siblings like get_offers or search_candidates. However, the phrase 'separately from' is slightly ambiguous about whether both categories are returned or only discovery candidates, and 'RevenueGuard' is unexplained jargon, so it stops short of a 5.

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

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

There is no guidance on when to use this tool versus alternatives. The description states behavior but does not tell the agent whether to select this over get_offers, search_candidates, or verify_solution. An agent would have to infer the use case from the tool name and vague description, which is insufficient.

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, and non-destructive behavior, so the description does not need to repeat that. It adds useful context by limiting the result to 'generator families implemented by the current deterministic core,' but provides no detail on ordering, filtering, or edge 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?

A single 11-word sentence that states the essential action without fluff. The key constraint 'only generator families... current deterministic core' is front-loaded.

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?

Although the annotations and output schema cover safety and return shape, the description leaves a major gap around the intent parameter and does not explain how this tool fits among its siblings. For a simple tool this is minimally functional but not complete enough for confident selection and 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?

Schema description coverage is 0% and the description does not mention the intent parameter at all. An agent cannot determine whether intent filters the returned families or changes the meaning of the result, so the description fails to compensate for the schema gap.

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 uses a specific verb ('Lists') and a specific resource ('generator families implemented by the current deterministic core'). It is clearly distinct from sibling generation tools because it enumerates families rather than producing artifacts, though it does not name any 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?

There is no guidance on when to use this tool versus siblings like generate_artifact or search_candidates. It also does not explain when the optional intent parameter should be provided or omitted.

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?

The annotations already establish read-only, idempotent, non-destructive behavior, and the description adds useful behavioral context: resolution is deterministic and the tool either produces the best supported next action or the minimum missing information. This goes beyond the structured annotations without contradicting them.

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

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

The description is a single sentence with no filler and front-loads the verb and outcome. It loses a point because the phrase 'problem-first resolver' is used without explanation, making the sentence harder to parse than necessary.

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 output schema and annotations cover some context, but the description is incomplete for a tool with five mostly undocumented parameters and many closely related siblings. An agent is not given enough information about what inputs matter, how to phrase the required description, or when this tool should be chosen over alternatives.

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

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

Schema description coverage is 0% and the description provides no meaning for any of the five parameters. It does not even mention that 'description' is required or clarify roles of intent, productA, productB, or relationship. The description entirely fails to compensate for the missing schema documentation.

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 specific operation ('runs the deterministic problem-first resolver') and a concrete outcome ('returns the best supported next action or the minimum missing information'), so an agent can tell it is a decision/resolution tool. It does not explicitly distinguish itself from siblings like synthesize_physical_solution or get_next_observation, which lowers it from a 5.

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

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

There is no explicit guidance about when to use this tool versus the many sibling tools. The description implies it is for resolving a physical-part problem and getting the next action, but it never states prerequisites, exclusions, or how this resolver relates to other tools.

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, and destructiveHint, so the safety profile is covered. The description adds meaningful behavior: the guarantee that a candidate is never presented as an identified product without evidence. This is valuable context beyond the structured annotations.

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

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

The description is a single sentence with a semicolon, front-loading the core action and then qualifying the result semantics. There is no filler or redundancy. It is appropriately concise, though it could be slightly more informative without becoming verbose.

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 read-only, idempotent search with an output schema, the description covers the essential purpose and a key behavioral constraint. However, it does not address when to prefer this over search_parts or how limit behaves. Given the sibling context, this is a moderate gap.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. It mentions 'Searches' which loosely implies the query parameter, but it does not describe the limit parameter or any query formatting constraints. This is minimal compensation at best.

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: 'Searches the verified local index for candidates.' It clarifies the result type by noting that a candidate is never presented as an identified product without evidence. It does not explicitly contrast with the sibling search_parts, but the candidate concept provides reasonable differentiation.

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

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

No guidance is provided about when to use this tool versus alternatives like search_parts or get_product. The description implies use for candidate discovery but does not state exclusions, prerequisites, or a decision rule. An agent must infer usage from the tool name and sibling list.

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 communicate read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful context by emphasizing that the index is 'verified' and local, and that the tool will not fabricate identities. This goes beyond the structured annotations without contradicting them.

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

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

A single sentence that is tightly worded and front-loaded with the core action. Every phrase contributes meaning: 'verified', 'local', 'product and part-type index', and 'without inventing identities' all add useful semantic weight.

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 simple two-parameter schema, rich annotations, and presence of an output schema, the description is largely sufficient. The main missing piece is explicit routing guidance relative to sibling search or generation tools, but this is a minor gap for such a straightforward search operation.

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

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

Schema description coverage is 0%, and the description provides no parameter-specific meaning for 'query' or 'limit'. It does clarify what the query searches against, but it does not explain accepted formats, matching behavior, or how limit affects results. The description fails to compensate for the completely undocumented parameters.

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 uses a specific verb ('Searches') and identifies a clear resource ('verified local product and part-type index'). 'Without inventing identities' communicates a hard constraint and helps distinguish this tool from generation-oriented siblings like generate_artifact or synthesize_physical_solution.

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 when to use the tool: when searching a trusted, local, verified index rather than inventing or generating possibilities. However, it does not explicitly name alternatives or state when not to use this tool, so usage guidance remains implicit rather than direct.

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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered without description help. The description adds some behavioral context by specifying the possible return shape ('supported solution' or 'next required observation'), but it does not explain what 'canonical resolver' means or what triggers which outcome.

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 text is short and front-loaded, but it is under-specified rather than efficiently complete. The phrase 'canonical resolver' takes up space without adding useful meaning, and the description omits essential information about the input and usage context.

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 one-parameter tool with an output schema, the description could get by with less, but it still fails to explain the input contract or how this tool fits among 14 siblings. The vague 'canonical resolver' and 'next required observation' leave too much to inference.

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

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

Schema description coverage is 0%, so the description must explain the only parameter, 'description', but it does not mention it at all. An agent cannot tell whether 'description' should contain a physical problem statement, constraints, desired outcome, or something else.

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 concrete outcome — returns either a supported solution or the next required observation — but the key phrase 'canonical resolver' is vague jargon. It does not adequately distinguish this tool from siblings like resolve_problem or get_next_observation, whose names and purposes overlap.

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 guidance on when to call this tool versus alternatives. With siblings such as get_next_observation, resolve_problem, and verify_solution, the description should clarify which workflow stage this tool belongs to, but it gives no such context.

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 cover the safety profile (read-only, idempotent, non-destructive), and the description adds that it produces structured artifacts rather than a solution. It does not explain canonicalization behavior or whether existing problem state is replaced, but this gap is smaller because readOnlyHint and idempotentHint already convey the core behavioral context.

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

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

A single front-loaded sentence states the action, the input, and the three concrete outputs with no filler. It is as concise as possible while still conveying the core behavior.

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 tool with readOnlyHint, idempotentHint, and an existing output schema, the description covers the essential context: what goes in and what comes out. It is slightly incomplete only in not placing itself in the problem-solving workflow relative to its siblings.

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 0% description coverage on the only parameter, and the tool description merely refers to 'the supplied description' without explaining what constitutes a valid physical problem description, expected format, or examples. Since low schema coverage requires the description to compensate, this is insufficient even though the parameter name is somewhat self-explanatory.

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 uses a concrete verb ('Builds') and identifies specific outputs: a canonical PhysicalProblem, an Observation Graph, and an explicit unknown set. This makes the operation clearer than the title alone, though it does not explicitly contrast with sibling tools like resolve_problem or synthesize_physical_solution.

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

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

No guidance is given about when to call this tool versus alternatives; the description only states what it does with a supplied description. It does not mention that it is a preprocessing step before hypothesis generation or solution synthesis, nor does it name any sibling tool or exclusion condition.

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 cover read-only, idempotent, and non-destructive behavior. The description adds meaningful context: verification is done 'independently' and reported 'separately from generation,' which clarifies the tool's role beyond what annotations 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 a single sentence that is front-loaded with the action and contains no filler. Every phrase adds value: independent checking, canonical constraints, and separation from generation.

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

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

With an output schema present, the return value need not be explained, but the description still leaves key aspects unclear: what 'description' means, what counts as a candidate, and where the canonical constraints come from. The definition is minimally sufficient but lacks important operational detail.

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

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

Schema description coverage is 0%, so the description must compensate, but it does not explain what the required 'description' parameter should contain or what structure 'candidate' should follow. The word 'candidate' is the only vague hint, leaving both parameters under-specified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: it 'Checks a proposed candidate independently against the canonical constraints.' It also differentiates verification from generation, which helps distinguish it from generation-focused siblings, though it does not name alternative tools 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?

The description implies this tool should be used when a candidate needs independent verification rather than generation. However, it does not explicitly state when not to use it or name alternative tools, so the usage context is only implied.

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