Skip to main content
Glama
the-real-snipeit-mcp

the-real-snipeit-mcp

PUT /maintenances/{id}

snipeit_gen_maintenances_copy
DestructiveIdempotent

Updates selected fields in an existing Snipe-IT maintenance record by ID, so you can change details like dates, cost, notes, supplier, or maintenance type without replacing the full record.

Instructions

PUT /maintenances/{id}: Update selected fields in an existing maintenance. Generated from Snipe-IT OpenAPI operation maintenances-copy.

Input Schema

NameRequiredDescriptionDefault
idYesPath parameter 'id' (not declared in the spec, synthesized by codegen)
bodyNo
confirmNoRequired when SNIPEIT_CONFIRM_WRITES=true. Exact string "YES" to apply this write.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.2

TDQS

C2.6/5.0
Behavior2/5

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

Annotations already flag destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is partly covered, but the description adds nothing: it omits the confirm="YES" write gate that the schema exposes, says nothing about what gets overwritten by a PUT, and its "selected fields" phrasing misleadingly suggests a partial update when the body requires name, asset_id, supplier_id, asset_maintenance_type and start_date.

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?

Two short sentences, front-loaded with the operation, so it is not bloated. The second sentence is low-value codegen provenance ("Generated from Snipe-IT OpenAPI operation maintenances-copy") that tells an agent nothing usable while the space would be better spent on the confirm gate.

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?

No output schema exists, so return values are out of scope, but the body contract is undocumented.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 67%, and that coverage comes almost entirely from the synthesized id and the confirm parameter; the nine body fields (cost, notes, dates, enum-valued asset_maintenance_type) carry no descriptions anywhere. The description adds no meaning about any parameter, so the gap in the body contract is not compensated.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a concrete verb+resource ("Update selected fields in an existing maintenance") but never reconciles it with the tool name's "copy" suffix, nor does it distinguish this from the many near-identical maintenance siblings (snipeit_gen_maintenances_1, snipeit_gen_maintenances_copy_1, snipeit_gen_maintenancesid). An agent can guess it is an update call, but cannot tell which maintenance-update variant to pick.

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?

There is no statement of when to use this versus snipeit_create_maintenance, snipeit_list_maintenances, or the other gen_maintenances variants, and no prerequisites are given. The 'copy' in the name hints at a distinct intent that the description leaves entirely unexplained.

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

Deploy Server

Other Tools