Server has 13 tools with consistent naming (verb_noun pattern) and all have descriptions. However, parameter descriptions are minimal (often 1-2 lines), output schemas are not documented, and error handling lacks recovery guidance. Most tools accept optional workspace/database parameters that could benefit from clearer constraints. The guard() wrapper prevents stack trace leakage but doesn't provide actionable error messages. Schemas are present in FastMCP decorators but lack detail on return types and pagination.

• Document output schemas for each tool. E.g., list_workspaces returns JSON array of {id, name, description}. Use tool docstrings or a separate schema file. This enables LLMs to extract workspace_id for downstream calls.
• Enhance error messages with recovery guidance. Catch FabricMcpError subtypes and return: 'Workspace "proj-xyz" not found. Available: proj-abc, proj-def. Try list_workspaces() to see all.' This guides the LLM to self-correct.
• Add explicit constraints to optional parameters. E.g., 'workspace (optional): workspace ID (UUID) or name (string). If omitted, uses default workspace from FABRIC_DEFAULT_WORKSPACE env var. Accepts either ID or name, not both.'
• For run_notebook, document the parameters object format: 'parameters (optional): JSON object mapping notebook parameter names to values. E.g. {"date": "2024-01-15", "region": "US"}. Values must match notebook parameter types.'
• Add pagination to list tools. E.g., list_workspaces(name_filter, limit=20, offset=0) returns {items: [...], total: 150, has_more: true}. Document in description: 'Returns up to 20 workspaces per call. Use offset to paginate.'

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

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