LM Studio MCP Bridge
Related Servers
Alternatives to LM Studio MCP Bridge
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityCmaintenanceExposes local LM Studio language models as MCP tools, enabling chat completions and model listing through a local OpenAI-compatible API without requiring API keys.MIT
- FlicenseAqualityCmaintenanceMCP server that connects LLM agents to a local LM Studio instance, enabling model management, OpenAI-compatible chat completions, text completions, and embeddings through a set of tools.91-
- AlicenseAqualityDmaintenanceEnables seamless integration between Ollama's local LLM models and MCP-compatible applications, supporting model management and chat interactions.13758 npm170AGPL 3.0

Local AI MCPofficial
AlicenseAqualityAmaintenanceUnified MCP server for managing local model runtimes (Ollama, LM Studio, etc.), enabling provider-agnostic discovery, lifecycle management, hardware-fit checks, and delegated inference.1618 npmCreative Commons Attribution Non Commercial No Derivatives 4.0 International- FlicenseNot gradedqualityDmaintenanceIntegrates local language models (like Qwen3-8B) with MCP clients, providing tools for chat, code analysis, text generation, translation, and content summarization using your own hardware.-
- AlicenseAqualityDmaintenanceIntegrates Ollama's local AI models with MCP clients, enabling listing models, viewing model details, and asking questions to models.3MIT
TDQS
Scored across 28 tools
Multiple tools have overlapping purposes: get_system_health, check_server_status, and lms_status all report health status; list_local_models, lms_ls, and lms_ps all list models in different forms. The distinction between query_local_llm and query_local_llm_stateful is clear but other boundaries (e.g., lms_server_control vs lms_runtime_control) are fuzzy.
Naming conventions are mixed: most tools use snake_case (get_system_health, query_local_llm), but a subset uses an lms_ prefix (lms_status, lms_ps, lms_get). Verb choices vary inconsistently across similar actions (list vs get vs check vs read), and the async variant `analyze_local_image_async` does not follow a systematic pattern.
With 28 tools, the set is bloated. Many tools duplicate functionality or could be consolidated (e.g., multiple health check tools, multiple model listing tools). A more streamlined set of around 15-18 core tools would better align with the bridge's purpose.
The tool surface covers core workflows: model lifecycle, inference, vision, RAG, embeddings, file access, and network mesh. However, there are notable gaps such as no explicit tool to delete/unload models (only load/unload by model instance) and no way to cancel or manage background tasks beyond checking status. The redundancy in health/status commands also creates confusion but not missing functionality.