This server provides an MCP interface to IQMS/DELMIAworks (EnterpriseIQ) ERP, exposing read-only Oracle database queries and transactional write operations via the licensed WebAPI module.
Discovery & Status
iqms_navigate — explore available tools within a domain (workorders, inventory, boms, sales_orders, purchase_orders, schedule, quality)
iqms_status — verify Oracle credentials and WebAPI driver configuration
Work Orders
(Read) iqms_workorders_list — filter open/in-progress WOs by status, customer, item, or due date
(Read) iqms_workorders_get — retrieve full work order detail including routings
(Write, WebAPI) iqms_workorders_create — create a new work order
(Write, WebAPI) iqms_workorders_post_production — record quantities made/scrapped
Inventory
(Read) iqms_inventory_onhand — query stock levels by item, location, or lot
(Read) iqms_inventory_lot_trace — walk lot genealogy forward or backward
(Write, WebAPI) iqms_inventory_adjust — post positive or negative adjustments with a reason code
Bills of Materials
(Read) iqms_boms_explode — break down a parent item into components (single or multi-level)
(Read) iqms_boms_where_used — find all parent items consuming a given component
Sales Orders
(Read) iqms_sales_orders_list — list open SOs with ship status, filterable by customer or ship date
Purchase Orders
(Read) iqms_purchase_orders_list — list open POs with expected receipts, filterable by supplier or date
Scheduling
(Read) iqms_schedule_capacity — view machine/work-center schedule and capacity load within a date range
Quality
(Read) iqms_quality_ncrs — list non-conformances, CARs, and CAPAs filtered by status, item, or date
(Write, WebAPI) iqms_quality_create_ncr — open a new NCR with description, item, reporter, and linked work order
The server runs as local stdio or a stateless HTTP gateway with per-request credential headers.
Provides tools to interact with IQMS/DELMIAworks (EnterpriseIQ) manufacturing ERP from Dassault Systèmes, enabling queries and operations on work orders, inventory, BOMs, sales orders, purchase orders, schedule, and quality.
iqms-mcpMCP server for IQMS / DELMIAworks (EnterpriseIQ), the manufacturing ERP from Dassault Systèmes.
Status: Read tools issue queries through
@wyre-technology/node-iqmsagainst the Direct Oracle path (always available). Write tools route through the licensed DELMIAworks WebAPI module — an optional add-on — and throwDriverNotConfiguredErroruntilX-IQMS-WebAPI-Base-URLcredentials are supplied.
EnterpriseIQ doesn't have a public REST API. The realistic integration paths are:
Direct Oracle (universal at every install) — read-only queries
WebAPI module (paid licensed add-on) — transactional writes
This MCP server exposes both behind a single decision-tree-navigated tool surface.
Related MCP server: Industrial MCP Agent Platform
Initial discovery surface (always available):
iqms_navigate — list tools in a domain
iqms_status — credential / connection check
Domains: workorders, inventory, boms, sales_orders, purchase_orders,
schedule, quality.
Read tools (Oracle, available always):
Tool | Purpose |
| Open / in-progress work orders |
| Full work order detail incl. routings |
| On-hand by item / location / lot |
| Lot genealogy walk |
| BOM explosion |
| Where-used reverse lookup |
| Open SOs / ship status |
| Open POs / expected receipts |
| Machine schedule + capacity load |
| Non-conformances / CARs / CAPAs |
Write tools (WebAPI, gated):
Tool | Purpose |
| Create a new work order |
| Post qty made / scrapped |
| Inventory transaction |
| Open a non-conformance record |
IQMS_ORACLE_USER=eiq_ro \
IQMS_ORACLE_PASSWORD=… \
IQMS_ORACLE_CONNECT_STRING=eiq-db.example.com:1521/EIQ \
npx -y github:WYRE-AI/iqms-mcpMCP_TRANSPORT=http \
MCP_HTTP_PORT=8080 \
AUTH_MODE=gateway \
node dist/http.jsIn gateway mode, credentials are injected per-request via headers:
Header | Required | Notes |
| yes | Oracle DB user |
| yes | Oracle DB password |
| yes | Easy Connect or TNS |
| no | Enables write tools when present |
| no | |
| no |
Apache-2.0
Explode a BOM. Single-level by default; pass max_level to recurse deeper.
| Name | Required | Description | Default |
|---|---|---|---|
| parent_item | Yes | ||
| max_level | No | Default 1 |
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.
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.
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.
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.
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.
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.
Find every parent item that consumes a given component. Single-level by default.
| Name | Required | Description | Default |
|---|---|---|---|
| component_item | Yes | ||
| max_level | No | Default 1 |
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.
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.
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.
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.
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.
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.
Post an inventory adjustment (positive or negative quantity). Requires WebAPI credentials.
| Name | Required | Description | Default |
|---|---|---|---|
| item_number | Yes | ||
| location | Yes | ||
| lot_number | No | ||
| quantity_delta | Yes | Signed delta vs current on-hand | |
| reason_code | Yes | ||
| notes | No |
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.
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.
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.
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.
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.
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.
Walk lot genealogy. Direction "from_components" walks back through inputs that produced the lot; "where_produced" walks forward to lots derived from it.
| Name | Required | Description | Default |
|---|---|---|---|
| lot_number | Yes | ||
| direction | No | Default from_components |
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.
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.
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.
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.
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.
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.
List on-hand inventory by item, location, or lot. By default hides zero-quantity rows.
| Name | Required | Description | Default |
|---|---|---|---|
| item_number | No | ||
| location | No | ||
| lot_number | No | ||
| hide_zero_on_hand | No | Default true | |
| limit | No |
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.
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.
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.
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.
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.
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.
List purchase orders. Filter by status, supplier, or expected receipt date.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | ||
| supplier_id | No | ||
| expected_before | No | ISO date | |
| expected_after | No | ISO date | |
| limit | No |
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.
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.
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.
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.
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.
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.
Open a non-conformance record. Requires WebAPI credentials.
| Name | Required | Description | Default |
|---|---|---|---|
| item_number | No | ||
| work_order_id | No | ||
| description | Yes | ||
| reported_by | No |
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.
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.
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.
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.
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.
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.
List non-conformances / Corrective Action Requests (CARs / CAPAs). Filter by status, item, or reported date.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | ||
| item_number | No | ||
| reported_after | No | ISO date | |
| reported_before | No | ISO date | |
| limit | No |
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.
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.
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.
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.
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.
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.
List sales orders. Filter by status, customer, or requested ship date.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | ||
| customer_id | No | ||
| ship_before | No | ISO date | |
| ship_after | No | ISO date | |
| limit | No |
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.
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.
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.
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.
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.
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.
List scheduled work-center slots within a date range.
| Name | Required | Description | Default |
|---|---|---|---|
| work_center | No | ||
| start_date | Yes | ISO date | |
| end_date | Yes | ISO date | |
| limit | No |
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.
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.
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.
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.
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.
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.
Check IQMS connection status — reports whether Oracle credentials are configured and whether the optional WebAPI (write) driver is enabled.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Create a new work order. Requires WebAPI credentials (licensed module). Returns DriverNotConfiguredError when WebAPI is not configured.
| Name | Required | Description | Default |
|---|---|---|---|
| item_number | Yes | ||
| quantity | Yes | ||
| due_date | No | ISO date | |
| customer_id | No | ||
| notes | No |
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.
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.
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.
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.
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.
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.
Get a single work order by ID, including routings.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Work order ID |
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.
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.
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.
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.
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.
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.
List work orders. Filter by status, customer, item, or due date. Returns up to limit rows (default 50, max 500).
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by WO status | |
| customer_id | No | Filter by customer ID | |
| item_number | No | Filter by item number | |
| due_before | No | ISO date — due on or before | |
| due_after | No | ISO date — due on or after | |
| limit | No | Max rows (default 50, max 500) |
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.
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.
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.
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.
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.
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.
Post production quantities (made / scrapped) against a work order. Requires WebAPI credentials.
| Name | Required | Description | Default |
|---|---|---|---|
| work_order_id | Yes | ||
| quantity_made | Yes | ||
| quantity_scrapped | No | ||
| scrap_reason_code | No | ||
| posted_at | No | ISO timestamp |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.0.0-semantically-releasediqms_boms_explodeiqms_boms_where_usediqms_inventory_adjustiqms_inventory_lot_traceiqms_inventory_onhandiqms_navigateiqms_purchase_orders_listiqms_quality_create_ncriqms_quality_ncrsiqms_sales_orders_listiqms_schedule_capacityiqms_statusiqms_workorders_createiqms_workorders_getiqms_workorders_listiqms_workorders_post_productionScored across 16 tools
Several tools have overlapping purposes, such as the domain-named tools (workorders, inventory, boms) which duplicate functionality already provided by specific prefixed tools like iqms_workorders_list, iqms_inventory_onhand, etc. This creates ambiguity about which tool to use.
Naming is inconsistent: tools have either a 'iqms_' prefix with snake_case (e.g., iqms_boms_explode) or no prefix and just a noun (e.g., workorders, inventory). Additionally, some tools use verbs (list, get, create) while others are simply domain names.
With 16 tools, the count is slightly above the typical 3-15 range but still reasonable for an ERP system covering multiple domains. The overlap reduces efficiency but does not make the count inappropriate.
The tool set covers basic retrieval and creation for several domains but lacks update, delete, and other lifecycle operations. For example, sales orders and purchase orders only have list tools, and no tools exist to modify or close records.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
isolved and ApplicantPro jobs, tenant discovery, and change detection as an MCP server.
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
Unified MCP server for 70+ eCommerce platforms: products, orders, customers, and more.
