Skip to main content
Glama
jameshgordy

Snipe-IT MCP Server

by jameshgordy

manage_kits

Destructive

Create, update, and delete Snipe-IT kits while managing included models, licenses, accessories, and consumables.

Instructions

Manage Snipe-IT predefined kits (bundles of models, licenses, accessories, consumables).

Kit CRUD:

  • create: Create a kit (requires kit_data with name)

  • get / list / update / delete: Standard operations by kit_id

Kit contents (requires kit_id and item_type):

  • list_items: List the kit's models/licenses/accessories/consumables

  • add_item: Attach an item to the kit (requires item_id; optional quantity)

  • update_item: Change an attached item's quantity (requires item_id)

  • remove_item: Detach an item from the kit (requires item_id)

Note: checking out a kit to a user is only available in the Snipe-IT web UI; there is no kit-checkout API endpoint. To perform a kit checkout via MCP, list the kit's items and check each out individually.

Returns: dict: Result of the operation including success status and data

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNoField to sort by (for list action): id, name, created_at, updated_at, created_by
limitNoNumber of results to return (for list action)
orderNoSort order (for list action)
actionYesThe action to perform on predefined kits
kit_idNoKit ID (required for all actions except create and list)
offsetNoNumber of results to skip (for list action)
searchNoSearch query (for list action)
item_idNoID of the model/license/accessory/consumable (required for add_item, update_item, remove_item)
kit_dataNoKit data (required for create, optional for update)
quantityNoQuantity of the item in the kit (for add_item, update_item)
item_typeNoKit content type (required for list_items, add_item, update_item, remove_item)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.1

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already signal destructive and non-read-only behavior, and the description adds meaningful behavioral context beyond those flags: there is no API endpoint for kit checkout, and items are attached/detached individually. It also explains what each content operation does at a behavioral level. It does not claim any contradiction with the 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 a short intro, bullet-style CRUD and kit-content sections, and a crucial note. It is compact for the number of actions and parameters it covers. The redundant 'Returns: dict' section slightly reduces efficiency because the availability of an output schema already covers return shape.

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 an 11-parameter, 9-action tool, the description covers the key combinations of action, kit_id, item_type, item_id, and kit_data accurately. A clear omission is naming which sibling checkout tools should be used after listing items, but the description provides enough to call the tool safely. No important behavioral or workflow gap remains.

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 100%, so the input schema already documents each parameter. The description adds value by grouping parameters by action, e.g., 'requires kit_id and item_type' for content operations and 'requires item_id; optional quantity' for add_item. This action-to-parameter mapping is useful because the schema alone does not aggregate requirements by action.

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 that the tool manages Snipe-IT predefined kits, which are bundles of models/licenses/accessories/consumables, and enumerates the exact CRUD and content operations. The phrase 'Manage' plus the operation list distinguishes it from related tools like manage_assets or manage_licenses.

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 clearly maps actions to the parameters they require, so an agent can select the correct action. It also includes an important exclusion: kit checkout is not available via API and must be done by listing items and checking them out individually. It does not name explicit alternative sibling tools, but the usage guidance is strong enough for action selection.

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