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

the-real-snipeit-mcp

PUT /licenses/{id}

snipeit_gen_licensesid_1
DestructiveIdempotent

Update an existing Snipe-IT software license by ID with fields such as category, seats, supplier, purchase, expiration, and contact details to keep license records accurate.

Instructions

PUT /licenses/{id}: /licenses/:id. Generated from Snipe-IT OpenAPI operation licensesid-1.

Input Schema

NameRequiredDescriptionDefault
idYesID (not name) of license being updated
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

D1.5/5.0
Behavior1/5

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

Annotations declare destructiveHint=true, idempotentHint=true, openWorldHint=true, readOnlyHint=false, so the description should explain what a destructive PUT on a license actually does (overwrites fields, partial vs full replace, category_id required). Instead it adds zero context beyond the annotations and the 'Generated from OpenAPI operation' note, which tells the agent nothing about behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

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

It is short, but every sentence is filler: a repeated path and a provenance note. Brevity here comes from under-specification, not economy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

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

A destructive mutation tool with a nested 18-field body, no output schema, and only 67% schema coverage. The description provides nothing about return behavior, required vs optional body fields, or the confirm gate — far below what an agent needs to call it safely.

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 the id and confirm parameters are documented in the schema itself. The description adds no meaning to the large nested body (18 fields, category_id required) and says nothing about the confirm=YES write gate, which is a non-obvious operational requirement worth surfacing in prose.

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

Purpose2/5

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

The description is essentially the tool name and title restated: 'PUT /licenses/{id}: /licenses/:id.' Only the HTTP verb implies an update; no resource domain (licenses) semantics, no statement of what updating a license entails, and no differentiation from the many sibling license tools (snipeit_gen_licensesid, _2, _3, seats variants).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance, no alternatives named, no prerequisites. Given ~10 license-related siblings, the agent gets no routing signal at all.

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