ollama-mcp-bridge

Automatically discovers available tools from connected MCP servers by establishing stdio-based connections to MCP server processes, parsing their tool list responses, and registering tools with their schemas, descriptions, and input parameters into a DynamicToolRegistry. The bridge maintains a mapping between tool names and their originating MCP clients, enabling runtime tool availability without hardcoding tool definitions.

Manages the full lifecycle of MCP server processes including spawning child processes via Node.js child_process with stdio piping, establishing bidirectional JSON-RPC communication channels, handling process errors and disconnections, and graceful shutdown. Each MCP server runs as an isolated subprocess with its own stdio streams connected to the MCPClient for message routing.

Handles errors from MCP server tool calls by catching exceptions during tool execution, formatting error messages, and passing them back to the LLM as part of the conversation context. The LLM can then see the error and attempt alternative approaches or ask for clarification. Errors from MCP servers are converted to readable messages for the LLM.

Allows customization of the system prompt via bridge_config.json, with support for dynamic tool-specific instruction injection when relevant tools are detected. The base system prompt is loaded from configuration, then tool-specific instructions are appended when the bridge detects that certain tools are needed for the user's request, enabling model-specific guidance for tool usage.

Analyzes user messages to detect which tools from the registered tool registry are likely needed by matching keywords, tool descriptions, and semantic intent patterns. The DynamicToolRegistry maintains keyword mappings for each tool and the bridge uses these to identify relevant tools before sending the message to the LLM, enabling tool-specific instruction injection and optimized context window usage.

Wraps the Ollama API (OpenAI-compatible endpoint at baseUrl/v1/chat/completions) with a custom LLMClient that formats tool schemas as JSON in system prompts, sends messages with tool context, and parses tool-call responses from the LLM. Supports configurable temperature, max_tokens, and model selection, with built-in parsing of tool invocation patterns from LLM output.

Implements a message processing loop in MCPLLMBridge that handles multi-turn conversations where the LLM can invoke tools, receive results, and continue reasoning. The bridge detects tool calls in LLM responses, executes them via the appropriate MCP client, appends results to the conversation history, and re-invokes the LLM until it produces a final response without tool calls. Maintains full conversation context across turns.

Implements the Model Context Protocol using JSON-RPC 2.0 over stdio, with MCPClient handling message serialization, request/response correlation via message IDs, and error handling. Supports MCP methods like tools/list, tools/call, and resource operations through a standardized JSON-RPC request/response pattern with proper error codes and result handling.

Loads bridge configuration from bridge_config.json specifying LLM settings (model, baseUrl, temperature, maxTokens), MCP server definitions (command, args), and system prompt. The bridge parses this configuration at startup and uses it to initialize LLMClient with Ollama parameters and spawn MCP server processes with their configured commands and arguments, enabling zero-code configuration of the entire system.

Provides a command-line REPL interface in main.ts that accepts user messages, displays LLM responses, and supports special commands like 'list-tools' to enumerate available tools with their descriptions and 'quit' to exit. The CLI reads from stdin, processes messages through the bridge, and formats output for terminal display.

Converts tool schemas from the DynamicToolRegistry into JSON-formatted tool descriptions that are injected into the LLM system prompt. The bridge constructs a tools section in the prompt listing each tool's name, description, and input schema in a format the LLM can parse and understand, enabling the model to decide when and how to invoke tools based on the schema information.

Routes tool calls from the LLM to the correct MCP server by looking up the tool name in the tool registry to find the associated MCP client, then invoking the tool via that client's tools/call JSON-RPC method with the provided arguments. Handles tool execution errors and returns results back to the LLM for further processing.