Snipe-IT MCP Server

bulk_asset_operations

Destructive

Apply bulk edits or audits to multiple assets at once, updating fields or recording audit details with per-asset permission checks.

Instructions

Perform bulk operations on multiple assets at once (Snipe-IT v8.7+).

Operations:

edit: Apply the same field changes to every asset in asset_ids (PATCH /hardware/bulk; requires fields)
audit: Mark every asset in asset_ids as audited, optionally recording a note, location, and next audit date (POST /hardware/audit/bulk)

Snipe-IT applies per-asset permission checks, so one failing asset does not block the rest of the batch; check the returned payload for per-asset results.

Returns: dict: Result of the operation including success status and the API response

Input Schema

TableJSON Schema

Name	Required	Description
`note`	No	Audit note (for audit action)
`action`	Yes	The bulk operation to perform
`fields`	No	Fields to set on every asset (for edit action): status_id, model_id, company_id, location_id/rtd_location_id, name, custom fields (_snipeit_*), etc.
`asset_ids`	Yes	IDs of the assets to operate on
`location_id`	No	Location observed during audit (for audit action)
`next_audit_date`	No	Next audit date, YYYY-MM-DD (for audit action)
`update_location`	No	Also move the assets to location_id, not just record it in the audit (for audit action)

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.6.1Aug 24, 2026

TDQS

A4.5/5.0

Behavior4/5

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

The description meaningfully adds behavioral context beyond the annotations by explaining Snipe-IT's per-asset permission checks, partial batch behavior, and the need to inspect the returned payload for per-asset results. Annotations already signal destructiveness and non-idempotency, and the description reinforces those concerns within operation details. 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description uses a compact structured format with a one-line summary, clear operation bullets, and a natively concise note about batch failure behavior and return value. There is minimal redundancy and the most important usage scope appears first.

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?

For a 7-parameter tool with two actions, the description covers the operations, endpoint paths, required parameter conditions, behavior during partial failures, and result expectations. Combined with 100% schema description coverage and an output schema, an agent has enough context to invoke the tool correctly.

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 description coverage is 100%, so each parameter is documented in the schema. The description still adds value by clarifying that 'fields' is required for the edit action and by mapping note, location_id, next_audit_date, and update_location to the audit action, which aids correct selection based on the chosen 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?

Description clearly states 'Perform bulk operations on multiple assets at once' and enumerates the two operations (edit, audit) with their specific endpoints. It distinguishes from single-asset tools by emphasizing the bulk nature and explicit action list.

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 implies this tool is for batch operations on multiple assets, while sibling tools like asset_operations handle single assets. It does not name an explicit alternative for single-asset workflows, so the usage guidance is strong but not fully explicit.

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