MCP-Chatbot

Automatically discovers available tools from configured MCP servers via the stdio protocol, parses tool schemas, and registers them into the LLM's system prompt without manual tool definition. Uses the Server.list_tools() method to query each MCP server asynchronously, extracting tool metadata (name, description, input schema) and formatting it for LLM consumption via Tool.format_for_llm(). This enables zero-configuration tool integration where new tools become available immediately upon server startup.

Provides a unified LLMClient class that communicates with any LLM API following OpenAI's chat completion interface (configurable base URL, model name, API key). The client handles request formatting, response parsing, and error handling for tool-calling responses, allowing seamless swapping between OpenAI, Anthropic, Ollama, or any OpenAI-compatible endpoint without code changes. Configuration is loaded from environment variables, enabling provider switching via .env file updates.

Manages sensitive credentials (API keys, endpoints) via environment variables loaded from .env files, keeping secrets out of source code and configuration files. The Configuration class reads variables like OPENAI_API_KEY, LLM_BASE_URL, and provider-specific credentials from the environment, enabling secure credential injection without code changes. Supports .env file loading via python-dotenv or similar libraries.

Manages the full lifecycle of MCP server connections using the stdio protocol: spawning server processes, initializing the MCP session, discovering tools, executing tool calls with built-in retry mechanisms, and gracefully shutting down resources. The Server class wraps subprocess management and async I/O to handle bidirectional communication with MCP servers, including error recovery and resource cleanup. Supports multiple concurrent server connections via asyncio, enabling parallel tool execution across servers.

Orchestrates a full agentic loop: accepts user input, sends it with system prompt and tool schemas to the LLM, parses tool-calling decisions from the LLM response, executes requested tools via MCP servers, and feeds tool results back into the conversation context for the LLM to reason over. The ChatSession class manages conversation history and iteratively calls the LLM until it produces a final response (no more tool calls). This enables multi-step reasoning where the LLM can call tools, observe results, and make follow-up decisions.

Loads MCP server configurations from a JSON file (servers_config.json) that specifies server command, arguments, and environment variables. The Configuration class merges JSON-defined settings with environment variables (e.g., API keys from .env), enabling secure credential management and environment-specific server setup without hardcoding secrets. Supports variable substitution in server commands and arguments, allowing dynamic path resolution and credential injection at runtime.

Converts MCP tool metadata (name, description, input schema) into a structured format that LLMs can understand and reason about. The Tool.format_for_llm() method serializes tool schemas into a standardized text or JSON representation that is injected into the system prompt, enabling the LLM to recognize available tools and generate valid tool-calling requests. Handles schema validation and formatting to ensure LLM-compatible output.

Executes tool calls concurrently across multiple MCP servers using Python's asyncio framework. When the LLM requests multiple tools, the system spawns async tasks for each tool execution, allowing parallel I/O and reducing total latency. The Server class uses async/await patterns for all I/O operations (server communication, tool execution), enabling efficient handling of multiple concurrent requests without blocking.

Executes tool calls with automatic retry logic on failure, allowing transient errors (network timeouts, temporary server unavailability) to be recovered without user intervention. The Server.call_tool() method includes configurable retry counts and handles specific error types, re-attempting failed tool calls before surfacing errors to the LLM. Errors are formatted as tool results and fed back to the LLM for reasoning, enabling the agent to adapt to tool failures.

Provides a command-line interface for interactive multi-turn conversations with the chatbot. Users type messages at a prompt, and the system displays LLM responses and tool execution traces in real-time. The main() function orchestrates the chat loop, handling user input, calling the ChatSession, and formatting output for readability. Supports streaming responses (if the LLM provider supports it) to provide real-time feedback to users.

Constructs a system prompt that includes tool schemas and usage instructions, injected into every LLM request to guide the model's behavior. The system prompt is built dynamically from discovered tools, formatted via Tool.format_for_llm(), and combined with static instructions about how to call tools and when to use them. This enables the LLM to understand its capabilities without requiring fine-tuning or external knowledge.