snipeit-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools map to a distinct resource and action, like get_asset, list_assets, create_asset. The only close pair is assign_license_seat_to_asset and assign_specific_license_seat_to_asset, but their descriptions clearly differentiate auto-selection vs. explicit seat ID.
Naming Consistency5/5
All tools follow a consistent snake_case verb_noun pattern (get, list, create, check, assign, unassign). Even compound targets like list_license_seats and assign_license_seat_to_asset fit the pattern cleanly.
Tool Count4/5
At 16 tools, the set is slightly above the ideal 3-15 range, but the scope justifies it: assets, licenses, users, and reference data (categories, locations, models) are all covered. No bloat or redundant tools beyond the closely related seat assignment pair.
Completeness3/5
Core asset and license workflows are covered (create, get, list, license seating), but major gaps exist: no update_asset, delete_asset, asset checkin/checkout, or license update/delete. User management is limited to read-only, and reference data cannot be modified.
Average 3.2/5 across 16 of 16 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
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 says 'register an asset' and lists required fields, which simply repeats schema information. It does not mention side effects, permissions, failure modes, or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence in Japanese, which is concise and front-loaded. It contains no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, output schema, and parameter explanations, the description is severely underspecified for a tool with 9 parameters. It fails to provide enough context for an agent to use the tool correctly or anticipate its behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 9 parameters with 0% coverage from the description. The description only echoes the three required parameters without explaining their meaning or providing context for optional fields like purchase_cost or location_id. This does not compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'registers an asset' (資産を登録します), which is a specific verb and resource. It does not explicitly differentiate from sibling create tools like create_license, but the asset focus is clear from context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as creating a license or updating an asset. The only hint is the tool name and the required fields, which are already visible in the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'get user details' without disclosing potential side effects, permissions, rate limits, or behavior on missing/invalid IDs. For a read operation, it is minimally transparent but lacks context beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, immediately front-loaded with the core action and resource. It is appropriately sized for a simple get operation and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no output schema), the description provides the essential purpose but lacks usage guidance and behavioral context. It is adequate for a trivial get but leaves gaps around when to use and potential error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required integer parameter 'user_id' with 0% description coverage. The description mentions 'ID' but adds no new meaning beyond what the schema already shows—it does not clarify the expected format, constraints, or how the ID relates to the user. The description merely echoes the schema field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and the resource 'user details', with the ID as the key parameter. It distinguishes from sibling 'list_users' by indicating a specific ID-based retrieval, but does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no explicit guidance on when to use this tool versus alternatives like list_users. It implies you need an ID, but does not state when this tool is preferred, any prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the limit maximum of 100, which is useful, but does not explain search semantics, pagination behavior, or return format, leaving significant gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that delivers both purpose and a key parameter constraint. It is appropriately sized for a simple list tool with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with three parameters and no output schema, the description is too sparse. It lacks explanation of offset and search behavior, pagination details, and return value structure, making it insufficient for an agent to fully predict tool behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that 'limit' has a maximum of 100, but 'offset' and 'search' remain undocumented in both schema and description, forcing the agent to guess at their meanings and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search and list licenses' with a clear verb and resource, effectively distinguishing it from other list tools by targeting licenses specifically. However, it doesn't explicitly differentiate among sibling list tools like list_license_seats, though the resource term 'licenses' provides sufficient clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_license_seats or list_assets. The description does not mention use cases, prerequisites, or exclusions, leaving the agent to infer appropriate usage entirely from the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full behavioral burden. It merely says 'search and list' without disclosing pagination behavior, search semantics, or confirming that the operation is read-only with no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff, front-loading the action. It is appropriately short for a simple list operation, though it lacks some substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the three parameters and the absence of annotations or an output schema, the description is incomplete. It doesn't explain how search works, what the response looks like, or how limit/offset are applied, making it insufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes limit, offset, and search parameters, but the description offers zero explanation about them. With schema description coverage at 0%, the description does nothing to compensate for the lack of parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'ロケーションを検索・一覧表示します。' clearly states the tool's function as searching and listing locations. The resource 'locations' is specific and distinct from sibling tools like list_assets or list_categories, making 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.
Usage Guidelines2/5
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 the many sibling tools (e.g., list_assets, list_categories). There are no explicit use cases, alternatives, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It only says 'registers a license' and lists required fields. It does not disclose side effects like record creation into a persistent store, potential validation errors, or whether the operation is idempotent. No return value or failure behavior is mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences. It gets straight to the point and repeats no fluff. The required-field note is front-loaded and useful, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, no output schema, and no annotations, this description is incomplete. It omits what happens on success (e.g., returns the created license ID), potential error conditions, and any special constraints like uniqueness of name. The schema provides structure but not context about the operation's lifecycle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only repeats that name, seats, and category_id are required, which is already in the schema's required array. It does not explain the meaning of any parameter or touch on the optional fields (notes, serial, purchase_cost, etc.). With schema description coverage at 0%, the description adds minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'ライセンスを登録します' (registers a license), which is a specific verb+resource. It also notes the required fields, distinguishing it from license-related read or assignment tools. Purpose 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.
Usage Guidelines1/5
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 alternatives. It does not mention situations where another tool would be more appropriate, nor does it describe the context for creating a license. Sibling tools like 'assign_license_seat_to_asset' exist, but no distinction is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 fails to explain search semantics (e.g., partial matching, case sensitivity), pagination behavior, or confirm that the operation is read-only. The description adds no behavioral context beyond the tool name and action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in Japanese with no redundancy. It is efficiently written, though it could be more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description must be self-sufficient. A single phrase about searching and listing categories is inadequate for a tool with three parameters, as it omits return format, pagination details, and search behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 any of the three parameters (limit, offset, search). It does not compensate for the lack of schema documentation, leaving the agent to rely solely on parameter names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'カテゴリを検索・一覧表示します' which clearly indicates searching and listing categories. It uses a specific verb (search/list) and resource (categories), distinguishing it from sibling list tools like list_assets or list_models based on the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. The resource 'categories' implies a specific use case, but there is no context about prerequisites, exclusions, or conditions where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the basic mutation (unassign) but does not mention side effects, permission requirements, failure conditions, or whether the operation is reversible. The lack of behavioral detail is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the core purpose. No unnecessary words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema and no annotations, the description is too minimal. It does not address the dual nature (asset vs user) or how the operation is executed, leaving the agent uncertain about the exact behavior and response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It mentions 'asset or user' but does not map these to the available parameters (license_id, seat_id), leaving ambiguity about how the target is specified. The note parameter is not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'unassign' and the resource 'license seat', specifying that it removes the assignment from an asset or user. This distinguishes it from sibling assignment tools like assign_license_seat_to_asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit when-to-use guidance or mention of alternatives. It implies its use for unassigning seats but does not clarify when to choose this over other tools or what prerequisites exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While 'Gets the details' implies a read-only operation, it does not state whether this is safe, what happens if the asset ID does not exist, whether authentication is required, or any rate limits. The description adds no behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no unnecessary words. It front-loads the verb and resource, making it immediately scannable. Ideal conciseness for a simple get operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), and the description states the core operation. However, it lacks any information about return format, error behavior, or field details, which are not covered by schema or annotations. It is minimally adequate but leaves gaps for an agent that needs to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate for parameter meaning. It mentions 'ID' generically, but only repeats what is already evident from the property name 'asset_id' and the type integer. It does not explain the ID's format, whether it is a database identifier, or any constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Gets the details') and the resource ('asset') with a specific parameter ('by specifying ID'). It distinguishes from sibling tools like list_assets (lists assets) and get_license/get_user (other get tools) by clearly targeting a single asset by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_assets or get_license. It does not mention any prerequisites, exclusions, or scenarios where another tool would be more appropriate. This is a clear gap for a tool with many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses only the basic action (getting details) and offers no additional behavioral context like error handling, authentication requirements, or return format. There is no mention of what happens if the ID does not exist, which is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and free of unnecessary detail. It conveys the essential action and argument efficiently, with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a one-parameter tool, the description is still incomplete. It does not specify what the 'details' encompass, nor does it clarify response structure or error behavior. Given that sibling tools include list_licenses and other license operations, more context would help select and invoke the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'IDを指定して' (specifying an ID), but does not add semantic meaning beyond the schema's 'license_id' integer field. It does not explain that the ID is the unique license identifier, nor does it provide constraints or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'IDを指定してライセンスの詳細を取得します' which clearly identifies a specific verb ('get') and resource ('license details') with a required parameter (ID). It effectively distinguishes from siblings like list_licenses and get_asset by indicating it retrieves one license.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the context of sibling tools (e.g., list_licenses for listing, get_license for single retrieval), but the description does not explicitly state when to use this tool over alternatives or provide any exclusionary guidance. It lacks explicit context such as 'use when you have a license ID'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It does state that the limit has a maximum of 100, which is a useful constraint. However, it does not disclose whether the operation is read-only, whether pagination via offset is supported, or what the return structure looks like. The description is adequate but minimal for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the purpose and includes a key constraint. Every word earns its place, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and 3 parameters, the description is far from complete. It fails to mention return format, pagination behavior (offset), or search semantics. An agent would struggle to know what to expect from the response or how to appropriately set the search parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains the 'limit' parameter (max 100), leaving 'offset' and 'search' with no added meaning. The word 'search' in the description hints at the search parameter but does not clarify its behavior (e.g., partial vs exact match). This is insufficient for a 3-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search and list users' with a specific verb (search/list) and resource (users), distinguishing it from the sibling 'get_user' which implies a single user lookup. The mention of 'limit' further clarifies it's a list operation with a cap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives like 'get_user'. It does not mention exclusions or prerequisites. The only contextual hint is the limit constraint, but this does not help the agent decide between list_users and get_user.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It reveals the algorithmic behavior of selecting the smallest available seat, which is useful. However, it does not disclose edge cases such as what happens when no seats are available, whether existing assignments are overwritten, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core behavior. It contains no unnecessary words and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema, the description does not explain return values, error conditions, or prerequisites. It covers the core assignment logic but leaves out important contextual details that an agent would need to handle failures or verify success.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters' meanings beyond their names. It mentions asset and seat but does not clarify the role of license_id or the optional note parameter. This is insufficient compensation for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it automatically selects the available seat with the smallest seat number and assigns it to an asset. This specific behavior distinguishes it from the sibling tool assign_specific_license_seat_to_asset, which requires specifying a particular seat.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you want automatic seat selection) but does not explicitly mention the alternative of assigning a specific seat or provide exclusions. The sibling name hints at the alternative, but the description itself lacks explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It adds a useful constraint that limit is capped at 100 (limitは最大100件です), but it does not disclose return format, pagination behavior beyond offset/limit, or whether the operation is read-only (though 'list' implies this). Some behavioral context is present, but key details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the tool's primary purpose and the key limit constraint. Every word earns its place, with no irrelevant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description needs to explain what the tool returns and how search/pagination work. It only mentions the limit cap, leaving offset semantics, search behavior, and return shape undocumented. This is incomplete for a tool with three parameters and no structured output definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains the limit parameter (max 100) and leaves offset and search undefined. This adds partial value for one parameter but fails to clarify pagination offset or what the search parameter searches (e.g., asset name, ID, tags).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches and lists assets (資産を検索・一覧表示します), which is a specific verb-resource combination. It distinguishes from sibling tools like get_asset (single asset) and list_categories/list_locations (other resource types).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied from the tool name and sibling context: use this to search/list assets, while get_asset is for a single asset. However, the description does not explicitly state when to use this tool versus alternatives or mention any exclusions, so it stops at implied guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'Search and list' clearly indicates a read-only operation, which is adequate for a simple listing tool. However, it does not disclose pagination behavior, return format, or any potential side effects. For a lightweight read tool, this is minimally acceptable 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the core purpose. There is no wasted prose or unnecessary detail, making it highly efficient for the agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and 0% parameter descriptions. The one-line description does not elaborate on return values, pagination behavior, search semantics, or when to use this tool over siblings. For a listing tool with three parameters and no structured documentation, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The description mentions 'search' generically but does not explain how the 'search' parameter works, what fields it matches, or the meaning of 'limit' and 'offset' beyond their name-based intuition. The schema itself has no descriptions, leaving the agent to guess parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '資産モデルを検索・一覧表示します' clearly states the tool searches and lists asset models, using specific verbs (search/list) and a specific resource (asset models). It distinguishes from siblings like list_assets (which likely lists assets, not models) and get_asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching/listing asset models but does not explicitly state when to prefer this over alternatives like list_assets or get_asset. The intent is understandable from the name and description, but no exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description carries the full burden for behavioral disclosure. The description only states the action and the norm to use the auto-select tool, but does not disclose any side effects, prerequisites, error conditions, or required permissions. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action and a clear usage recommendation. Every sentence earns its place without unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no output schema, and no annotations. The description is very brief and omits critical context such as return values, error handling, and prerequisites. Given the mutating nature of the tool, the description is incomplete for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must explain parameters. It clarifies seat_id (specific) and asset_id (target), but does not explain license_id or note. Since 3 required params are only partially explained, the description does not compensate for the missing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it assigns an explicitly specified unique Seat ID to an asset. It distinguishes from the automatic selection tool by saying '通常は自動選択ツールを使用してください', implying this is for specific seat assignments. This gives a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states '通常は自動選択ツールを使用してください' (normally use the automatic selection tool), which is a clear recommendation for when not to use this tool. This works as a usage guideline despite not naming the sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It states the core behavior (checking connection and authentication), which implies a non-destructive health check. However, it does not specify whether the operation makes network requests, what happens on failure, or whether any authorization is required. This is adequate for a simple check but lacks richer detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that squarely addresses the tool's purpose. There is no redundant information, fluff, or irrelevant detail. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a very simple tool with zero parameters and an output schema. The description sufficiently states the tool's purpose. While it could add a note about typical usage contexts (e.g., 'Use this to verify API credentials before other calls'), that is more of a usage guideline and not strictly necessary for completeness given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics to clarify. The schema already covers this with 100% coverage (trivially). The description adds nothing about parameters because none exist, which aligns with the baseline of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Check the connection and authentication to the Snipe-IT API.' This is a specific verb ('check') with a resource ('connection and authentication to the Snipe-IT API'), and it clearly distinguishes itself from sibling tools that focus on CRUD operations for assets, licenses, users, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical scenarios (e.g., troubleshooting connectivity before making other API calls), or any exclusions. The only context is the tool name itself, but no explicit usage advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides some behavioral context: it returns all seats in a specific order and supports an available-only filter. It does not mention return format, pagination, or any side effects, but as a read operation, the risk is low.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, two sentences, with the primary action and key filter stated front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with only two parameters and an output schema, the description covers the main functionality, ordering, and filtering. It could mention additional details like whether assigned seats are included, but overall it is fairly complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly explains the available_only parameter (filter to empty seats) and implies the license_id through the concept of 'license'. However, license_id itself is not elaborated beyond the schema, and schema coverage is 0%, so partial compensation only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (retrieves), the resource (license seats), and the ordering (by seat number). It also mentions an optional filter for available seats, distinguishing it from related assignment tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for reading license seats, especially given the sibling tools (assign/unassign). However, it does not explicitly state when to use this tool versus alternatives like get_license or list_licenses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![snipeit-mcp MCP server](https://glama.ai/mcp/servers/chiku-wa/snipeit-mcp/badges/card.svg)](https://glama.ai/mcp/servers/chiku-wa/snipeit-mcp)

Score Badge

Copy to your README.md:

[![snipeit-mcp MCP server](https://glama.ai/mcp/servers/chiku-wa/snipeit-mcp/badges/score.svg)](https://glama.ai/mcp/servers/chiku-wa/snipeit-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/chiku-wa/snipeit-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server