It is an MCP server that lets Claude query and manage a Snipe-IT asset-management instance via natural language.
Connection & discovery: check API status/credentials (snipeit_status) and explore available domains (snipeit_navigate).
Hardware/assets: list, get by ID/tag/serial, create, update, check in/out, and audit assets.
Users: list users, get user details, and view assets assigned to a user.
Locations: list locations, get location details, and view assets at a location.
Licenses: list licenses, get license details, and view seat assignments.
Reference data: list/get asset models, categories, manufacturers, and status labels, plus view assets by status label.
Filtering/pagination: most list tools support search, sorting, limit, offset, and domain-specific filters like status, category, location, company, or assignee.
Safety features: write tools use allowlisted fields, and the server strips empty/redundant response data to keep outputs compact.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Snipe-IT MCP Server list all unassigned laptops in the Austin office"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol server for Snipe-IT — lets Claude query and manage your IT assets, users, locations, licenses, and more via natural language.
Built and maintained by TEC Building Systems LLC. Community contributions welcome!
// claude_desktop_config.json (or ~/.claude/settings.json for Claude Code)
{
"mcpServers": {
"snipeit": {
"command": "npx",
"args": ["-y", "@tecpabs/snipe-it-mcp"],
"env": {
"SNIPEIT_URL": "https://your-snipeit-instance.com",
"SNIPEIT_API_TOKEN": "your-api-token-here"
}
}
}
}Get your API token from Snipe-IT → Profile → API.
Related MCP server: Snipe-IT MCP Server
Variable | Required | Description |
| Yes | Base URL of your Snipe-IT instance |
| Yes | Bearer token from your Snipe-IT profile |
| No |
|
| No | Request timeout in milliseconds (default |
Tool | Description |
| Check connection and credentials |
| Discover available domains |
Tool | Description |
| List assets with filters (status, category, location, search) |
| Get asset by ID |
| Get asset by asset tag |
| Get asset(s) by serial number |
| Check in an asset |
| Check out to user, location, or asset |
| Record an asset audit |
| Create a new asset |
| Update asset fields |
Tool | Description |
| List users |
| Get user by ID |
| List assets assigned to a user |
Tool | Description |
| List locations |
| Get location by ID |
| List assets at a location |
Tool | Description |
| List licenses |
| Get license by ID |
| List seat assignments |
Tool | Description |
| Asset models |
| Categories |
| Manufacturers |
| Status labels |
| Assets with a given status |
Note: responses are compacted before being returned to the model — null/empty fields,
available_actions, and redundantformatteddate strings are stripped, andcustom_fieldsis flattened to a simple{name: value}map. This keeps large asset lists cheap without losing information.
Use these with Claude's prompt selector:
asset-audit-report — Summarize all assets by location and status
expiring-licenses — Find licenses expiring soon
unassigned-assets — List deployable assets with no assignee
git clone https://github.com/TECPabs/snipe-it-mcp.git
cd snipe-it-mcp
npm install
npm run build
# Point Claude Code at your local build:
# command: node, args: ["D:/Claude/snipe-it-mcp/dist/index.js"]Releases are published to npm automatically by GitHub Actions when a version tag is pushed (via npm trusted publishing, so no npm tokens are stored in CI):
npm version minor # or patch / major — bumps package.json and creates the vX.Y.Z tag
git push --follow-tagsThe workflow refuses to publish if the tag doesn't match package.json, and the
prepublishOnly script runs build + tests + lint before any upload.
Use a least-privilege API token. Snipe-IT tokens inherit every permission of the
user who created them. Create a dedicated user (e.g. claude-mcp) with only the
permissions you want Claude to have — view, checkout/checkin, create/edit assets —
and generate the token from that account, not from a superadmin.
Use HTTPS. The server logs a warning at startup if SNIPEIT_URL is plain
http://, since the bearer token would be sent unencrypted.
Write tools send only their documented fields. Bodies for create, update, checkout, checkin, and audit are filtered against an allowlist, so unexpected extra arguments are never forwarded to the API.
Tools carry MCP annotations (readOnlyHint/destructiveHint) so clients can
auto-approve reads while still confirming writes.
Treat asset data as untrusted. Notes and names stored in Snipe-IT are shown to the model; anyone who can edit them can attempt prompt injection. Keep write confirmation enabled in your MCP client.
Pull requests welcome! Areas that would benefit from community help:
Accessories, consumables, and components domains
Asset maintenance records
Custom fields support (writing; reading is already flattened into responses)
Bulk operations
License seat checkout/checkin
Please open an issue first for major changes.
MIT — see LICENSE
Get a category by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; 'Get' clearly signals a read-only retrieval, but the description does not disclose return shape, error behavior such as a 404, or any data-specific caveats. It is minimally transparent but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A six-word sentence, front-loaded with the verb and resource, with zero filler. It is as concise as a definition like this can be while remaining informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter getter the description is close to adequate, but with no annotations and no output schema it omits what the call returns and how failures surface. The tool name and schema fill some gaps, but not all.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description maps the lone id parameter to the category being retrieved, which adds just enough semantic context. It does not elaborate on how to obtain or format the ID, though the schema already supplies the number type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the explicit resource 'a category' and adds ID-based scoping, clearly distinguishing it from sibling list tools like snipeit_categories_list. An agent can tell exactly what this tool does without inspecting the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by ID' implies this is for retrieving a single known category rather than browsing via categories_list, but it does not explicitly state when to prefer this tool over alternatives or exclude any cases. No when-not-to-use guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List asset categories
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | ||
| limit | No | ||
| order | No | ||
| offset | No | ||
| search | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'list' implies a read-only collection operation, which is the primary behavioral signal. However, with no annotations and no output schema, the description does not disclose default pagination, sort behavior, search scope, or the shape of the returned categories.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with no wasted words. It is arguably too terse for a tool with five parameters and no other documentation, but as a short phrase it is clean and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five parameters, no output schema, and zero annotation coverage, the description only restates the core operation. It omits pagination/filtering behavior, defaults, and return format, leaving important invocation details to be guessed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the five parameters. The parameter names like sort, limit, and offset are suggestive, but the tool provides no detail on accepted sort keys, search fields, default ordering, or offset semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact operation ('list') and resource ('asset categories') with no ambiguity. It also distinguishes itself from the sibling snipeit_categories_get by making the list-versus-detail contrast clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, how to combine search/pagination parameters, or whether to prefer categories_get for single-category lookups. An agent must infer usage entirely from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record an audit on an asset
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Audit note | |
| asset_tag | Yes | Asset tag | |
| location_id | No | Location ID where asset was found |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It says 'Record an audit' but does not explain side effects, whether it creates a new audit record, modifies an asset, or requires any special permissions. This is a meaningful gap for a write-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise, though arguably under-specified for an agent needing behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description is too thin to be complete. It fails to indicate when an audit is appropriate, what happens after recording, or how this differs from other asset mutations. The tool's low parameter count reduces complexity, but the description still leaves critical operational context unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds no additional meaning about parameter usage, but the baseline of 3 applies because the schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Record') on a specific resource ('an asset'), and the term 'audit' clearly distinguishes this from sibling tools like checkin, checkout, create, and update. It is not a tautology and gives an agent a reasonable idea of the operation's intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as snipeit_hardware_update, checkin, or checkout. The description does not mention any prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a hardware asset by asset tag
| Name | Required | Description | Default |
|---|---|---|---|
| asset_tag | Yes | Asset tag |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. The verb 'Get' implies a read-only operation, but it does not explicitly state that it is non-destructive, nor does it mention behavior on missing assets or any side effects. For a simple retrieval, this is minimally adequate, but more context (e.g., error handling) would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no superfluous words. It is front-loaded with the action and object, and the method is stated directly. This is highly efficient and appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no nested objects), the description covers the essential purpose and method. It lacks explicit routing about when to use this versus other hardware getters, but that is a usage-guidelines issue. For a straightforward get-by-tag operation, the description is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter 'asset_tag' is already described as 'Asset tag' in the schema. The description repeats this without adding format, examples, or uniqueness constraints. Since the schema does the heavy lifting, the description adds no extra meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('hardware asset') with the lookup method ('by asset tag'). This clearly indicates what the tool does and naturally differentiates it from sibling tools like snipeit_hardware_get (which presumably retrieves by ID) without explicitly naming them. It is clear but doesn't call out an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description only states what it does; it does not mention conditions like 'use when you have an asset tag' or compare with other retrieval methods. The agent must infer the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check in an asset (unassign it)
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Asset ID | |
| note | No | Optional check-in note |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only states that the action unassigns an asset, without disclosing side effects, reversibility, permission requirements, or what happens to the asset's status. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is efficient and front-loaded. It avoids extraneous detail, though it is too terse to provide full context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description should provide more behavioral and usage context. It omits return value, side effects, and any prerequisites, making it incomplete for reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions: id is 'Asset ID' and note is 'Optional check-in note'. The description adds no extra meaning beyond the schema, so baseline 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('check in') and resource ('asset'), and clarifies the action as 'unassign it', which distinguishes it from checkout. It doesn't explicitly name the sibling, but the meaning is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, such as snipeit_hardware_checkout or other asset operations. The context of 'unassign' implies use when an asset needs to be returned, but the description does not state conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check out an asset to a user, location, or another asset
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Asset ID | |
| note | No | Optional checkout note | |
| assigned_user | No | User ID to assign to | |
| assigned_asset | No | Asset ID to assign to | |
| checkout_to_type | Yes | Assignee type | |
| expected_checkin | No | Expected check-in date (YYYY-MM-DD) | |
| assigned_location | No | Location ID to assign to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits, but it only states the action and target types. It does not mention side effects (e.g., changing the asset's assignment or status), permissions required, reversibility, or what the response contains, which is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. It states the verb, resource, and targets efficiently, earning its place without extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has seven parameters and no annotations or output schema, yet the description omits important contextual details such as the conditional relationship between checkout_to_type and the assigned_* fields, and the state-changing behavior. The schema covers parameter names and types, but the description does not help an agent understand how to combine parameters correctly or what the operation does beyond the literal action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters, giving a baseline of 3. The description's mention of 'user, location, or another asset' echoes the enum and assigned_* fields but adds no new meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check out') and names the resource ('an asset') along with the three assignee types (user, location, another asset). This clearly differentiates the tool from siblings like checkin, list, get, create, and update, so an agent can identify it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrasing 'Check out an asset to...' implies when to use the tool, but there is no explicit when-to-use or when-not-to-use guidance. It does not name alternatives such as checkin or explain conditions that would select a different tool, leaving usage to be inferred from the operation name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new hardware asset
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Asset name | |
| notes | No | Notes | |
| serial | No | Serial number | |
| model_id | Yes | Asset model ID | |
| asset_tag | Yes | Unique asset tag | |
| status_id | Yes | Status label ID | |
| company_id | No | Company ID | |
| location_id | No | Location ID | |
| purchase_cost | No | Purchase cost | |
| purchase_date | No | Purchase date (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only reveals that this is a mutation operation, but does not mention uniqueness of asset_tag, validation behavior, permission requirements, or what happens if required IDs are invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every word contributes to stating the core operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the schema covers parameters, there is no output schema, no annotations, and no description of return values, side effects, or operational constraints. For a create tool with 10 parameters and several mutation siblings, this is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all 10 parameters, so the baseline is 3. The description adds no parameter-level meaning, but the schema fully covers names, types, and required fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action 'Create' and the resource 'hardware asset,' which clearly distinguishes it from sibling tools like snipeit_hardware_update, snipeit_hardware_checkin, and snipeit_hardware_list. The intent is immediately unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The only signal is the verb 'Create,' which implies adding a new asset but does not help an agent decide between this and related hardware operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a hardware asset by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Asset ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'get' without mentioning the return format, whether it's a read-only operation, or any potential errors. The agent is left unaware of what the tool returns or side effects, though 'get' implies a read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the core action. No wasted words or filler, and it is front-loaded with the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only one parameter and no output schema, the description should at least clarify what the response contains (e.g., full asset details) and how it may differ from by_tag. It fails to compensate for the missing output schema, leaving the agent with insufficient context about the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, as the single parameter 'id' is described as 'Asset ID' in the schema. The description adds no additional parameter meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States the verb 'get' and the resource 'hardware asset by ID', making the basic purpose clear. It distinguishes from list (multiple) and by_tag (which fetches by tag), but doesn't explicitly name alternatives or clarify the difference between ID and tag-based retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs the many siblings (e.g., snipeit_hardware_by_tag, snipeit_hardware_list). The description implies use when you have an asset ID, but that is left to inference rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List hardware assets with optional filters
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort field (e.g. created_at, name) | |
| limit | No | Max results (default 50) | |
| order | No | Sort order | |
| offset | No | Pagination offset | |
| search | No | Search term (asset tag, serial, name) | |
| status | No | Filter by status label name | |
| status_id | No | Filter by status label ID | |
| assigned_to | No | Filter by assigned user ID | |
| category_id | No | Filter by category ID | |
| location_id | No | Filter by location ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, and 'List' reasonably implies a read-only, non-destructive operation. It does not disclose response format, pagination behavior beyond the schema, or access considerations, but the core action is transparent and unlikely to mislead.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with no wasted words. It is concise and easy to parse, though 'with optional filters' is somewhat redundant with the schema, which prevents a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the fully documented input schema, the one-sentence description is minimally viable for making a simple list call. However, with no output schema and no annotations, it leaves the agent without guidance about result shape, when to prefer this over related hardware tools, or how the optional filters interact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all 10 parameters with useful descriptions such as 'Search term (asset tag, serial, name)' and 'Max results (default 50)'. The description adds only the generic phrase 'optional filters', which adds no parameter-level meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource, 'List hardware assets', which clearly identifies the tool's core operation and distinguishes it from sibling tools like snipeit_hardware_get, snipeit_hardware_create, or snipeit_hardware_checkin. However, it does not explicitly contrast with any named sibling, so it does not earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this list endpoint versus alternatives such as snipeit_hardware_get, snipeit_hardware_by_tag, or the related list tools. The phrase 'with optional filters' is generic and does not explain selection criteria, exclusions, or expected use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update fields on an existing asset
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Asset ID | |
| name | No | ||
| notes | No | ||
| serial | No | ||
| model_id | No | ||
| status_id | No | ||
| location_id | No | ||
| purchase_cost | No | ||
| purchase_date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only reveals that the operation mutates fields; it does not mention permissions, partial-update semantics, whether null clears fields, reversibility, or response/error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clean, front-loaded sentence with no filler or redundancy. It is concise, though the brevity comes at the cost of substantive detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with nine parameters, nearly no schema descriptions, no annotations, and no output schema, this description is far from complete. An agent would lack enough context about field semantics, required data formats, and expected behavior to call it reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 11%, with just 'id' described as 'Asset ID'. The description adds no parameter meaning, leaving eight of nine parameters with bare types and no explanation of valid values, formats, or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Update') and resource ('fields on an existing asset'), which distinguishes it from create/list/get siblings at a basic level. However, it does not enumerate the updatable fields or contrast it with checkin/checkout, which also mutate asset state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like hardware_checkin, hardware_checkout, or hardware_create. The word 'update' weakly implies modifying existing records, but there is no explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a license by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral disclosure. It only states that it gets a license by ID, implying a read operation, but omits any details about return format, error handling, permissions, or side effects. This is minimal and insufficient for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy. It is appropriately concise for a simple get-by-ID operation, conveying the essential purpose without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is too sparse. It does not mention what the response contains, any prerequisites, or how it relates to other license operations. Without an output schema or annotations, an agent is left guessing about expected results. This is a significant gap for a tool that should be straightforward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'id' parameter with 0% description coverage. The description clarifies that the parameter is the license's ID, which adds meaning beyond the bare schema. However, it does not elaborate on ID format or constraints, so it only partially compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a license by ID' clearly states the action (get) and resource (license) with an identifier qualifier. It differentiates from siblings like snipeit_licenses_list and snipeit_licenses_seats by specifying retrieval of a single record. However, it does not explicitly name the alternatives, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings. It does not mention when to use list, seats, or how to decide. There is no context, prerequisites, or exclusions. This leaves the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List software licenses
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | ||
| limit | No | ||
| order | No | ||
| offset | No | ||
| search | No | ||
| company_id | No | ||
| category_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'List' implies a read operation, but the description does not mention pagination, default ordering, whether associated seats or company/category details are included, or any other behavioral nuance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clutter-free sentence with the purpose front-loaded. It is concise, though it achieves that conciseness by omitting useful usage and behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with seven optional parameters, no output schema, and no annotations, this description is too sparse. An agent gets no information about filtering, pagination semantics, response shape, or how this list relates to the other license tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to any of the seven parameters. While names like sort, limit, and search are somewhat self-explanatory, the description itself contributes nothing beyond the schema field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
'List software licenses' clearly states a verb and resource, and the collection-oriented wording distinguishes it from licenses_get and licenses_seats. It does not explicitly contrast itself with siblings, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as licenses_get or licenses_seats. There is no mention of prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all seats for a license (who has it assigned)
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | License ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'List' clearly signals a read-only collection operation and 'who has it assigned' hints at the result content, but nothing is said about pagination, response format, authentication requirements, or error behavior. This is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It states the action, resource, and output meaning in under ten words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup tool, the description is nearly complete: the agent knows what to do, which ID to pass, and what the result represents. The only gaps are minor and expected for a simple list endpoint, such as pagination or detailed seat fields, and there is no output schema to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage by describing the single required parameter 'id' as 'License ID.' The description adds no new parameter semantics beyond reiterating that seats belong to a license, so it stays at the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List all seats for a license.' The parenthetical '(who has it assigned)' clarifies the output's meaning and distinguishes this from sibling tools like snipeit_licenses_list and snipeit_licenses_get, which operate on licenses themselves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied: this is the tool to use when you need the assignment information for a license. However, it does not explicitly state when not to use it or name alternative tools, leaving the agent to infer the routing from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List assets at a location
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Location ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'List' weakly implies a read operation, but the description does not disclose pagination behavior, response shape, whether assets are inherited or direct assignments, or any other runtime traits. This is a meaningful gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with zero filler. Every word contributes to understanding what the tool does, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter listing tool, the description is minimally viable, but it lacks detail about the result set: does it include paginated results, full asset objects, or only basic metadata? With no output schema and no annotations, a bit more context about what 'assets at a location' returns would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage: the only parameter, id, is documented as 'Location ID'. The description adds no additional meaning beyond that schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: list assets, scoped to a location. This distinguishes it from sibling tools like snipeit_hardware_list (all assets), snipeit_locations_get (location details), and snipeit_locations_list (all locations). The verb-resource-scope structure is exact and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'at a location' implies the primary use case: when an agent needs assets associated with a specific location. However, it does not explicitly contrast with alternatives such as snipeit_hardware_list or mention when not to use this tool, so guidance is merely implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a location by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether the operation is read-only, what happens if the ID is not found, or any other behavioral traits. The description adds no value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with one parameter and no output schema, the description is adequate to invoke it, but it omits any mention of the return format or error behavior. Given the low complexity, this is a minor gap, but it could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'by ID', which clarifies that the single 'id' parameter is the identifier. However, schema description coverage is 0%, and the description does not add further detail about the parameter's format or constraints. For a trivial single parameter, this is minimally sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get) and the resource (location) with a specific scope (by ID). It distinguishes itself from sibling tools like snipeit_locations_list and snipeit_locations_assets, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions. An agent must infer that it's for fetching a single location by ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all locations
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | ||
| limit | No | ||
| order | No | ||
| offset | No | ||
| search | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'List all locations' and omits details like pagination behavior, default limits, authentication requirements, or whether the 'all' claim is affected by the limit and offset parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, and the primary action is front-loaded. It is concise, though it may be too terse given the number of parameters and lack of other documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five optional parameters, no output schema, no annotations, and only a one-line description, the tool is not fully specified. An agent would lack critical information about filtering, pagination, result shape, and how this tool relates to sibling location tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description gives no explanation of the five parameters. Parameter names like sort, limit, order, offset, and search are somewhat self-explanatory, but the description adds no meaning about accepted values, defaults, or how they interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all locations' uses a specific verb and resource, making the core operation clear. It is distinguishable from sibling tools like snipeit_locations_get and snipeit_locations_assets by the resource and action, though it does not explicitly differentiate them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as snipeit_locations_get or snipeit_locations_assets. The description provides no context for choosing it over other list tools or related location endpoints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a manufacturer by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations to communicate safety or side effects, so the description carries the burden of behavioral context. 'Get' suggests a read operation, but it does not disclose whether the operation is strictly read-only, what error behavior exists, whether authentication is needed, or what a requestor should expect on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler. It puts the core purpose up front, but it is under-specified in useful surrounding context rather than being optimally scoped.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter getter the description is usable, but with no annotations, no output schema, and no sibling differentiation, it does not fully equip an agent to know what it will receive, when to prefer it, or what requestor constraints apply.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'id', is documented in the schema with type number and required true, and the description merely restates that it is looked up by ID. This adds minimal semantic value beyond the schema's own property name and does not explain the origin/meaning of the ID, whether it is a database ID or a custom code, or expected value format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: get a single manufacturer by ID. It is not a tautology and it is readily distinguishable from a list-style tool like snipeit_manufacturers_list, though it does not explicitly mention that distinction in words.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose this tool over alternatives, when not to use it, or what circumstances make it appropriate. The phrase 'by ID' weakly implies it is for known-ID lookups, but the description does not state this or contrast it with sibling lookup tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List manufacturers
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | ||
| limit | No | ||
| order | No | ||
| offset | No | ||
| search | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but 'List manufacturers' only conveys a read-like listing operation. It does not disclose default ordering, limit behavior, pagination, or what the response contains, leaving significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and has no filler, but this is under-specification rather than effective conciseness. It omits essential context that an agent needs to use the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given five optional parameters, no output schema, and no annotations, a two-word description is insufficient. The agent has no idea about default behaviors, result shape, or how parameters interact, so the definition is not complete enough for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining any of the five parameters. No meaning is added for sort, limit, order, offset, or search beyond their bare names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete verb ('List') and a specific resource ('manufacturers'), so the core action is unambiguous. It does not explicitly contrast with snipeit_manufacturers_get, but the list/get distinction is implied by the verb and naming pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus snipeit_manufacturers_get or other manufacturer-related tools. No mention is made of filtering, pagination, or typical use cases; the only implicit signal is that this tool returns a list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an asset model by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. 'Get' clearly signals a read-only retrieval rather than a mutation, but it does not disclose response shape, error behavior, permissions, or other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is six words with no filler. It front-loads the action and target, and every word adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter getter with no output schema, the description provides the essential call context: retrieve one asset model by ID. It is terse but adequate, and nothing critical is missing for a tool this simple.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions and 0% coverage, so the description partially compensates by clarifying that the 'id' parameter is the asset model's ID. It does not add further detail about the value's source or expected format beyond the schema's number type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Get'), a specific resource ('asset model'), and the retrieval criterion ('by ID'), making it distinct from snipeit_models_list which would return multiple models. An agent can immediately tell this is a singular lookup tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'by ID' phrasing implies the tool should be used when the caller already knows a specific model ID. However, it does not explicitly say when not to use it or name the list alternative that should be used for discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List asset models
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | ||
| limit | No | ||
| order | No | ||
| offset | No | ||
| search | No | ||
| category_id | No | ||
| manufacturer_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'List' hints at a read-only operation, but the description does not disclose whether the result is paginated, what default ordering/limit applies, or whether search/category_id/manufacturer_id are filters vs exact matches. This leaves key runtime behavior unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal and front-loaded, but it is under-specified rather than efficiently sized. A three-word description cannot carry the behavioral and parameter context needed for a seven-parameter API, so brevity becomes a gap.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and zero parameter documentation, the description is materially incomplete: it does not state what fields are returned, how pagination works, or how filters combine. An agent would have to guess or probe the API to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no parameter meaning; it repeats only the 'asset models' resource. With seven parameters and no schema documentation, the agent receives no help on what sort, limit, offset, search, category_id, or manufacturer_id do.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('List') and resource ('asset models'), clearly identifying the operation as an enumeration of model records. It is distinguishable from the sibling snipeit_models_get ('get' singular), but it does not articulate any scope or exclusions, so it is not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no context for when to choose this tool over alternatives such as snipeit_models_get, snipeit_hardware_list, or snipeit_categories_list. There is no mention of typical use cases, filtering, or pagination strategy, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check Snipe-IT connection status and API credentials
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description carries the full behavioral burden; it does convey that the tool performs a non-mutating connection/credential check, but it does not explicitly state read-only behavior, what a successful or failed check looks like, or whether credentials are validated against the API. This is adequate but not deeply transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence contains exactly the necessary information: what is checked and against which system. There is no filler or redundant restatement of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter diagnostic tool with no output schema, the description is close to sufficient, but it stops short of describing the expected result shape (e.g., status fields, credential-validity indicator). The absence of annotations and output schema makes that missing return-context a real, though small, gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema-description coverage, so the baseline is 4. The description adds no parameter details, but none are needed for a parameterless health-check tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and resource ('Snipe-IT connection status and API credentials'), making it immediately distinguishable from the data-operation siblings like snipeit_hardware_list or snipeit_users_get. There is no ambiguity about what this tool is for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The wording positions this as a diagnostic/health-check tool, creating clear context for when an agent would invoke it (verifying connectivity or credential validity), while no explicit exclusions or alternative names are needed because no sibling performs this function. It does not say 'use before other calls,' but the diagnostic role is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List assets with a given status label
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Status label ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. 'List' implies a read-only, non-destructive operation and 'with a given status label' conveys the filtering behavior. Still, it does not disclose pagination, auth expectations, or the shape of the returned asset list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single concise sentence that directly states the tool's action and scope with no filler. Every word contributes value, and the core behavior is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list operation with no output schema, this is generally complete: an agent knows to supply a status label ID and expect a list of assets. Minor missing details are pagination and exact asset field shape, but they are not critical given the tool's simplicity and sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the only parameter ('Status label ID') at 100% coverage. The description does not add meaningful semantic detail beyond the schema; it just references the status label concept.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') tied to a clear resource ('assets') and a specific filter ('with a given status label'). This clearly distinguishes it from sibling tools like snipeit_statuslabels_list (list status labels), snipeit_statuslabels_get (get one label), and snipeit_hardware_list (list all assets).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: call this when you want assets associated with a particular status label ID. However, it does not explicitly state when not to use it or mention alternatives such as snipeit_hardware_list or snipeit_users_assets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a status label by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only restates the operation conveyed by the tool name. It does not mention what happens for nonexistent IDs, whether permissions are required, read-only guarantees, or the response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. It conveys the resource and operation immediately, making it easy to scan and process.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and no parameter documentation, leaving the agent without information about return values, failure behavior, or usage context. The simplicity of the tool mitigates this somewhat, but the overall context is still quite thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the meaning of the id parameter beyond the phrase 'by ID'. Since the schema only exposes id as a number, the description adds little semantic value beyond what can be inferred from the property name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get), resource (status label), and selection criterion (by ID), which clearly distinguishes it from list-oriented siblings like snipeit_statuslabels_list. It does not name the sibling explicitly, but the 'by ID' qualifier makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of snipeit_statuslabels_list or snipeit_statuslabels_assets. There are no prerequisites, exclusions, or fallback instructions, so the agent must infer usage solely from the name and phrasing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List status labels
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | ||
| limit | No | ||
| order | No | ||
| offset | No | ||
| search | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only says 'List status labels' – no mention of pagination, sorting, authentication, rate limits, or return structure. It does not contradict annotations (none exist), but it provides essentially zero behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase with no waste, but it is under-specified rather than appropriately concise. For a tool with five parameters and no other documentation, this brevity is a deficiency, not a strength.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the five-parameter schema, no output schema, and no annotations, the description is woefully incomplete. It omits any information about expected input formats, response behavior, or how it differs from similar list tools. An agent would have to guess or inspect the schema, which itself lacks descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to any of the five parameters (sort, limit, order, offset, search). An agent cannot infer what each parameter does or how to format values, so the tool is effectively unusable without external knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action 'List' and the resource 'status labels', making the core purpose clear. It does not explicitly differentiate from sibling tools like snipeit_statuslabels_get or snipeit_statuslabels_assets, but the verb 'list' implies a collection operation distinct from singular get or asset queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention any prerequisites, filtering strategies, or typical use cases, leaving the agent to infer from the name alone that it is for enumerating status labels.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all assets assigned to a user
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | User ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. The verb 'List' makes it clear this is a read-only retrieval, but the description does not disclose response shape, pagination behavior, or whether historical assignments are included. This is acceptable for a simple read operation but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler. The core purpose is front-loaded and every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool, the description and schema are largely sufficient to invoke it correctly. The absence of an output schema and annotations means some details are missing, but the low complexity keeps this from being a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the property 'id' is already documented as 'User ID'. The description reinforces the user context but adds no additional parameter-level meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('assets assigned to a user'), which clearly differentiates this from sibling tools like snipeit_hardware_list or snipeit_locations_assets. The user scope is explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when you need all assets assigned to a specific user, but it does not explicitly mention alternatives or when-not-to-use cases. It provides no comparison to sibling tools like snipeit_users_get or snipeit_hardware_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a user by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description must carry the burden of disclosing behavioral traits. It does not state whether the operation is read-only (though 'Get' implies it), nor does it mention error handling (e.g., what happens if user not found), authorization requirements, or response format. This is a simple getter, but without annotations, more context is needed to fully inform the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It is appropriately front-loaded with the verb and resource. It is under-specified but not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with only one parameter and no output schema, the description is mostly sufficient: it tells the agent exactly what to call and with what. However, given the lack of annotations and no explanation of return value or error behavior, it is not fully complete. The tool is simple, so a 3 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'id' of type number, which is self-explanatory. The description adds the phrase 'by ID' which clarifies that the 'id' parameter is the user's identifier, but this is already implied by the parameter name and the type. With 0% schema description coverage, the description should compensate, but it does not add significant meaning beyond what the schema already conveys (e.g., it doesn't state that the ID is the Snipe-IT user ID, or if it's a numeric database ID). Thus, the description adds only marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and resource ('a user'), and the 'by ID' qualifier distinguishes it from snipeit_users_list, which presumably retrieves multiple users. However, it does not explicitly differentiate from other getters like snipeit_locations_get, but the resource is clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. It is implied that you use it when you have a user ID and need a single user's details, but no alternatives are named (e.g., snipeit_users_list for multiple users) and no exclusions are stated. The agent must infer usage from the 'by ID' qualifier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List users with optional search/filter
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | ||
| limit | No | ||
| order | No | ||
| offset | No | ||
| search | No | Search by name, username, or email | |
| company_id | No | ||
| location_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are entirely absent, so the description carries the full burden of behavioral disclosure. It discloses none of the relevant behavior for a list tool — pagination defaults, result format, whether the response is a user list with fields, or how sort/order/offset behave. The description is not misleading, but it adds no behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that puts the verb and resource first with no wasted words. It trades completeness for brevity, but the line itself is well-structured and directly readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 7-parameter list tool with no annotations and no output schema, so the description must carry a great deal of context. It does not describe the return value or result fields, pagination defaults, or any sorting/filtering behavior; complexity and gaps require much more than a 7-word description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14% (just the 'search' param), so the description must compensate for the other six parameters. It only offers 'search/filter', which loosely hints at search/company_id/location_id but gives no meaning for sort, limit, order, or offset, and no detail on how filtering works.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource — 'List users' — with a scope modifier ('optional search/filter'). It is implicitly distinct from sibling tools like snipeit_users_get (single user) and snipeit_users_assets (assets), but it does not explicitly name them or call out the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to choose this tool over alternatives such as snipeit_users_get or snipeit_users_assets. The 'optional search/filter' phrase only implies the use case; it never states when-not-to-use or points to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0snipeit_categories_getsnipeit_categories_listsnipeit_hardware_auditsnipeit_hardware_by_tagsnipeit_hardware_checkinsnipeit_hardware_checkoutsnipeit_hardware_createsnipeit_hardware_getsnipeit_hardware_listsnipeit_hardware_updatesnipeit_licenses_getsnipeit_licenses_listsnipeit_licenses_seatssnipeit_locations_assetssnipeit_locations_getsnipeit_locations_listsnipeit_manufacturers_getsnipeit_manufacturers_listsnipeit_models_getsnipeit_models_listsnipeit_navigatesnipeit_statussnipeit_statuslabels_assetssnipeit_statuslabels_getsnipeit_statuslabels_listsnipeit_users_assetssnipeit_users_getsnipeit_users_listScored across 28 tools
Tools are clearly namespaced by resource and action, so hardware, users, locations, licenses, and status labels are easy to distinguish. The only mild overlaps are hardware_get versus hardware_by_tag and resource-specific asset listing versus hardware_list, but the descriptions clarify the different identifiers and filters.
The dominant pattern is snipeit_<resource>_<action>, which is applied consistently across most tools. Exceptions like snipeit_status, snipeit_navigate, and snipeit_hardware_by_tag break the strict pattern but are still intuitive and do not create confusion.
28 tools is heavy for an MCP server, but the breadth of Snipe-IT domains—hardware, users, locations, licenses, models, categories, manufacturers, and status labels—partly justifies the count. Still, many resources only have list/get pairs, which inflates the surface without adding much capability.
Hardware lifecycle coverage is strong with create, update, read, checkin, checkout, and audit. However, users, locations, licenses, models, categories, manufacturers, and status labels are mostly read-only, so the server cannot fully manage the asset database or create new assignable entities.
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
WHOOP recovery, strain, sleep and workouts in Claude via official WHOOP OAuth. Free, open source.
Connect Claude to Fathom meeting recordings, transcripts, and summaries
Connect your team's living knowledge base — docs, data, issues, CRM — to Claude and ChatGPT.
