Server Quality Checklist

Tool Scores

• iqms_quality_create_ncrC
  2/5.0
  Behavior2/5

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

  With no annotations, the description should disclose behavior (e.g., creating records, side effects). It only states credential requirements, leaving the agent unaware of mutations or consequences.

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

  Conciseness2/5

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

  While very short (10 words), it sacrifices necessary detail for brevity. The description is under-specified and does not effectively convey the tool's purpose or constraints.

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

  Completeness1/5

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

  Given no output schema and 4 undocumented parameters, the description fails to provide complete guidance for usage. It omits return values, error handling, and parameter meanings.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description adds no meaning to parameters. The four parameters (item_number, work_order_id, description, reported_by) are not explained, making their roles unclear.

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

  Purpose3/5

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

  The description uses 'Open' which is ambiguous for a creation tool. The name suggests creation, but 'Open' could imply viewing an existing record. It provides a general sense of what it does but lacks specificity.

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

  Usage Guidelines2/5

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

  Only mentions 'Requires WebAPI credentials' as a prerequisite. No guidance on when to use this tool versus siblings like 'iqms_quality_ncrs' or other workflow tools.

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

• iqms_workorders_post_productionC
  2.4/5.0
  Behavior2/5

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

  No annotations provided, so description carries full burden. It states it posts quantities, implying a write operation, but lacks details on side effects (e.g., status changes, permissions needed, idempotency). The credential requirement is minimal 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.

  Conciseness2/5

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

  Very short at one sentence, but it is under-specified rather than concise. Important information is omitted, so brevity is not a virtue here.

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

  Completeness1/5

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

  Given 5 parameters, 2 required, no output schema, and no annotations, the description is severely incomplete. It does not explain what the tool returns, error conditions, or workflow context (e.g., when to post production relative to other operations).

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

  Parameters2/5

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

  With 20% schema description coverage, the description should add meaning to parameters. It mentions 'made / scrapped' hinting at quantities, but does not elaborate on any of the 5 parameters, their constraints, or relationships. Missing critical info for correct invocation.

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

  Purpose4/5

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

  Clearly states it posts production quantities against a work order, using verbs 'post' and 'made/scrapped'. The tool's purpose is distinct from siblings like iqms_workorders_create or iqms_workorders_list, though it does not explicitly contrast with them.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus alternatives. The only extra info is 'Requires WebAPI credentials', which is a prerequisite, not usage context. No mention of scenarios or exclusions.

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

• iqms_quality_ncrsC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the full burden. It indicates the tool lists and filters but provides no details on behavioral traits such as pagination (despite a limit parameter), default ordering, or whether it returns all records if no filters are applied. This is insufficient for a tool with no safety cues.

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

  Conciseness4/5

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

  The description is a single concise sentence that directly states the purpose and filters. However, it could be restructured to front-load the most critical information (e.g., listing NCRs) and separate filter options more clearly.

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

  Completeness2/5

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

  Given 5 parameters (none required), no output schema, and no annotations, the description is too brief. It fails to explain default behavior, output format, or the effect of omitting filters. This leaves the agent without sufficient context to use the tool reliably.

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

  Parameters2/5

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

  Schema coverage is 40% (only date parameters described), and the description only lists filterable fields (status, item, reported date) without adding meaning beyond the schema. The 'item' reference is vague, and 'limit' is not mentioned. The description does not compensate for the low schema coverage.

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

  Purpose4/5

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

  The description uses the verb 'List' to specify the action and identifies the resource as 'non-conformances / Corrective Action Requests (CARs / CAPAs)', making the tool's purpose clear. It also mentions filtering options, which helps distinguish it from creation tools like iqms_quality_create_ncr.

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

  Usage Guidelines3/5

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

  The description implicitly indicates that this tool is for listing and filtering non-conformances, but it does not explicitly state when to use it versus alternatives (e.g., for creation use iqms_quality_create_ncr). No exclusion criteria or additional context is provided.

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

• iqms_workorders_createC
  2.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses a specific error ('Returns DriverNotConfiguredError') and a prerequisite, but does not mention other behavioral aspects such as side effects (e.g., state changes) or other possible error conditions. 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.

  Conciseness4/5

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

  The description is very short (two sentences) and each sentence adds value: purpose and then prerequisites/error. There is no unnecessary text. It could be slightly more organized but is efficient.

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

  Completeness2/5

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

  Given no output schema, the description should explain return values. It only mentions one error, ignoring typical outputs for a create operation (e.g., created work order ID). It also lacks parameter guidance and context on using the tool alongside other work order tools.

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

  Parameters1/5

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

  The input schema has 5 parameters with only 20% description coverage (due_date has 'ISO date'). The description does not mention any parameters by name or provide context for their values. Thus, it adds no meaning beyond the schema, failing to compensate for low schema coverage.

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

  Purpose4/5

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

  The description clearly states 'Create a new work order,' which is a specific verb+resource. The tool name itself is descriptive, and among sibling tools (list, get, post_production), it is obvious that this is the creation function. However, it does not explicitly state when to choose this over alternatives.

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

  Usage Guidelines3/5

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

  The description mentions the prerequisite 'Requires WebAPI credentials (licensed module)' and an error condition. This gives some guidance on when to use, but it lacks explicit when-not-to-use instructions or comparisons with other tools like iqms_workorders_post_production.

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

• iqms_inventory_lot_traceB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description must fully disclose behavioral traits. However, it omits details about side effects (e.g., read-only nature), authorization requirements, behavior for nonexistent lots, or pagination/limits. Only the directional behavior is explained.

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

  Conciseness5/5

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

  The description is concise (two sentences), front-loads the core action ('Walk lot genealogy'), and efficiently explains both directional options without extraneous text.

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

  Completeness2/5

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

  Despite the moderate complexity of lot tracing, the description does not explain the output format, return values, error conditions, or how results are structured. The absence of an output schema makes this information critical for an agent.

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

  Parameters3/5

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

  The description adds value to the 'direction' parameter by explaining the meaning of each enum value, which supplements the schema's default value. However, the 'lot_number' parameter lacks any description in both schema and description, and schema coverage is only 50%.

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

  Purpose5/5

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

  The description clearly states the tool's purpose as 'Walk lot genealogy' and explicitly defines the two directions ('from_components' and 'where_produced'), which distinguishes it from sibling tools like iqms_inventory_onhand or iqms_boms_where_used.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives such as iqms_inventory_onhand or iqms_boms_explode. It does not specify prerequisites, limitations, or scenarios where the tool is appropriate.

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

• iqms_sales_orders_listB
  3.2/5.0
  Behavior2/5

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

  The description does not explicitly state that the tool is read-only or list any side effects. With no annotations provided, the description carries the full burden but only says 'List sales orders,' which implies read-only but leaves other behavioral traits (e.g., pagination via 'limit', sorting, authentication) unaddressed.

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

  Conciseness5/5

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

  The description is a single sentence of 11 words with no redundancy. It is front-loaded with the primary action and includes key filter information. Every word contributes directly to understanding.

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

  Completeness2/5

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

  Given no output schema and no annotations, the description lacks important details such as expected return format, pagination behavior (limit parameter), default sorting, or whether filters are inclusive. For a list tool with 5 parameters, more context is needed for effective use.

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

  Parameters3/5

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

  The description mentions three filtering options (status, customer, requested ship date) that map to parameters, but it does not add meaning beyond the schema's basic info. Schema coverage is 40% (only ISO date descriptions), so the description partially compensates but could elaborate on parameter usage or format.

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

  Purpose5/5

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

  The description clearly states 'List sales orders' and specifies the filtering options (status, customer, requested ship date), which directly matches the tool name and input schema. It distinguishes itself from sibling list tools (e.g., purchase orders, work orders) by the resource type.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives like iqms_purchase_orders_list or iqms_workorders_list. There is no indication of context, prerequisites, or which scenarios are appropriate for this tool.

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

• iqms_schedule_capacityB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it lists slots, but fails to mention important traits like pagination, ordering, error handling, or what happens when no slots are found.

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

  Conciseness4/5

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

  The description is a single, concise sentence that front-loads the core action. It is efficient, though some may argue it is too terse and omits useful details.

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

  Completeness2/5

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

  For a tool with 4 parameters, no output schema, and no annotations, the description is minimal. It does not explain what a 'scheduled work-center slot' is, how results are organized, or any constraints (e.g., date format expected). The context provided is inadequate for full understanding.

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

  Parameters2/5

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

  The schema has 50% description coverage, yet the description adds no parameter-level information beyond the schema. It reinforces that start_date and end_date define the date range, but does not explain work_center (which is optional but has no description) or limit (purpose, default, max).

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

  Purpose5/5

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

  The description clearly states the action (list), resource (scheduled work-center slots), and scope (within a date range). It effectively distinguishes the tool from its siblings, none of which focus on capacity or scheduling.

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

  Usage Guidelines3/5

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

  The description implies the tool should be used to retrieve slots by date range, but does not provide explicit guidance on when to use it versus alternatives, or any prerequisites. Usage is inferred but not clarified.

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

• iqms_boms_explodeB
  3.3/5.0
  Behavior2/5

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

  No annotations exist, so the description bears full burden. It discloses default single-level and recursion via max_level, but omits critical behavioral details such as output format, error handling, side effects, or required permissions.

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

  Conciseness4/5

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

  A single sentence that is front-loaded with the core action and default behavior. No wasted words, though a slightly more structured format (e.g., separating default and override) could improve scannability.

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

  Completeness2/5

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

  Given no output schema and only 2 parameters, the description is too sparse. It does not describe the output (e.g., list of component details), pagination, or any edge cases. The agent lacks enough context to fully interpret results.

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

  Parameters3/5

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

  The description adds meaning to 'max_level' beyond the schema (clarifies recurrence), but provides no additional info about 'parent_item'. With schema coverage at 50% and only 2 parameters, the description partially compensates.

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

  Purpose5/5

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

  The description clearly states the action ('Explode a BOM') and the resource, with specific detail on default behavior and recursion via max_level. It naturally distinguishes from sibling 'iqms_boms_where_used' which finds where a BOM is used, not its components.

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

  Usage Guidelines3/5

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

  The description implies when to use (exploding a BOM) and how to deepen the explosion, but it does not explicitly compare with alternatives or state when not to use. No mention of preconditions or exclusions.

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

• iqms_inventory_adjustB
  3.3/5.0
  Behavior2/5

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

  No annotations provided, so description carries full burden. It states the credential requirement but does not disclose whether the adjustment is destructive, reversible, or any side effects on inventory records.

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

  Conciseness5/5

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

  Two sentences with no wasted words. First sentence states core function, second adds requirement. Efficient and front-loaded.

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

  Completeness2/5

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

  With 6 parameters (4 required), no output schema, and no description of return values or behavior beyond the adjustment, the description is too brief to be complete. It omits what the tool returns (e.g., success confirmation, error messages) and any side effects.

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

  Parameters2/5

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

  Schema description coverage is only 17% (only quantity_delta has a description). The tool description does not explain the meaning or usage of the other 5 parameters (item_number, location, lot_number, reason_code, notes), leaving the agent uninformed.

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

  Purpose5/5

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

  Description clearly states the verb (Post) and resource (inventory adjustment), specifies that it can be positive or negative, and distinguishes from sibling inventory tools like iqms_inventory_onhand and iqms_inventory_lot_trace.

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

  Usage Guidelines3/5

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

  Mentions a prerequisite (WebAPI credentials) but does not provide explicit guidance on when to use this tool versus alternatives, nor any when-not conditions.

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

• iqms_inventory_onhandB
  3.3/5.0
  Behavior2/5

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

  Description notes the default hiding of zero-quantity rows, but with no annotations provided, it fails to disclose other behaviors like pagination, read-only nature, response format, or limits. Minimal behavioral context beyond the single default.

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

  Conciseness5/5

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

  Two sentences, no unnecessary words, front-loaded with primary action and key default behavior. Efficient and clear.

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

  Completeness3/5

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

  Given no output schema, 5 parameters, and no annotations, the description is adequate but incomplete: it omits limits, no-parameter behavior, potential error conditions, and explicit statement that it's a read operation. Slightly below average completeness.

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

  Parameters3/5

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

  Schema coverage is low (20%), but description adds value by implying parameters 'item', 'location', and 'lot' are filter keys. However, it does not explain 'limit' or confirm the default for 'hide_zero_on_hand' beyond schema. Partial compensation.

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

  Purpose5/5

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

  Description clearly states the verb 'List' and resource 'on-hand inventory', with filtering by item, location, or lot. It distinguishes from sibling tools like iqms_inventory_adjust and iqms_inventory_lot_trace.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool vs alternatives, such as iqms_inventory_lot_trace for lot-level tracing or iqms_inventory_adjust for modifications. The description lacks context for selection.

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

• iqms_boms_where_usedB
  3.4/5.0
  Behavior2/5

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

  No annotations provided, so description carries full burden. Only states default behavior (single-level). Does not disclose error handling, permissions, or response characteristics. Minimal transparency beyond core function.

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

  Conciseness5/5

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

  Two sentences, front-loading the main action. Every word is necessary; no redundancy. Efficient and clear for a simple tool.

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

  Completeness4/5

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

  For a simple tool with two parameters and no output schema, the description covers the key purpose and default behavior. Missing details on return format or edge cases, but generally sufficient.

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

  Parameters3/5

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

  Schema description coverage is 50% (only max_level has description). Description reinforces max_level default but adds no new meaning for component_item. Compensates somewhat but could better explain component_item's purpose.

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

  Purpose4/5

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

  Clearly states finding parent items for a component ('Find every parent item that consumes a given component'). Implies distinction from sibling 'iqms_boms_explode' but does not explicitly differentiate.

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

  Usage Guidelines3/5

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

  Mentions 'Single-level by default', suggesting when to use (single-level) vs. not (multi-level). However, no explicit alternatives or when-not guidance are provided. Sibling 'iqms_boms_explode' likely handles multi-level but is not referenced.

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

• iqms_purchase_orders_listB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose behavioral traits. It only states that it lists and filters, but does not mention pagination (the limit parameter is not referenced), ordering, authentication requirements, or what data is returned. Essential behavioral context is missing.

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

  Conciseness5/5

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

  The description is highly concise: two sentences with no wasted words. The action is front-loaded, and the filtering options are listed efficiently.

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

  Completeness2/5

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

  Without an output schema, the description should explain what the tool returns (e.g., fields, format). It does not address this. Additionally, the limit parameter is omitted from the description, and there is no mention of default behavior or ordering. The tool is incomplete for an agent to use without risk.

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

  Parameters3/5

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

  Schema description coverage is 40%, with only two parameters having descriptions. The description maps to the main filter parameters (status, supplier_id, expected_before, expected_after) but does not mention the limit parameter. It adds some value by grouping filters but does not compensate for the low coverage fully.

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

  Purpose5/5

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

  The description clearly states 'List purchase orders' with a specific verb and resource, and mentions filtering by status, supplier, or expected receipt date, which distinguishes it from siblings like iqms_workorders_list or iqms_sales_orders_list.

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

  Usage Guidelines3/5

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

  The description implies usage for listing purchase orders with filters, but provides no explicit guidance on when to use this tool vs other list tools or alternatives. There is no mention of exclusions or context.

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

• iqms_workorders_listA
  3.6/5.0
  Behavior3/5

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

  No annotations provided, so the description must disclose behavior. It explains pagination via limit parameter with defaults and max. However, it does not mention that the operation is read-only or any side effects, which is a minor gap.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the core action. Every word is useful. No redundancy.

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

  Completeness2/5

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

  No output schema; the description does not mention the structure of returned work orders (e.g., fields included, sorting, pagination details beyond limits). This leaves the agent guessing about the response format.

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

  Parameters3/5

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

  Schema coverage is 100% with parameter descriptions. The description adds value by summarizing filters and clarifying limit behavior, but does not provide additional meaning beyond what's in the schema.

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

  Purpose5/5

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

  The description clearly states the tool lists work orders and specifies filtering options (status, customer, item, due date). This distinguishes it from sibling tools like get (single work order) or create.

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

  Usage Guidelines3/5

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

  The description implies use for listing work orders with filters, but does not provide explicit guidance on when to use over alternatives like iqms_workorders_get, nor when not to use.

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

• iqms_navigateA
  3.8/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose behavioral traits. It only states 'Navigate to ... to see its tools' without mentioning whether the operation is read-only, has side effects, requires permissions, or what the response contains. This is insufficient for an agent to understand the tool's behavior.

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

  Conciseness4/5

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

  The description is concise and well-structured, listing domains in a clear format. It front-loads the purpose and then provides domain details. No unnecessary sentences.

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

  Completeness3/5

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

  For a simple navigator tool with one parameter, the description is adequate but incomplete. It does not specify what 'see its tools' means in practice (e.g., does it return a list of tools, change context, etc.). No output schema is provided, so the description should clarify the expected result.

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

  Parameters4/5

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

  The schema already provides an enum for domain with descriptions, but the tool description adds significant value by explaining what tools each domain contains (e.g., 'workorders: list/get work orders, post production'). This helps the agent understand the meaning of each domain beyond a simple label.

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

  Purpose5/5

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

  The description clearly states 'Navigate to an IQMS domain to see its tools,' specifying a verb (navigate) and resource (domain). It distinguishes from sibling tools which are specific operations (e.g., iqms_boms_explode, iqms_inventory_onhand), making the purpose unambiguous.

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

  Usage Guidelines4/5

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

  The description lists domain options with brief tool descriptions, implying when to use each domain. However, it does not explicitly state when to use this tool over alternatives, such as when to navigate vs using a specific tool directly.

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

• iqms_workorders_getA
  3.8/5.0
  Behavior3/5

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

  No annotations are present, so the description carries full burden. It adds that the response includes routings, which is helpful. However, it does not disclose behavior such as read-only nature, error handling, or any side effects, which are minimal for a GET operation.

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

  Conciseness5/5

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

  The description is a single, concise sentence that conveys all necessary information without unnecessary words. It is front-loaded with the core action.

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

  Completeness4/5

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

  Given the simplicity of the tool (one parameter, no output schema), the description provides sufficient context: what it retrieves and that it includes routings. It could mention return format or failure cases, but for a straightforward getter, it is fairly complete.

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

  Parameters3/5

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

  The input schema already describes the 'id' parameter as 'Work order ID' (100% coverage). The description adds no additional semantic value beyond confirming the parameter's role.

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

  Purpose5/5

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

  The description clearly states the verb ('Get'), the resource ('a single work order'), and the scope ('by ID, including routings'). It distinguishes itself from siblings like 'iqms_workorders_list' which retrieves multiple work orders.

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

  Usage Guidelines3/5

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

  The description does not explicitly state when to use this tool versus alternatives, but the purpose implies its use for retrieving a specific work order. No exclusion criteria or context for when not to use it is provided.

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

• iqms_statusA
  4.3/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries full burden. It discloses what the tool reports (credentials, WebAPI), which is adequate for a read-only status check. No mention of side effects or error conditions, but likely none.

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

  Conciseness5/5

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

  Single clear sentence with no unnecessary words. Front-loaded with verb and purpose.

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

  Completeness3/5

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

  The description explains what the tool reports but does not describe the return format or response structure. Since no output schema exists, this gap leaves the agent unsure how to interpret results. Adequate but incomplete.

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

  Parameters4/5

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

  The tool has zero parameters with 100% schema coverage. Baseline for 0 params is 4; no additional description needed.

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

  Purpose5/5

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

  The description clearly specifies the tool checks IQMS connection status, reporting on Oracle credentials and WebAPI driver enablement. It is distinct from all sibling tools which focus on BOMs, inventory, orders, etc.

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

  Usage Guidelines4/5

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

  The description implies usage for pre-checking connectivity before using other IQMS tools, but does not explicitly address when-not-to-use or provide alternative tools. However, sibling context makes usage relatively clear.

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