Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@inventree-mcp list all parts in category Electronics"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for InvenTree inventory management. Provides 12 parameterized tools covering 117 operations for parts, stock, build orders, purchase/sales/return orders, companies, barcodes, labels, reports, attachments, and system administration.
Python 3.11+
uv (recommended) or pip
An InvenTree instance with API access enabled
An API token (generate from InvenTree > Settings > API Tokens)
Related MCP server: MCP Inflow Ingredients
# Clone the repository
git clone https://github.com/puran-water/inventree-mcp.git
cd inventree-mcp
# Copy the example environment file and fill in your values
cp .env.example .env
# Install dependencies
uv syncEdit .env with your InvenTree instance URL and API token:
INVENTREE_URL=https://your-inventree-instance.example.com
INVENTREE_TOKEN=your-api-token-hereuv run python server.pyuv run python server.py sse --port 3074Add to your MCP client config (e.g. ~/.claude/mcp.json):
{
"mcpServers": {
"inventree-mcp": {
"command": "uv",
"args": ["run", "--directory", "/path/to/inventree-mcp", "python", "server.py"],
"env": {
"INVENTREE_URL": "https://your-inventree-instance.example.com",
"INVENTREE_TOKEN": "your-api-token-here"
}
}
}
}Or for SSE transport:
{
"mcpServers": {
"inventree-mcp": {
"url": "http://localhost:3074/sse"
}
}
}Each tool uses a parameterized operation field to select the specific action.
Tool | Operations | Description |
| 21 | Part & category management (list, get, create, update, delete, BOM, suppliers, parameters) |
| 16 | Stock item & location management (list, get, create, transfer, count, add, remove) |
| 9 | Manufacturing build orders (list, get, create, update, allocate, complete, cancel) |
| 12 | Purchase order lifecycle (list, get, create, update, issue, receive, complete) |
| 14 | Sales order lifecycle (list, get, create, shipments, allocations) |
| 8 | Return order management |
| 12 | Suppliers, manufacturers, customers, contacts, addresses |
| 4 | Barcode scan, assign, unassign, lookup |
| 5 | Label template listing and printing |
| 3 | Report template listing and generation |
| 5 | File attachments on any object (upload, download, delete) |
| 8 | Health, version, settings, users, groups, currencies |
server.py — FastMCP server with 12 parameterized tools and dual transport (STDIO/SSE)
client.py — Async adapter wrapping the official inventree-python library via asyncio.to_thread() with a semaphore for concurrency control
The inventree-python library is synchronous (requests-based). All calls are offloaded to threads to maintain async compatibility with the MCP framework.
MIT
File attachment management for any InvenTree object.
Operations: Read: list, download Write: upload, upload_link Delete: delete
Args: operation: One of the operations listed above. model_type: Object type (part, stockitem, build, purchaseorder, salesorder, company). model_id: Object ID for list/upload/upload_link. attachment_id: Attachment ID for download/delete. file_path: Local file path for upload. link: URL for upload_link. comment: Optional comment for uploads. destination: File path to save downloaded attachment to.
Returns: JSON string with attachment data or {"error": "..."}.
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | ||
| model_type | No | ||
| model_id | No | ||
| attachment_id | No | ||
| file_path | No | ||
| link | No | ||
| comment | No | ||
| destination | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false; the description adds context by listing operations (list, download, upload, etc.) but does not elaborate on side effects, permissions, or failure modes beyond a basic error return.
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 well-structured with clear sections for operations, arguments, and returns, each sentence serving a purpose and no redundant 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?
Given the complexity (8 parameters, multiple operations) and the presence of an output schema, the description provides sufficient detail for basic usage, though it could explicitly state which parameters are required for each operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description fully compensates by explaining each parameter (operation, model_type, attachment_id, etc.), including the list of valid operations and object types.
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 'File attachment management for any InvenTree object' and enumerates supported operations (Read, Write, Delete), making the tool's purpose unambiguous and distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly distinguishes this tool from siblings by focusing on attachments, but lacks explicit guidance on when to use it vs. other tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Barcode scanning and assignment in InvenTree.
Operations: Read: scan, lookup Write: assign, unassign
Args: operation: One of the operations listed above. barcode_data: Barcode string for scan/assign/lookup. model_type: Model type for assign/unassign (part, stockitem, stocklocation, build, purchaseorder, salesorder, returnorder). pk: Object ID for assign/unassign.
Returns: JSON string with barcode result or {"error": "..."}.
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | ||
| barcode_data | No | ||
| model_type | No | ||
| pk | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false; the description adds the specific write operations (assign/unassign) but discloses no additional behavioral traits such as side effects, authentication needs, or rate limits. With annotations present, the description provides only marginal extra 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?
The description is concise (roughly 6 lines), front-loads the overall purpose, then lists operations, parameter details, and return format. Every sentence adds value with no repetition or fluff.
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 (0% schema coverage), minimal annotations, and an existing output schema, the description covers purpose, operations, parameter details, and return format. It lacks prerequisites or error handling specifics but is largely complete for typical 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?
Schema description coverage is 0%, so the description fully compensates by clearly explaining each parameter: operation (enumerates options), barcode_data (purpose), model_type (lists valid models like part, stockitem, etc.), and pk (object ID). This adds essential meaning beyond the bare 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 'Barcode scanning and assignment in InvenTree' and lists specific operations (scan, lookup, assign, unassign), providing a precise verb+resource combination that distinguishes this tool from siblings like 'part' or 'stock'.
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 barcode-related tasks but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or when-not-to-use guidance. No sibling differentiation beyond the tool's name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manufacturing build order management in InvenTree.
Operations: Read: list, get, get_outputs, get_lines Write: create, update, allocate, complete, cancel
Args: operation: One of the operations listed above. pk: Build order ID. data: Dict of fields for create/update/complete. items: List of allocation dicts for allocate (e.g. [{"stock_item": 1, "quantity": 5, "build_line": 3}]). search: Text search filter for list. limit: Max results (default 25). offset: Pagination offset.
Returns: JSON string with build order data or {"error": "..."}.
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | ||
| pk | No | ||
| data | No | ||
| items | No | ||
| search | No | ||
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only, non-destructive, and open-world behavior. The description adds operations and return format, but does not detail mutation effects, error handling, or permission needs. Moderate improvement over annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections, but the 'Operations' list is somewhat redundant given the 'operation' parameter. Remaining text is 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?
Covers all parameters and return format, but lacks per-operation required parameters (e.g., pk for get/update). Output schema exists, reducing need for detailed return field descriptions, but guidance on parameter combinations is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains all 7 parameters, including examples for 'items'. This provides essential meaning that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as 'building order management in InvenTree', listing specific read/write operations. Sibling tools like 'part' or 'stock' are distinct domains, so this tool is easily distinguishable.
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 lists operations but does not explicitly guide when to use this tool vs siblings or which operation to pick. Context from sibling names implies domain-specific usage, but no situational guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Supplier, manufacturer, and customer management in InvenTree.
Operations: Read: list, get, list_supplier_parts, get_supplier_part, list_manufacturer_parts, get_manufacturer_part, list_contacts, list_addresses, get_price_breaks Write: create, update Delete: delete
Args: operation: One of the operations listed above. pk: Company, supplier part, or manufacturer part ID. data: Dict of fields for create/update. company_id: Company ID for list_supplier_parts/list_manufacturer_parts/list_contacts/list_addresses. supplier_part_id: Supplier part ID for get_price_breaks. search: Text search filter for list/list_supplier_parts/list_manufacturer_parts. is_supplier/is_manufacturer/is_customer: Boolean filters for list. limit: Max results (default 25). offset: Pagination offset.
Returns: JSON string with company data or {"error": "..."}.
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | ||
| pk | No | ||
| data | No | ||
| company_id | No | ||
| supplier_part_id | No | ||
| search | No | ||
| is_supplier | No | ||
| is_manufacturer | No | ||
| is_customer | No | ||
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description confirms deletable operations but adds limited new behavioral insight (e.g., return format as JSON error string). It does not detail side effects, authentication requirements, or rate limits beyond the annotation basics.
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 well-structured with clear sections (overview, operations, args, returns) and front-loaded with the core purpose. While comprehensive, it is slightly verbose; each sentence contributes value, but some repetition could be trimmed (e.g., listing all operations in both text and args).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, multiple operations), the description covers all key aspects: operation list, parameter explanations, return format. It lacks details on error propagation or required parameter combinations beyond the schema, but it is sufficiently complete for an agent to invoke correctly.
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 0% schema description coverage, the description fully compensates by explaining each parameter's purpose and operation-specific usage (e.g., pk for company/supplier/manufacturer ID, company_id for list endpoints, search for filtering). This adds substantial meaning beyond the raw 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 domain (Supplier, manufacturer, and customer management in InvenTree) and enumerates all supported operations (list, get, create, update, delete). This provides a specific verb-resource mapping and distinguishes the tool from sibling tools focused on other domains like parts or 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 lists what the tool can do but does not provide explicit guidance on when to use this tool versus alternatives (e.g., when to choose company over stock or purchase_order). Usage is implied through the domain context, but no exclusions or when-not scenarios are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Label printing and template management in InvenTree.
Operations: list_templates, print_part, print_stock, print_location, download_template
Args: operation: One of the operations listed above. label_type: Filter for list_templates (part, stock, location). template_id: Label template ID for print/download operations. item_ids: List of item IDs to print labels for. destination: File path to save downloaded template to.
Returns: JSON string with label templates or print result.
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | ||
| label_type | No | part | |
| template_id | No | ||
| item_ids | No | ||
| destination | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the tool's operations (including print and download, which may have side effects) and the return format (JSON string). While annotations indicate no destructiveness, the description adds context about what each operation does, though it could clarify which operations modify state (e.g., printing triggers a print job).
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 and well-structured: it front-loads the purpose, then lists operations and their arguments in a clear bullet-style format. Every sentence adds value without 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?
The description covers all parameters and operations, and the presence of an output schema means detailed return structure is handled elsewhere. However, it lacks handling of error cases or edge conditions (e.g., missing template_id for print 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 0% schema description coverage, the description fully compensates by explaining each parameter: operation (list of possible values), label_type (filter for list_templates), template_id (for print/download), item_ids (list of IDs), destination (file path). This adds critical meaning beyond the schema's titles.
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: 'Label printing and template management in InvenTree.' It enumerates the five specific operations (list_templates, print_part, etc.), making it distinct from sibling tools like barcode or report which handle different domains.
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 lists the available operations and their parameters, which guides usage within the tool. However, it does not explicitly state when to use this tool versus alternatives (e.g., barcode for barcode printing) or provide conditions for when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Part & category management in InvenTree.
Operations: Read: list, get, get_stock, get_bom, get_bom_usage, get_suppliers, get_manufacturers, get_parameters, get_parameter_templates, get_test_templates, get_related, get_builds, get_internal_prices, get_sale_prices, list_categories, get_category, get_category_parameters Write: create, update, create_category Delete: delete
Args: operation: One of the operations listed above. pk: Part or category ID (required for get/update/delete and sub-queries). data: Dict of fields for create/update (e.g. {"name": "Seal Kit", "category": 5}). search: Text search filter for list/list_categories. category: Category ID filter for list. limit: Max results for list (default 25). offset: Pagination offset for list.
Returns: JSON string with part/category data or {"error": "..."}.
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | ||
| pk | No | ||
| data | No | ||
| search | No | ||
| category | No | ||
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds behavioral context by detailing read/write/delete operations, error handling, and pagination. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for operations, arguments, and returns. It front-loads the purpose. While somewhat lengthy due to listing all operations, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple operations, 7 parameters, output schema exists), the description covers operations, parameters, pagination, filters, and error handling. It provides all necessary context for an AI agent to select and invoke the tool correctly.
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 0% schema coverage, the description fully compensates by explaining each parameter: operation (with listed options), pk, data (with example), search, category, limit, offset. This provides clear semantics beyond the bare 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 'Part & category management in InvenTree', listing all specific operations (list, get, create, etc.). It distinguishes itself from sibling tools like stock or purchase_order by focusing solely on parts and categories.
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 lists operations and parameters, making it clear when to use the tool for part/category management. However, it does not explicitly contrast with sibling tools or specify when not to use it, but the context is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Purchase order lifecycle management in InvenTree.
Operations: Read: list, get, get_line_items Write: create, update, issue, receive, complete, cancel, hold, add_line_item, add_extra_line_item
Args: operation: One of the operations listed above. pk: Purchase order ID. data: Dict of fields for create/update/add_line_item. location_id: Receiving location for receive operation. items: Line items to receive (e.g. [{"line_item": 1, "quantity": 10}]). search: Text search filter for list. limit: Max results (default 25). offset: Pagination offset.
Returns: JSON string with PO data or {"error": "..."}.
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | ||
| pk | No | ||
| data | No | ||
| location_id | No | ||
| items | No | ||
| search | No | ||
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description adds the list of operations (some mutating) and the return format (JSON with data or error). However, it does not describe side effects, permission requirements, or behavioral nuances beyond annotations. The description adds moderate value.
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 and well-structured. It front-loads the purpose, then lists operations and arguments in a clear, bullet-like format. Every sentence adds value, and there is no wasted 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?
Given the complexity (8 parameters, multiple operations, output schema exists), the description is fairly complete but lacks operation-specific parameter requirements. It does not detail the output structure (though output schema exists) or error handling beyond a generic error response. More guidance on operation-specific parameter needs would improve 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 0%, so the description must compensate. It explains each parameter: operation (list of operations), pk (PO ID), data (dict for create/update), location_id (receiving location), items (line items example), search, limit, offset. This adds significant meaning beyond the bare schema types. However, it could clarify which parameters are required for each operation.
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 it is for 'Purchase order lifecycle management', lists all operations, and distinguishes itself from sibling tools by its specific domain (purchase orders vs sales orders, etc.). The verb 'manage' plus resource 'purchase order' is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a list of operations and arguments but does not explicitly state when to use this tool versus sibling tools (e.g., sales_order, return_order). It implies usage through the resource name but lacks explicit when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report generation and template management in InvenTree.
Operations: list_templates, print_report, download_template
Args: operation: One of the operations listed above. template_id: Report template ID for print_report/download_template. item_ids: List of item IDs to include in report. model_type: Model type for print_report. destination: File path to save downloaded template to.
Returns: JSON string with report templates or print result.
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | ||
| template_id | No | ||
| item_ids | No | ||
| model_type | No | ||
| destination | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide non-destructive and non-read-only hints. The description adds that the tool returns a JSON string, but lacks details on side effects, authentication needs, or whether 'print_report' actually sends to a printer.
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 structured with a clear intro, operation list, parameter details, and return information. It is fairly concise, though the Args section could be slightly more streamlined.
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 covers the operations and parameters adequately given the presence of an output schema, but lacks examples or default values that would help an agent understand typical usage patterns.
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?
Despite 0% schema coverage, the description includes an Args section that explains each parameter's purpose and how they relate to operations, significantly adding meaning beyond the raw schema names.
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 explicitly states the tool handles 'Report generation and template management in InvenTree' and lists three distinct operations, clearly differentiating it from sibling tools like 'label' or 'part'.
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 lists operations and gives brief guidance on when to use each, but does not explicitly compare to sibling tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return order lifecycle management in InvenTree.
Operations: Read: list, get, get_line_items Write: create, update, complete, cancel, add_line_item
Args: operation: One of the operations listed above. pk: Return order ID. data: Dict of fields for create/update/add_line_item. search: Text search filter for list. limit: Max results (default 25). offset: Pagination offset.
Returns: JSON string with RO data or {"error": "..."}.
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | ||
| pk | No | ||
| data | No | ||
| search | No | ||
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, destructiveHint=false) are consistent with the description's mention of write operations (create, update, cancel). The description adds operation-level detail (e.g., add_line_item) but does not discuss side effects or auth requirements, which is acceptable given the annotation coverage.
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 well-organized with sections (Operations, Args, Returns) and front-loaded with the purpose. It is somewhat lengthy but appropriate for the tool's complexity; a slightly more concise phrasing could improve it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, multiple operations), the description covers the main aspects including operations, parameters, and return format. It does not detail nested objects or all possible data fields, but the output schema is mentioned, and the description is adequate for an agent to use the tool correctly.
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 0% description coverage, so the description provides essential meaning: operation (list of values), pk (order ID), data (dict for write ops), search (text filter), limit (default 25), offset (pagination offset). This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return order lifecycle management in InvenTree' and lists specific operations (read, write) and sub-operations (list, get, create, etc.), distinguishing it from sibling tools like purchase_order and sales_order.
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 lists operations and arguments, providing clear context for when to use each operation. However, it does not explicitly state when not to use the tool or compare directly to sibling tools, though the name and context suffice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sales order lifecycle management in InvenTree.
Operations: Read: list, get, get_line_items, get_allocations Write: create, update, complete, cancel, hold, add_line_item, add_extra_line_item, create_shipment, complete_shipment
Args: operation: One of the operations listed above. pk: Sales order ID. data: Dict of fields for create/update/add_line_item. shipment_id: Shipment ID for complete_shipment. reference: Reference string for create_shipment. search: Text search filter for list. limit: Max results (default 25). offset: Pagination offset.
Returns: JSON string with SO data or {"error": "..."}.
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | ||
| pk | No | ||
| data | No | ||
| shipment_id | No | ||
| reference | No | ||
| search | No | ||
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only and non-destructive behavior. The description adds minimal behavioral context beyond listing operations; it does not disclose side effects (e.g., inventory changes on complete/cancel), required permissions, or idempotency. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a clear intro, operation list, parameter list, and return format. Every part adds value, and the length is appropriate for the tool's complexity. No redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, multiple operations) and existence of an output schema, the description is adequate but not complete. It does not specify which parameters are required for each operation (e.g., create requires data, list does not), forcing the agent to infer. Error handling is mentioned minimally.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It gives one-line explanations for each parameter (e.g., 'pk: Sales order ID', 'data: Dict of fields'), adding basic meaning. However, it lacks details like required fields for specific operations or valid enum values for 'operation', relying on the list above.
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 'Sales order lifecycle management in InvenTree' and lists all supported operations (read, write, shipment management). It implicitly distinguishes from sibling tools like purchase_order by focusing on sales orders, 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?
The description provides a list of operations but no guidance on when to use which operation or when to prefer this tool over alternatives. No contextual hints like 'use list for search, create for new orders' are given, leaving the agent to infer from parameter names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stock item & location management in InvenTree.
Operations: Read: list, get, get_by_location, get_by_part, list_locations, get_location, get_tracking, get_test_results Write: create, update, transfer, count, add, remove, create_location, upload_test_result
Args: operation: One of the operations listed above. pk: Stock item or location ID. data: Dict of fields for create/update. part_id: Filter stock by part (for list, get_by_part). location_id: Filter stock by location or transfer destination. quantity: Quantity for transfer/count/add/remove operations. test_name: Name for upload_test_result. test_result: Boolean pass/fail for upload_test_result. search: Text search filter for list/list_locations. limit: Max results (default 25). offset: Pagination offset.
Returns: JSON string with stock/location data or {"error": "..."}.
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | ||
| pk | No | ||
| data | No | ||
| part_id | No | ||
| location_id | No | ||
| quantity | No | ||
| test_name | No | ||
| test_result | No | ||
| search | No | ||
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false and destructiveHint=false. The description adds details about write operations (create, update, transfer, etc.) and return format. However, it does not disclose authorization needs, rate limits, or side effects of destructive operations like 'remove'. The description adds moderate value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized with an intro, operation lists, and parameter details. It is front-loaded but somewhat lengthy given the number of operations. Could be more concise by grouping similar operations or using bullet points, but it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters, multiple operations, and no schema descriptions, the description covers operation types and parameter meanings. The output format is mentioned ('JSON string with stock/location data'), and the presence of an output schema (context signal) reduces the need for detailed return info. Missing details on error handling and nested object structures, but adequate overall.
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 0% schema description coverage, the description compensates by explaining each parameter's purpose and usage (e.g., 'part_id: Filter stock by part'). Some explanations remain vague (e.g., 'data: Dict of fields'), but overall it adds significant meaning beyond the raw 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 'Stock item & location management in InvenTree' and enumerates specific read/write operations. While the term 'management' is broad, the operation list provides sufficient specificity. It is distinct from sibling tools like 'part' or 'purchase_order' 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?
No guidance on when to use this tool versus siblings or when not to use it. The description lists operations but does not provide context for choosing between this and other tools, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
InvenTree system administration and health checks.
Operations: health, version, settings, list_users, get_user, list_groups, list_owners, get_project_codes, list_currencies
All operations are read-only.
Args: operation: One of the operations listed above. pk: User ID for get_user.
Returns: JSON string with system data.
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | ||
| pk | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description reinforces read-only behavior and adds the list of operations, which is consistent and adds useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a brief intro, a bullet list of operations, and clear Args/Returns sections. Every sentence serves a 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?
Given the presence of an output schema and rich annotations, the description covers the parameter usage and operation domain adequately. It could include explicit enumeration of operation values for 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 description coverage is 0%. The description adds some meaning: it explains operation selects from the listed operations, and pk is for get_user. However, it does not enumerate valid operation values explicitly, leaving some ambiguity.
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 is for 'InvenTree system administration and health checks' and enumerates specific operations (e.g., health, version, settings). This distinguishes it from sibling tools like part or stock.
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 notes 'All operations are read-only' and lists operations, providing clear context. However, it does not explicitly state when not to use this tool or mention alternatives, though the domain separation from siblings implies usage.
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. Dates show when Glama detected each change.
v1.0.0attachmentbarcodebuild_ordercompanylabelpartpurchase_orderreportreturn_ordersales_orderstocksystemScored across 12 tools
Each tool addresses a distinct domain (e.g., attachment, barcode, build_order), with no overlap in purpose. The operations within each tool are specific to that domain, making it clear which tool to use for a given task.
All tool names are lowercase snake_case single words or compound words (e.g., build_order, purchase_order), following a consistent pattern. Operation names within tools are also uniform and descriptive.
12 tools is well-scoped for an inventory management system, covering all major entities (parts, stock, orders, etc.) without unnecessary granularity or missing core areas.
The tool set provides full lifecycle management for parts, stock, all order types (build, purchase, sales, return), companies, attachments, barcodes, labels, reports, and system administration. No obvious gaps in core functionality.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Manage a Foundry IMS catalog: products, variants, BOMs, plus invoices read from supplier docs.
Query and manage Mercoa AP/AR bill-pay: entities, invoices, transactions and payment methods.
Manage repositories, users, releases, and automate GitHub workflows
Inventory management for small organizations: search, assign, report, order, set up by chat.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hvkshetry/inventree-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
