inventree-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 4/5 across 12 of 12 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness3/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus 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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters (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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![inventree-mcp MCP server](https://glama.ai/mcp/servers/hvkshetry/inventree-mcp/badges/card.svg)](https://glama.ai/mcp/servers/hvkshetry/inventree-mcp)

Score Badge

Copy to your README.md:

[![inventree-mcp MCP server](https://glama.ai/mcp/servers/hvkshetry/inventree-mcp/badges/score.svg)](https://glama.ai/mcp/servers/hvkshetry/inventree-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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