Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
The server defines 10 tools with varying quality. Tool names follow verb_noun conventions well (execute_, create_, destroy_, get_, list_, read_, write_). However, critical gaps undermine definition quality: (1) Parameter descriptions exist but are minimal (10-50 chars typically), well below the 72-char baseline for A+ tools. (2) No visible input schemas in the source code, tools are registered in package.json with names and brief descriptions only, but actual schema validation and structured parameter definitions are not visible in the provided src/server.py excerpt. The server uses fastmcp but the tool registration logic is cut off mid-file. (3) Output schemas are entirely undocumented, no tool describes what fields it returns, breaking the agent's ability to plan downstream calls and extract required IDs. (4) Error handling is absent from tool descriptions, no guidance on retryability, recovery steps, or failure modes. (5) Three tools (list_user_sessions, get_available_workspaces, get_kasm_users) take no parameters, which is unusual and suggests potential pagination/limit issues. (6) Sensitive operations like create_kasm_user and write_kasm_file have minimal descriptions and no mention of validation, permissions, or dry-run support. (7) The server logs to both stdout and stderr but there is no indication of structured logging, audit trails, or permission checks. Per-tool average score: 38/100.
Tools (10)
create_kasm_sessionwriteauthsource verified48/100
Create a new Kasm session with the specified workspace image.
Input schemas not visible in source code. Package.json lists tool names and brief descriptions, but actual parameter schemas, type definitions, and validation rules are not shown in the provided src/server.py excerpt. FastMCP tool registration appears incomplete.
Output schemas completely undocumented. No tool describes what fields it returns (no mention of kasm_id, status, file_content, etc.). Agents cannot plan downstream calls or extract required references. Violates baseline that 100% of A+ tools have documented return types.
Add explicit input schemas (JSON Schema) to every tool in FastMCP registration. Each parameter must have type (string, integer, boolean, array, object), description (50+ chars), and constraints (enum, minLength, maxLength, pattern, minimum, maximum). Example: { 'type': 'string', 'description': 'UUID of the Kasm session (format: 01366df3a03b4bccbb8c913846594826). Obtain from create_kasm_session or list_user_sessions.', 'pattern': '^[a-f0-9]{32}$' }
Document output schemas for every tool. Specify return type (object, array, string) and list all fields with type and description. Example for create_kasm_session: { 'type': 'object', 'fields': { 'kasm_id': 'string (UUID)', 'status': 'string (running|stopping|stopped)', 'created_at': 'ISO 8601 timestamp', 'workspace_image': 'string (image name/ID)' } }
Expand parameter descriptions to 50 - 150 characters. Include format hints, constraints, and where to obtain the value. Example for kasm_id: 'UUID of the Kasm session (format: 01366df3a03b4bccbb8c913846594826). Obtain from create_kasm_session or list_user_sessions. Required.'
Add pagination to list_user_sessions, get_available_workspaces, and get_kasm_users. Include optional parameters: limit (integer, 1 - 100, default 20), offset (integer, default 0). Return object with fields: items (array), total (integer), offset (integer), limit (integer).
Add error handling guidance to tool descriptions. For each tool, mention likely failure modes and recovery hints. Example for destroy_kasm_session: 'Terminates a Kasm session irreversibly. On failure: if session not found, error message suggests available sessions; if permission denied, check user role and retry with correct credentials; retryable up to 3 times.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Parameter descriptions are minimal (10 - 50 characters), well below the 72-character baseline for production tools. E.g. 'ID of the Kasm session' (24 chars) does not explain format, constraints, or typical values. Descriptions should answer: what is this? what format? what happens if I pass an invalid value?
No error handling guidance in tool descriptions. Tools like destroy_kasm_session (marked DESTRUCTIVE) provide no indication of failure modes, retryability, or recovery steps. Agents cannot self-correct on errors.
No pagination parameters on list/query tools. list_user_sessions, get_available_workspaces, and get_kasm_users accept no parameters (no limit, offset, page). Returning unbounded results risks blowing context windows. Baseline: paginated results include limit, page/offset, and total count.
Sensitive operations lack protective patterns. create_kasm_user and destroy_kasm_session are high-risk but have no dry-run, confirmation_required, or permission gate mention. Baseline: irreversible operations should support confirmation or dry-run to prevent agent mistakes.
Parameter naming ambiguity on accept-flexible-id tools. Tools like execute_kasm_command and get_session_status require 'kasm_id' (opaque system ID), but the description does not clarify format, where to obtain it, or whether UUIDs are expected. Baseline: if both system IDs and names are valid, provide separate parameters (kasm_id, kasm_name).
No audit trail or permission checks visible in code. Server logs basic startup info but no indication of per-call logging (who called what, when, with what result). Baseline: agent-initiated actions must be traceable for compliance and debugging.
Implement confirmation pattern for destructive tools. destroy_kasm_session and delete operations should support a 'confirm' parameter (boolean, default false). When false, return { 'status': 'confirmation_required', 'summary': 'Will destroy session X with 5 running processes.' }. Require confirm=true for actual deletion.
Add permission checks and audit logging. On every tool call, log: timestamp, calling user/agent ID, tool name, parameters (redact secrets), result (success/failure/error code). Return success/failure in structured format with error code and recovery hint. Example: { 'status': 'error', 'code': 'PERMISSION_DENIED', 'message': 'User role insufficient. Required: admin. Call get_user_profile to check current role.' }
For tools accepting image names or IDs (create_kasm_session), provide discovery. Add a 'validate_image' internal step or suggest calling get_available_workspaces first. Example description: 'Name or ID of workspace image. Call get_available_workspaces to list available options. Accepts Docker image names (e.g. kasmweb/chrome:1.8.0) or UUIDs (e.g. 01366df3a03b4bccbb8c913846594826).'
Split multi-responsibility tools. execute_kasm_command accepts optional working_dir, document clearly that working_dir is optional and defaults to user home. If command execution changes directory, document the side effect. Consider separate tools if read_kasm_file + write_kasm_file are combined in one 'modify_kasm_file' function.
Reduce required parameters where possible. For get_session_status, kasm_id is required, good. For list_user_sessions, add optional filter parameters (user_id, status_filter, limit) so the agent can narrow results efficiently without fetching all sessions.