We don't publish
your competitive advantage.

IFWhen a task's LLM output fails Pydantic validation, the error recovery mechanism in converter.py crashes with 'NoneType' object has no attribute 'function_calling_llm' because the agent context is lost.

THENModify the `handle_partial_json` call in `to_pydantic` method of `Converter` class (in `converter.py`) to pass the actual `agent` object instead of `None`. This ensures the recovery logic can access the agent's LLM to fix malformed output.

IFMCP client initializes session via streamablehttp_client but server responds with unexpected content type (e.g., text/html) instead of MCP JSON stream.

THENThe client should validate the response content type before proceeding. If the content type is not 'application/json' or 'text/event-stream', raise an exception with a descriptive error message instead of silently printing a warning. This allows callers to catch and handle connection failures gracefully.

IFTool execution failures (e.g., missing env vars, server errors) are not caught, leading to unhandled exceptions or silent failures.

THENWrap tool calls in try-catch blocks, validate server responses, and provide meaningful error messages to the user. Ensure all tool-related operations have error handling.

IFWhen a long-running graph stream is cancelled (e.g., client disconnects in FastAPI), the completion callback may be set to None, causing a TypeError: 'NoneType' object is not callable.

THENIn `on_done` method, defensively check that both `self.callback` and the result of `self.callback()` are not None before calling it. This prevents the TypeError when tasks finish after cancellation.

IFPydantic model conversion fails with NoneType error when LLM output is malformed and agent context is lost in fallback.

THENPass the agent object to handle_partial_json in converter.py instead of None. Improve error messages to clearly indicate pydantic conversion failure. Ensure the agent's function_calling_llm is accessible during recovery.

IFAn assertion failure in cache.py (e.g., `assert mm_item is not None`) causes the input processing thread to die silently, leaving the EngineCore unresponsive.

THENAdd explicit exception handling and logging in the input thread loop to catch assertion errors and other failures. Ensure that unexpected thread termination is reported and that the system can either recover or gracefully shut down to avoid hanging.

IFWhen structured LLM output fails to parse, the generic AttributeError 'str' object has no attribute 'model_dump_json' hides the actual Pydantic validation error.

THENImprove error handling by catching the parsing exception and re-raising the original Pydantic validation error, so developers can see which fields caused the mismatch.

IFCreating an auto router with missing optional or mandatory fields causes a destructuring error on 'litellmParamsObj'.

THENEnsure all required and optional fields are provided when creating an auto router. Additionally, add error handling to check if the first element exists before destructuring, e.g., use a conditional assignment or optional chaining.

IFSSE event parsing fails due to invalid JSON, causing client to hang indefinitely

THENAdd a custom message_handler to the ClientSession that cancels the task group upon ValidationError. This ensures the client does not hang and can recover or retry.

IFWhen an MCP server (e.g., stdio) encounters an error like missing environment variables, the client has no built-in way to see the server-side error message.

THENSet up a notification handler on the client to receive server log messages via the `LoggingMessageNotificationSchema` using `client.setNotificationHandler`. The server can send log messages with `server.sendLoggingMessage` to communicate errors and status info to the client.

IFMCP server fails (e.g., due to missing environment variables) and needs to propagate the error details to the client.

THENUse the server's `sendLoggingMessage` method to send error-level messages to the client. On the client side, register a notification handler for `LoggingMessageNotificationSchema` to capture and display those messages, enabling effective error reporting from the server.

IFMCP server errors (e.g., missing required environment variables) are not captured by the client, leading to confusion.

THENConfigure the MCP client to handle server-side logging messages by setting a notification handler for LoggingMessageNotificationSchema. On the server side, use server.sendLoggingMessage to send error details. This allows the client to display or log server errors for debugging.