MCP Server Jupyter Edit provides 7 well-defined notebook manipulation tools with explicit schemas and descriptions. Tool naming follows verb_noun convention consistently (read_notebook, write_notebook, list_cells, get_cell, add_cell, update_cell, delete_cell). Descriptions are present and actionable (average ~80 chars), falling within the 10-1024 character baseline. All parameters have type definitions and descriptions. However, several critical gaps prevent a higher score: (1) Output schemas are not explicitly documented in the visible code, LLMs cannot predict return structure for composition; (2) Error handling is basic (anyhow::bail with messages) without recovery guidance or categorization; (3) No safety confirmations for destructive operations (delete_cell); (4) Parameter validation rules are sparse (e.g., path existence, cell_type enum is validated in code but not schema-declared); (5) STDIO transport limits protocol readiness; (6) No tool annotations (destructiveHint, readOnlyHint, idempotentHint) despite clear operation types. Averaging across 7 tools: 4 read-only tools (read_notebook, list_cells, get_cell, partial list_cells) score ~70 (good naming/descriptions, limited output docs); 3 write/destructive tools (write_notebook, add_cell, update_cell, delete_cell) score ~55 (good input validation in code, but no output schemas, missing safety patterns). Baseline comparison: tool names average 18 chars (rubric p50), server uses 10-20 chars (good); descriptions average 194 chars (rubric p50), server uses 60-120 chars (slightly lean but adequate); 100% of params have descriptions and types (meets baseline).

• Add explicit JSON Schema output definitions to all tool registrations. Document return types for read_notebook (string), write_notebook (WriteNotebookResponse with message and warnings fields), list_cells (Vec<CellInfo>), get_cell (string), add_cell (AddCellResponse), update_cell (string), delete_cell (string).
• Declare cell_type in add_cell as an enum in the JSON Schema: enum=['code', 'markdown', 'raw']. Remove duplicated validation from code or keep both for defense-in-depth.
• Add tool annotations to all tool definitions: destructiveHint=true for delete_cell, write_notebook (overwrites), add_cell, update_cell; readOnlyHint=true for read_notebook, list_cells, get_cell.
• Implement a dry-run pattern for delete_cell. Add an optional 'confirm' parameter (boolean, default false). On confirm=false, return a confirmation message with cell details; on confirm=true, execute the delete. This allows agents to verify before irreversible actions.
• Enhance error messages with recovery guidance. Instead of anyhow::bail('Cell not found with ID: ...'), return structured errors like: '{"error": "CELL_NOT_FOUND", "details": "Cell 'abc123' not found", "recovery": "Call list_cells(path) to see available cell IDs", "retryable": false}'. Use a custom error type with these fields.
• Add path validation/sanitization to all file-accepting tools. Canonicalize paths with std::fs::canonicalize or use a jail directory (e.g., restrict to a notebooks/ subdirectory). Validate that resolved paths do not escape the intended directory.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry