Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This MCP server has severe definition quality issues. Only 2 tools are exposed, and both lack proper schema documentation and LLM-optimized descriptions. The 'test' tool appears to be a health check endpoint misclassified as a tool. The 'process-file' tool has a basic description but no visible input schema, and parameter descriptions are minimal. The server uses Spring AI MCP framework but provides no evidence of properly structured tool registration with JSON Schema definitions. No output schemas are documented for either tool. Error handling and recovery guidance are absent. Parameter naming and descriptions do not follow production tool patterns.
No input schemas visible for either tool. The 'process-file' tool has parameter types inferred as 'MultipartFile' and 'string' from source code comments, but no formal JSON Schema is present in the source.
'test' tool is a health check endpoint, not a data-processing or user-facing tool. It has description 'Test endpoint for health check' (28 chars) which is barely adequate. Health checks should not be exposed as primary MCP tools; they belong in infrastructure monitoring, not agent interaction surfaces. This misclassifies infrastructure concerns as user-facing capabilities.
No documented output schemas for either tool. Agents cannot know what fields 'process-file' returns, making downstream tool chaining impossible and forcing LLMs to guess at response structure.
testprocess-file
Recommendations
Remove or demote the 'test' tool. Health checks should be infrastructure concerns, not user-facing MCP tools. If health status must be exposed, create a single 'get_server_status' tool with a documented schema returning {status: 'healthy'|'degraded'|'unhealthy', uptime_seconds: number, version: string}.
Rename 'process-file' to a more specific verb_noun form like 'analyze_csv_with_prompt', 'extract_data_from_file', or 'summarize_spreadsheet'. The current name is generic and does not indicate what analysis occurs.
Document the complete input schema for 'process-file' in JSON Schema format: {type: 'object', properties: {file: {type: 'string', description: 'Multipart file upload. Accepted formats: CSV (.csv), Excel (.xlsx, .xls). Max size: 10MB.'}, prompt: {type: 'string', description: 'LLM prompt to analyze file content. Min 5 chars, max 2000 chars. E.g., "Summarize the key metrics in this spreadsheet."'}}, required: ['file', 'prompt']}.
Expand tool description to 100-200 chars with concrete context: 'Analyze CSV or Excel files using an LLM. Upload a file and provide a prompt (e.g., "Extract all customer emails"). Returns the LLM's structured analysis. Useful for data extraction, summarization, and pattern detection from tabular data.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Parameter descriptions for 'process-file' are extremely terse. 'file' is described as 'The CSV or Excel file to process' (31 chars) and 'prompt' as 'The prompt to send to the LLM along with file content' (54 chars). These lack format constraints, limits, required field details, and context for when to use the tool.
No error handling guidance. If a file fails to parse, or the LLM call fails, or a file is too large, no error responses are documented. No actionable recovery suggestions (e.g., 'Try a smaller file' or 'Use a CSV instead of Excel'). Per pattern: error responses must tell the LLM what to do next.
Parameter naming is inconsistent with production patterns. 'file' and 'prompt' are generic and lack suffixes. Should be 'file_path', 'file_content', 'csv_file', 'prompt_text', or similar to disambiguate.
Tool descriptions are too brief. 'Process CSV or Excel files with an LLM prompt' (51 chars) answers WHAT but not WHEN to use it or what it returns. Production descriptions explain: What does it do? When should the LLM call it? What does it return?
No input validation constraints documented. For 'file': is there a size limit? Supported formats (CSV, XLSX, XLS only?)? For 'prompt': max length? Min length? These constraints should appear in parameter descriptions and be enforced server-side. Per pattern: describe the expected format, range, and allowed values directly in the parameter description.
No documentation of what the tool returns. Does 'process-file' return the LLM's analysis text? A JSON structure? A file? An error code? Agents cannot compose follow-up actions without knowing output fields.
process-file
Add parameter descriptions with format and constraint details. For 'file': 'CSV or Excel file to analyze. Supported formats: .csv, .xlsx, .xls. Max 10MB. Pass as multipart/form-data.' For 'prompt': 'Analysis instruction for the LLM (e.g., "Extract product names and prices"). Min 5 characters, max 2000. Must be a valid English instruction.'
Implement comprehensive error handling with recovery guidance. Document error responses: {error: 'File too large', recovery: 'Upload a file smaller than 10MB, or split your data into multiple files.'}, {error: 'Unsupported format', recovery: 'Use CSV or Excel (.xlsx/.xls) format only.'}, {error: 'LLM processing failed', recovery: 'Try a simpler prompt or contact support.'}
Add tool annotations (readOnlyHint, idempotentHint) to clarify behavior. 'process-file' is read-only on the file system but may interact with an LLM service; mark it appropriately in the tool definition.
Specify parameter constraints formally: file multipart field with max size 10MB, prompt string with minLength 5, maxLength 2000. Enforce these server-side and return clear validation errors (e.g., 'Prompt too short: must be at least 5 characters').
Document pagination and result limits if the LLM analysis returns multiple items. If returning an array of extracted fields, cap at 100 items and include a 'total_results' and 'truncated' flag.