CLINE-MCP defines 4 tools with explicit schemas and basic descriptions, but falls short of production quality. All tools are registered in ListToolsRequestSchema with schemas visible in src/index.ts. However, descriptions are minimal (avg 8 words), parameter descriptions lack depth, no output schemas are documented, and no error recovery guidance is provided. The server implements basic input validation (type checking) but does not return actionable error messages. Parameter names are clear (directory, sessionId, content) but lack format constraints (e.g., no guidance on valid session ID format or directory path constraints). Tools are well-separated (create, get, update, end) following single-responsibility principle, but lack composition hints. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk profiles.
Tools (4)
create_sessionwritesource verified53/100
Create a new session for a specific directory
end_sessiondestructivesource verified52/100
End a session and remove its context
get_contextread onlysource verified55/100
Retrieve context for a specific session and directory
Descriptions are too short and lack WHEN/WHY context. 'Create a new session for a specific directory' does not explain when to call this tool, what constitutes a 'session', or what the returned sessionId represents.
Parameter descriptions are missing or minimal. 'directory' lacks format guidance (absolute vs relative? must exist beforehand?). 'sessionId' lacks format spec (UUID? opaque string? how long?). 'content' has no length limits or encoding notes.
No output schema documentation. CallToolRequest handlers return text responses (JSON.stringify) but LLM does not know what fields to expect. No documented structure for sessionId, context object, or success response.
Expand tool descriptions to 100 - 150 characters. Add WHEN/WHY context: 'Create a new session to isolate conversation context for a specific directory. Sessions store accumulated context, allowing the model to build up understanding across multiple interactions without mixing concerns. Returns a sessionId for use in subsequent get_context and update_context calls.'
Add format constraints to all parameters. Example: 'directory: (string, required) Absolute or relative filesystem path to the project directory. Must exist and be readable. Example: /home/user/myproject or ./src'
Document parameter formats in descriptions. Example: 'sessionId: (string, required) Unique opaque session identifier (UUID format, 36 chars). Generated by create_session. Used to retrieve and modify context for that specific directory session.'
Add explicit output schema documentation in tool descriptions. Example: 'Returns: { sessionId: string } on success. sessionId is valid for 24 hours or until end_session is called.'
Annotate tools with readOnlyHint and destructiveHint. Add to schema: '"readOnlyHint": false' for create_session, update_context, end_session. Add '"destructiveHint": true' for end_session.
Implement dry-run for destructive operations. Add optional parameter 'dry_run: boolean' to end_session. When true, return what WOULD be deleted without actually deleting.
Improve error messages with recovery guidance. Instead of 'Invalid directory parameter', return: 'Directory not found: /path/to/dir. Please provide an absolute or relative path to an existing directory. Example: /home/user/project or ./src'
Destructive and write tools lack annotations and confirmation patterns. end_session deletes state (Risk: DESTRUCTIVE) but has no readOnlyHint=false or destructiveHint annotation. No dry-run or confirmation step.
Error messages are generic and not recovery-guided. 'Invalid directory parameter' does not tell the LLM what to do next. No examples of valid formats or recovery steps.
Parameters accept unconstrained strings. 'directory' could be an absolute path, relative path, environment variable, or invalid path, no enum, pattern, or format constraint. LLM may hallucinate invalid values.
No idempotency guarantees. create_session on the same directory twice, does it create a new session or return the existing one? Agents retry on ambiguous failures; non-idempotent tools risk duplicate sessions.
Tool composition unclear. After create_session returns, does the sessionId work immediately with get_context, or is there a delay? No dependency hints or ordering constraints documented.
create_sessionget_context
Document idempotency behavior. For create_session: 'If called twice with the same directory, creates a new session both times. To reuse an existing session, pass its sessionId to get_context.'
Add parameter constraints. For sessionId: use a pattern field (UUID regex) or explicit enum of valid formats. For content: specify max length (e.g., 100KB) and encoding (UTF-8).
Include tool chaining guidance. After create_session, immediately call get_context to verify. Document the expected flow: create_session → get_context → update_context → end_session.
Specify timeout behavior. If Redis is unavailable, should the server fail immediately or retry? Document expected latency and timeout (e.g., 'Calls may take 100 - 500ms. If Redis is unreachable, requests timeout after 5s and return an error.').