Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
Smart File MCP suffers from significant definition quality issues. While all 12 tools have names and descriptions, most descriptions are generic and under 50 characters, falling well short of the 194-char baseline. Parameter descriptions are minimal or absent. Input schemas exist for most tools but lack proper depth. No output schemas are documented. Error handling guidance is missing entirely. The server lacks security-critical pattern implementations (secret injection, permission gates, audit trails). This is a C-/D+ server in its current form.
No output schemas documented for any tool. LLMs cannot know what fields to expect in responses, breaking downstream tool chaining and forcing manual parsing
Expand all tool descriptions to 100-200 characters. Answer: (1) What does it do? (2) When should the LLM call it? (3) What does it return? Example for get_file_info: 'Retrieve metadata and recent activity for a monitored file, including modification timestamp, size, and access patterns. Use this before querying to understand file status.'
Document output schemas for every tool. Create a formal JSON Schema that specifies the fields returned, their types, and descriptions. For list_files, return an array with fields [file_path, size, last_modified, status]. For get_metrics, return {request_count, avg_response_time_ms, error_count, timestamp}.
Add enum constraints to parameters with restricted values. For notify_change.event_type, change description to: 'Type of change event. Must be one of: created, modified, deleted, moved.' And add 'enum': ['created', 'modified', 'deleted', 'moved'] to the schema.
Implement tool annotations in the schema. Mark read-only tools with 'readOnlyHint': true. Mark destructive tools (clear_conversation, cleanup_conversations) with 'destructiveHint': true. This signals operation risk to the client.
Add pagination support to list_files and list_conversations. Include parameters 'limit' (1-100, default 20) and 'offset' (default 0). Return a response with 'items', 'total_count', and 'has_more' fields.
Document parameter constraints in descriptions. For file_path: 'Absolute or relative path to the monitored file. Max 512 characters. Special characters are not allowed.' For days in cleanup_conversations: 'Positive integer, range 1-365. Default 7. Warning: conversations with less than this inactivity will be permanently deleted.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Parameters like 'event_type' in notify_change lack enum constraints and validation guidance. Description says 'created, modified, deleted, moved' but does not declare these as valid enum values
Destructive operations (clear_conversation, cleanup_conversations) have no confirmation step, dry-run mode, or permission gating. Agents can irreversibly delete data without friction
API key authentication is mentioned in source (X-API-Key header) but there is no documentation of permission scopes or how the LLM should know which tools require authentication
Parameter descriptions for 'file_path' are minimal ('Path to the file'). No guidance on absolute vs relative paths, valid character sets, or maximum length
cleanup_conversations has a default value for 'days' (7) but no documentation of whether this is safe or if it risks unintended deletion
cleanup_conversations
Add error handling guidance. For each tool, document common failures: 'file_path not found → returns 404 with suggestion to call list_files() first', 'Invalid event_type → returns 400 with list of valid types', 'Rate limit exceeded → returns 429, retry after X seconds'.
Implement permission gating for destructive operations. Before clear_conversation and cleanup_conversations execute, verify the caller has 'admin' or 'write:conversations' scope. Return 403 Forbidden with clear message if permission denied.
Add a dry-run parameter to cleanup_conversations. Include 'dry_run': bool (default false) in input schema. When true, return a report of conversations that would be deleted without actually deleting them. This enables safe testing.
Document which tools require authentication. Add a 'requires_auth' field or note to each tool description that needs X-API-Key, e.g., 'Requires X-API-Key header with admin scope.'
Add tool descriptions that explain prerequisites and dependencies. Example for query_file: 'Query a monitored file using natural language. The file must be in the monitored directory (see list_files). Supports questions like "Show recent changes" or "What is the current status?"'