Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
Console Automation MCP has 30 tools with basic descriptions but significant gaps in schema completeness, parameter documentation, and error handling guidance. All tools have names starting with action verbs (console_*), which is good. However, input schemas are inferred from the provided list rather than directly verified in source code, the Dockerfile and package.json show build/deployment configuration but not the actual tool registration code. Tool descriptions are terse (avg ~60 chars), meeting the minimum but lacking context for LLM selection. Most critically, parameter type constraints (enums, bounds, formats) are absent, descriptions state 'string' or 'array' but provide no validation rules or examples of valid inputs. Output schemas are not documented at all. Error handling does not guide recovery: tools lack categorization (retryable vs fatal), actionable error messages, or compensation paths. The server implements many security-sensitive operations (process execution, SSH, cloud provisioning via peerDependencies) but parameter descriptions do not warn about injection risks or side effects. Composition is problematic: console_send_input, console_send_key, console_get_output, and console_wait_for_output overlap significantly and could be unified. Background job management (tools 26-30) duplicates session management (tools 1-7) with different naming conventions, confusing tool selection.
Schema completeness: Input parameter descriptions lack type constraints, enums, bounds, and validation rules. E.g., 'timeout' params accept numbers but no min/max/units specified; 'shell' param accepts string but no enum of valid shells (bash, sh, zsh, etc.); 'detectErrors' accepts boolean but no explanation of what error patterns trigger detection.
Output schemas not documented: No tool describes what fields are returned, their types, or their meaning. LLMs cannot plan downstream calls when return structure is opaque. E.g., console_list_sessions likely returns an array of session objects, but the schema, field names, and nesting are invisible.
Expand tool descriptions from avg 50 chars to 150 - 250 chars. Include: (1) what the tool does, (2) when/why to call it vs similar tools, (3) key side effects (especially for write operations), (4) prerequisites or dependencies.
Add parameter type constraints to all descriptions: numeric params should specify min/max/units (e.g., 'timeout: 0 - 300000 milliseconds'); string params should list valid enums or regex patterns (e.g., 'shell: one of bash, sh, zsh, fish, powershell'); boolean params should explain what each value means in context.
Document output schemas for every tool. Use a standard format: '{"sessionId": "string (UUID)", "status": "running|stopped|error", "output": "string", "timestamp": "ISO 8601 date"}'. LLMs need this to parse responses and plan downstream calls.
Add error handling guidance to descriptions. State common failure modes and next steps: 'If sessionId not found, call console_list_sessions() to discover valid IDs.' Categorize errors: 'This error is retryable: the session may come online shortly.'
Consolidate session and job management. Either: (a) unify console_execute_async into console_create_session with an 'async: true' parameter, or (b) clearly document in both tool descriptions when to use synchronous vs async paths and what response fields differ.
Add input validation and injection warnings to console_create_session, console_execute_command, console_execute_async descriptions: 'Command arguments are passed to a shell. Do NOT interpolate untrusted user input directly, use parameterization or escaping to prevent command injection.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Error handling lacking recovery guidance: No tool describes what errors are possible, when they are retryable, or what the agent should do. E.g., 'sessionId not found', should the agent retry, call console_list_sessions(), or ask the user? Descriptions silent on this.
Composition overlap: Session management (tools 1-7) and job management (tools 26-30) duplicate each other with different naming. console_create_session + console_execute_command vs console_execute_async + console_get_job_status confuses tool selection. Consolidate or clarify when to use each.
Tool description brevity: Descriptions avg ~50 chars, below the 194-char baseline for production tools. E.g., 'Clear output buffer of a console session' (43 chars) omits WHEN to call this, WHY it matters (does it affect output retrieval?), or WHAT side effects occur.
Security & injection risk not documented: Tools execute arbitrary commands (console_create_session, console_execute_command, console_execute_async) and interact with SSH, cloud provisioning (peerDependencies: @aws-sdk/*, @azure/*, @google-cloud/*). Descriptions do NOT warn about command injection, path traversal, or privilege escalation risks. LLMs may pass unsanitized user input as command arguments.
Parameter identity & reference fields incomplete: Many tools accept sessionId, jobId, name as strings, but descriptions do not state whether these are case-sensitive, what format is expected (UUID? alphanumeric?), or how to discover valid IDs if unknown. E.g., 'sessionId', is it a UUID, integer, or string slug?
Pagination not mentioned: Tools like console_list_sessions, console_list_profiles, console_list_jobs do not describe pagination. Are results capped? What happens with 1000+ sessions? Can the agent request pages or cursors?
Tool naming 'and' signals multiple concerns: console_send_input and console_send_key both send data to a session but differ in mechanism. Descriptions do not clarify when to use each or whether they can be combined. Naming alone does not disambiguate.
No idempotency guarantees stated: Tools like console_execute_command, console_save_profile do not state whether retrying with the same input is safe. If an LLM retries a failed console_execute_command, does it re-execute the command (side effect risk)?
Document pagination for console_list_sessions, console_list_profiles, console_list_jobs: 'Returns up to 50 items per request. Use offset and limit parameters to paginate. Include total_count and has_more in responses.'
Clarify sessionId and jobId format in parameter descriptions. E.g., 'sessionId: string UUID (e.g., a3f8-4d2c-9e1b-7c5f). Discover valid IDs by calling console_list_sessions().'
Add idempotency statements: 'This tool is idempotent: calling it multiple times with the same parameters will not cause duplicate side effects.' Or: 'This tool is NOT idempotent: retrying may re-execute the command. Verify the session state before retrying.'
Add explicit timeout behavior: 'If the session does not respond within the timeout period, the tool returns a timeout error. This error is retryable: the session may recover.'
Split console_send_input and console_send_key into separate, focused tools with distinct descriptions explaining the difference: console_send_input sends text/stdin; console_send_key sends control sequences (Ctrl+C, Ctrl+Z). Document why each exists and when to use each.
Document rate limits in descriptions or a general note: 'Tools are rate-limited to 100 calls/minute per session to prevent runaway agents. Hitting this limit returns a 429 error with retry-after guidance.'