Static source inference · medium confidence · detected: stateful session
Deprecated protocol patterns detected
Summary
LIMPS is a STDIO-only MCP server with 21 tools for plan management, document handling, and knowledge graphs. While tool names follow verb_noun patterns, definition quality is severely hampered by: (1) minimal or missing parameter descriptions across many tools; (2) absent input schemas for several tools; (3) vague descriptions that fail to explain WHEN/WHY to use each tool; (4) no documented output schemas; (5) no error handling guidance. The tool definitions appear to be extracted from a verification script (verify-tools.ts) rather than from actual implementation code, suggesting tool registrations may be inferred rather than directly visible. Multiple tools (tools 1, 2, 6, 15-21) have zero or empty required parameters with no descriptions explaining what they do or how to invoke them productively. This pattern indicates the server prioritizes breadth over depth and lacks the LLM-optimized descriptions that 94% of A+ production tools provide.
Empty or missing parameter descriptions on 11+ tools. Tools like create_plan, list_plans, check_staleness, check_drift, get_proposals have no 'required' parameters but lack any explanation of input structure or purpose. LLMs cannot infer what these tools do or how to invoke them.
Insufficient tool descriptions (under 50 characters). Tools like 'Create a new plan', 'List all plans', 'Check for stale documents' fail to explain WHEN the LLM should call them, what they return, or how they fit into the plan workflow.
No documented output schemas for any tool. LLMs cannot plan multi-step workflows if they do not know what fields each tool returns. E.g., does create_plan return a plan_id? Does get_proposals return an array or object? Unknown.
Recommendations
Expand every tool description to 50 - 200 characters, following the LLM-optimization pattern: 'What does it do?' + 'When should the LLM call it?' + 'What does it return?' Example: 'List all tasks in a plan by status and timestamp. Call after create_plan to set up the workflow. Returns array of task objects with id, status, assignee, deadline.'
Document the output schema for every tool. Use structured examples: 'Returns: {plan_id: string, name: string, status: 'active'|'archived', created_at: ISO8601, tasks_count: number}'.
Rename 'graph' to one of: 'reindex_knowledge_graph', 'check_knowledge_graph_health', or 'search_knowledge_graph' to disambiguate operations.
Rename 'process_doc' and 'process_docs' to 'execute_doc_transform' or 'run_doc_script' to better signal that they run code. Add security note: 'Executes JavaScript in a sandboxed QuickJS environment. Allowed APIs: [list allowed object methods]. No access to process, network, or filesystem beyond the document store.'
Add required parameter 'planId' to get_next_task and document its necessity: 'The plan ID to retrieve the next unfinished task for. Omitting it is invalid.'
For destructive tools (delete_doc), add a 'confirm' boolean parameter (default false) and require explicit confirmation. Alternatively, return a 'dry_run_output' with preview of what would be deleted.
Remove the 'ping' tool or document its purpose. As of MCP spec 2026-07-28, the protocol is stateless and does not require liveness checks. If kept, clarify: 'Health check endpoint. Returns: {status: ok|error}.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Stateful initialize / Mcp-Session-Id (removed; protocol is stateless) - make each request self-contained
Generic or ambiguous tool names. 'graph' (tool 20) does not indicate what operation, reindex, health check, or search. Should be 'reindex_knowledge_graph', 'check_graph_health', 'search_knowledge_graph'.
No error handling guidance. Tools accept minimal parameters and provide no indication of failure modes, retry conditions, or recovery steps. E.g., what happens if planId is invalid in list_agents? No guidance.
'ping' tool (tool 21) is deprecated in the current MCP spec (2026-07-28). The protocol is now stateless and does not require handshakes or keep-alives. Remove this tool or provide a rationale for its retention.
get_next_task has no 'required' parameters but expects a planId. Schema shows planId is optional, confusing. Either make planId required with a description or explain what it means to omit it.
process_doc and process_docs accept JavaScript code as a parameter. No security guidance on sandboxing, access controls, or what objects/functions are available. High risk of injection or unintended execution.
delete_doc is marked DESTRUCTIVE but has no confirmation step, dry-run mode, or recovery guidance. Agents could accidentally delete critical plans. No undo mechanism described.
delete_doc
Add error handling guidance to every tool. Example: 'If planId is not found, returns error: {code: NOT_FOUND, message: "Plan <id> does not exist", available_plans: [list]}'. This enables LLM self-correction.
Document parameter constraints in descriptions. E.g., 'limit (number, 1-100, default 20): Maximum results to return per search. Search is full-text and case-insensitive.'
Add security guidelines for process_doc/process_docs: list the sandbox capabilities, forbidden APIs, and execution timeout. Warn against executing untrusted code.
Separate tools that combine multiple concerns. E.g., 'apply_proposal' should be split into 'validate_proposal' (returns validation results) and 'commit_proposal' (applies change), allowing agents to review before action.
Add dependency hints to discovery tools: 'Call list_plans first to see available plans, then list_agents to see who is assigned. Finally, call get_plan_status to see current progress.'
Clarify idempotency. E.g., 'create_plan is idempotent: calling with the same name returns the existing plan, not an error.' This is critical for agent retry logic.