This server exhibits severe definition quality issues across all 40 tools. Every single tool has identical, trivial input schemas (only 'action' parameter as a string with minimal description) and generic descriptions that provide no semantic guidance. The architecture uses a dispatch pattern where 'action' is a free-form string, not validated enums, which invites hallucination and misuse. Tools lack parameter descriptions entirely, the 'action' parameter description 'The action to perform' is generic across all 40 tools and provides no specificity about valid values, dependencies, or expected format. No output schemas are documented anywhere in the codebase. Error handling is invisible in the tool definitions. This is a pattern:tool and pattern:tool-description violation on a massive scale. The tool naming itself is problematic: 'manage_assets', 'asset_operations', 'bulk_asset_operations' are overlapping and unclear, the LLM cannot distinguish when to use each. 'manage_*' names are vague (does it create, update, delete, or list?). Tools like 'manage_imports' and 'manage_backups' lack any indication of what permissions they require or what side effects they have.
No input schemas visible for any tool. All 40 tools show only a single 'action' parameter as type string with trivial description. Per HARD SCORING RULE, schema score must be 0 for all tools.
Replace the dispatch pattern with per-action tools: instead of 'manage_assets' with action='create|update|delete|list|get', split into 'create_asset', 'update_asset', 'delete_asset', 'list_assets', 'get_asset'. Each tool name clearly describes what it does.
For each tool, write a substantive description (50-200 chars) that answers: What does it do? When should I call it? What does it return? Example: 'create_asset: Creates a new asset in Snipe-IT and returns the asset_id, serial_number, and status. Call this to add a newly acquired device to inventory.'
Document input schemas completely: list all parameters (not just 'action'), their types, descriptions, enums (for constrained values), and defaults. Example: 'asset_name (string, required, 2-255 chars): Name of the asset; asset_status (enum: 'ready', 'checked-out', 'in-transit', 'broken', 'deleted'): Current status of the asset.'
For each tool, document the return type and structure. Example: 'Returns {asset_id: string, asset_name: string, serial_number: string, status: string, created_at: ISO 8601 timestamp}' or for list endpoints include pagination: 'Returns {items: [{...}], total: int, page: int, limit: int}'.
Add enum constraints to the 'action' parameter or replace it entirely. If keeping a dispatch tool, use enums: action (enum: 'create', 'update', 'delete', 'list', 'get') with a description for each valid value.
For destructive operations (delete, send, backup), add a 'confirm' boolean parameter (default false) and implement a dry-run: when confirm=false, return what would happen without applying changes. Example: delete_asset with confirm=false returns '{deleted: asset_id, would_affect: [references]}' without actually deleting.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Generic, non-actionable descriptions across all 40 tools. Descriptions like 'Tool for managing assets in Snipe-IT' and 'Tool for asset operations in Snipe-IT' (16-35 chars) provide no LLM guidance on when to use each tool, what parameters to pass, or what to expect. Per HARD SCORING RULE, descriptions under 20 chars must score 0-20.
Dispatch pattern using free-form 'action' string instead of enums or verb-based tool decomposition. The 'action' parameter accepts any string value like 'create', 'update', 'delete', 'list', 'get', these are not constrained. LLMs cannot validate actions before calling and will hallucinate invalid action names. This is a pattern:constrained-input violation.
Overlapping and vague tool names: 'manage_assets', 'asset_operations', and 'bulk_asset_operations' all seem to do similar things but have no clear distinction. Per pattern:tool, tool names should start with a clear action verb (get_, create_, update_, delete_, search_, list_) and avoid ambiguity. 'manage_*' names are too generic, they could mean anything.
No output schemas documented. The provided tool list shows input schemas only; no return types, field structures, or pagination information are visible. Per pattern:tool and pattern:paginated-result, every tool must document what it returns so agents can plan downstream tool calls and extract the right data.
Parameter descriptions missing entirely. The 'action' parameter across all 40 tools is described only as 'The action to perform' with no hint of valid values, dependencies, or expected format. Per pattern:tool-description, every parameter needs a description explaining what it controls. This forces the LLM to guess what actions are valid.
Destructive operations (delete, send, backup) lack any confirmation, dry-run, or safety mechanism. Tools like 'manage_backups', 'manage_imports', and any delete action via 'manage_*' could destroy data without validation. Per pattern:confirmation-request, irreversible operations should support a dry-run or confirmation step to prevent catastrophic errors.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible. The FEATURES list shows 'toolAnnotations=false'. Per current MCP spec (2026-07-28), tools should declare whether they are read-only, destructive, or idempotent so agents know which calls are safe to retry. This is especially critical for 28 WRITE-risk tools.
Add tool annotations via FastMCP's decorator options: use readOnlyHint for READ_ONLY tools, destructiveHint=true for delete/backup operations, idempotentHint=true for operations safe to retry.
Document error responses with recovery guidance. Example: 'If asset_name is missing, returns {error: "asset_name required", hint: "Provide a 2-255 character asset name."}'
For tools returning lists (list_assets, activity_reports, etc.), add pagination parameters: 'limit (int, 1-100, default 20): Max results per page' and 'offset (int, default 0): Starting position'. Return {items: [...], total: int, offset: int, limit: int} so agents know when there are more results.
Consolidate overlapping tools: merge 'manage_accessories', 'accessory_operations' into single 'manage_accessories' with proper action enums, or split fully into 'list_accessories', 'create_accessory', 'update_accessory', 'delete_accessory'. Reduce cognitive load on the LLM.