CerbiX SDK exposes 4 tools that act as a generic MCP gateway/proxy rather than domain-specific tools. Tool definitions are minimal: descriptions are present but generic (10-50 chars), input schemas exist but lack parameter descriptions, and output schemas are entirely undocumented. The tools (list_tools, call_tool, list_resources, read_resource) are meta-tools that delegate to a backend service, making them unsuitable for direct LLM invocation without significant schema enrichment. No error handling guidance, no parameter constraints, no output documentation.

• Document output schemas for all tools. Specify what fields list_tools returns (e.g., array of {name, description, inputSchema}), what call_tool returns (result, error, status_code), and what list_resources/read_resource return (uri, mimeType, contents).
• Expand tool descriptions to 100-200 characters. Example: 'list_tools: Retrieve all available tools registered with this MCP server. Returns tool name, description, and input schema. Call this first to discover what operations are available.'
• Add descriptions to all parameters. For 'call_tool', document: 'name (string): The exact name of the tool to invoke. arguments (object): Tool-specific parameters as a JSON object. See list_tools for valid tool names and their required arguments.'
• Add error handling guidance. Document what errors call_tool can return (ToolNotFound, InvalidArguments, Timeout, PermissionDenied) and suggest recovery steps (e.g., 'If ToolNotFound, call list_tools to verify the tool name').
• Consider exposing domain-specific tools instead of generic proxies. If this SDK wraps a backend service, register actual tools (e.g., 'create_ticket', 'send_email') with full schemas rather than generic 'call_tool' that requires the LLM to know backend tool names.

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

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