inventree-mcp

by hvkshetry

Overview Schema Source Related Servers Discussions Admin

Python

Remote

purchase_order

Manage the full lifecycle of purchase orders, from creation to receiving and completion, for inventory procurement.

Instructions

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": "..."}.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`operation`	Yes
`pk`	No
`data`	No
`location_id`	No
`items`	No
`search`	No
`limit`	No
`offset`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Jun 3, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations provide basic hints (readOnlyHint=false, destructiveHint=false). The description adds significant behavioral context: which operations are read vs write, and the return format (JSON string with data or error). This goes 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 well-structured: summary line, operations grouped by read/write, parameter list with clear labels, and return 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.

Completeness5/5

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

Given the complexity of the tool (multiple operations, 8 parameters), the description covers purpose, operations, all parameters, and return format. The presence of an output schema further supports completeness.

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%, but the description explains every parameter: operation (list), pk, data, location_id, items with example, search, limit, offset. This fully compensates for the schema's lack of 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 'Purchase order lifecycle management in InvenTree' and lists all read and write operations. This distinguishes it from sibling tools like sales_order and return_order.

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 all operations but does not provide explicit guidance on when to use each operation or when to choose this tool over alternatives. Usage is implied through the operation list but lacks explicit when/when-not.

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

Deploy Server