Which integrations are available for this server?

Discovers local Ollama instances and exposes their endpoint metadata, reachability, and available model IDs to MCP clients.

How do I use model-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@model-mcp what local models are available?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

model-mcp

by shakerg

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

model-mcp

npm container

model-mcp is a Model Context Protocol (MCP) server that discovers local model runtimes and exposes their endpoint metadata to MCP clients such as Copilot.

It checks common localhost endpoints for:

Ollama (http://127.0.0.1:11434/api/tags)
LM Studio (http://127.0.0.1:1234/v1/models)
LocalAI or OpenAI-compatible local servers (http://127.0.0.1:8080/v1/models)

The server does not proxy prompts or model completions. It advertises where local models are available so an MCP-aware client can inspect and use that configuration.

Install

Run from a source checkout

git clone https://github.com/shakerg/model-mcp.git
cd model-mcp
npm install
npm run build

In the GitHub Copilot app, add a local/stdio MCP server. Use the absolute path to the checkout:

{
  "servers": {
    "local-models": {
      "type": "stdio",
      "command": "node",
      "args": ["/absolute/path/to/model-mcp/dist/index.js"]
    }
  }
}

You can also run the checkout directly with npm start; it communicates over stdio and normally waits silently for an MCP client.

Install from npm

If npm view model-mcp version returns the release you want, add a local/stdio MCP server in the GitHub Copilot app and let npx download and launch it:

{
  "servers": {
    "local-models": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "model-mcp@<published-version>"]
    }
  }
}

Use the package's exact published version for reproducible installation.

Install from Docker

Images are stored in this repository's GitHub Container Registry package. After the matching version is available, add a local/stdio server that keeps stdin open and maps the cross-platform Docker host name:

{
  "servers": {
    "local-models": {
      "type": "stdio",
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "--add-host",
        "host.docker.internal:host-gateway",
        "ghcr.io/shakerg/model-mcp:<published-version>"
      ]
    }
  }
}

The image defaults to the common model ports on host.docker.internal, allowing the container to discover Ollama, LM Studio, and LocalAI running on the host. Use MODEL_MCP_ENDPOINTS to override those endpoints.

Install from an MCP registry

After a release is listed in an MCP registry, supported Copilot clients can choose either the npm or Docker package instead of entering the command manually. The installer reads server.json and presents these optional environment fields:

MODEL_MCP_ENDPOINTS
MODEL_MCP_TIMEOUT_MS
MODEL_MCP_ALLOW_REMOTE

Leave a field unset to use its default. Registry installation is available only after the package or image version referenced by server.json has been published.

WARNING

https://github.com/shakerg/model-mcp is a repository page, not a remote MCP endpoint. Do not enter it as an HTTP, SSE, or streamable HTTP server URL. This project is a local stdio server; treating the GitHub URL as an MCP endpoint sends protocol requests to a web page and results in HTTP errors such as 422 with an HTML response.

Related MCP server: MCPfinder Server

Configuration

Set MODEL_MCP_ENDPOINTS to a comma-separated list of local endpoint base URLs when your model servers use different ports.

MODEL_MCP_ENDPOINTS="http://127.0.0.1:11434,http://127.0.0.1:1234" npm start

By default, only loopback hosts and Docker's host.docker.internal gateway are accepted. Set MODEL_MCP_ALLOW_REMOTE=true only when you intentionally want to expose other model endpoints through the MCP server.

Optional environment variables:

Variable	Default	Description
`MODEL_MCP_ENDPOINTS`	Common Ollama, LM Studio, and LocalAI localhost URLs	Comma-separated endpoint base URLs.
`MODEL_MCP_TIMEOUT_MS`	`2000`	Timeout for each endpoint discovery request.
`MODEL_MCP_ALLOW_REMOTE`	`false`	Allows non-loopback endpoints when set to `true`.

MCP capabilities

Tools

list_local_models - returns configured endpoints, reachability, and discovered model IDs.
describe_model_endpoint - inspects one endpoint by ID, such as ollama or lm-studio.
get_model_endpoint_config - returns an MCP configuration snippet that can be used by Copilot or another MCP client.

Resources

local-models://endpoints - JSON description of discovered endpoints and models.
local-models://copilot-config - JSON MCP configuration example for launching this server.

Development

npm run test:package
npm run test:docker

test:package type-checks the source, validates server.json against its official MCP schema, creates the npm tarball, checks that dist/index.js is executable and included, installs the tarball into a clean temporary project, and completes an MCP initialize/list-tools exchange over stdio.

test:docker builds the production image and completes the same MCP initialize/list-tools exchange through docker run.

When Docker-related source changes merge to main, the Publish container GitHub Actions workflow builds linux/amd64 and linux/arm64 images and pushes both the package version and latest tags to this repository's GHCR package. The workflow rejects an existing version tag, so image changes require a version bump.

Publishing checklist

Publication requires maintainer access to npm, GitHub Container Registry, and the MCP registry:

Run npm run test:package.
Confirm the version matches in package.json, server.json, and src/index.ts, and that package.json#mcpName matches server.json#name.
Publish with the project owner's npm account or configured trusted publishing.
Confirm npm view model-mcp version returns the released version.
Merge the release PR to main to publish the multi-platform image, then make the GHCR package public if it does not inherit public visibility and verify its version tag.
Only then publish server.json to an MCP registry.

Available Tools

3 tools

describe_model_endpointDescribe model endpointA

Inspect one configured endpoint by id and report whether it is reachable and which models it exposes.

ParametersJSON Schema

Name	Required	Description	Default
`endpointId`	Yes	Endpoint id from list_local_models, for example ollama or lm-studio

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that it reports reachability and models, which implies a read-only operation, but it does not explicitly say there are no side effects or describe error handling or edge cases (e.g., what happens if the endpoint is not found). The description is adequate but could be more transparent about potential failure modes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the core purpose and outcome. There is zero waste; every word contributes to understanding what the tool does. It is well-structured and easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description is nearly complete. It specifies what the tool does and what it reports (reachability and models), which covers the return value expectation. It does not mention error handling or prerequisites, but those are minor given the simplicity and the fact that the parameter schema points to list_local_models. Overall, the description is sufficient for an agent to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 100% coverage of the single parameter endpointId, with a clear description indicating where to obtain the id. The tool description adds no additional parameter semantics beyond what the schema already provides. Since coverage is high, the baseline of 3 is appropriate, and the description does not need to compensate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (inspect), the resource (one configured endpoint by id), and the outcome (report reachability and models). It distinguishes itself from siblings by specifying that it inspects a single endpoint and reports on reachability and exposed models, which is different from listing all endpoints or getting configuration details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies that this tool is used when you have a specific endpoint id and want to know if it's reachable and what models it exposes. It does not explicitly mention alternatives or exclusions, but the purpose is clear enough that an agent would know when to use it. The parameter schema further directs the user to get the id from list_local_models, providing implicit context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_model_endpoint_configGet model endpoint configurationA

Return the local MCP and model endpoint configuration to share with Copilot or another MCP client.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. 'Return' implies a read-only, non-mutating operation, and the description adds context about what configuration is returned. But it does not disclose potential sensitivity of the config, whether any network/remote call is made, or any side effects, so it is only minimally transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence efficiently states the action, resource, and purpose. There is no redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read-only tool, the description is mostly sufficient Disclaimer: it lacks an output schema and does not explain what the returned configuration contains beyond 'local MCP and model endpoint configuration.' It also doesn't distinguish itself from describe_model_endpoint, so an agent could benefit from more context about the exact content or format of the response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters existing, so there is nothing for the description to clarify. The baseline of 4 is appropriate; the description does not need to add parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns 'the local MCP and model endpoint configuration' and names the intended use case. It is clear about the resource and action, but it does not explicitly distinguish itself from sibling tools like describe_model_endpoint, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'to share with Copilot or another MCP client' gives a clear usage context. However, the description does not mention when not to use this tool or how it differs from list_local_models and describe_model_endpoint, leaving some selection judgment to the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_local_modelsList local modelsA

Discover models from configured localhost model runtimes such as Ollama, LM Studio, and LocalAI.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden of behavioral disclosure. It does not detail what happens if no models are found, whether it checks all configured runtimes or just the first, or if any network requests are made. This absence of behavioral context is a gap, but the description avoids contradicting any annotations since none exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that is appropriately concise. It front-loads the key action ('Discover models') and immediately clarifies the context (localhost model runtimes) with concrete examples. There is no unnecessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with zero parameters and no output schema, the description is quite complete. It clearly defines the tool's scope and expected behavior. The only potential gap is the lack of detail on how the discovery works or what happens in edge cases, but for a simple discovery tool, this is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Since the tool has zero parameters, the description does not need to add parameter semantics. The schema coverage is 100% (trivially, as there are no properties), but the description adds value by specifying the scope (localhost runtimes) and examples, which is useful for the agent to understand what 'discover models' means.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: to discover models from configured localhost model runtimes. It specifies the resource (local models) and provides concrete examples of supported runtimes (Ollama, LM Studio, LocalAI), which effectively distinguishes it from sibling tools that deal with endpoint configuration and description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when you need to discover available models from local runtimes, which provides clear context. It does not explicitly state when NOT to use it or mention alternatives such as get_model_endpoint_config, but given the simple nature and sibling names, the usage is clear enough for an agent to select it appropriately.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesv1.0.1Sep 10, 2026
- First observeddescribe_model_endpoint
- First observedget_model_endpoint_config
- First observedlist_local_models

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-09-10 22:33 across 3 tools

Disambiguation5/5

Each tool targets a distinct concern: discovering models, retrieving shareable config, and inspecting a specific endpoint. There is no meaningful overlap—list_local_models is about discovery, get_model_endpoint_config is about config export, and describe_model_endpoint is about state inspection of one endpoint.

Naming Consistency5/5

All tool names follow the same verb_noun convention with consistent snake_case. The verbs list, get, and describe are distinct actions that map to each tool's purpose without stylistic drift.

Tool Count5/5

Three tools is well-scoped for a server whose purpose is to discover, inspect, and share local model endpoint information. Each tool earns its place without redundancy or bloat.

Completeness5/5

The server covers the full intended workflow: discover local models, inspect a specific endpoint's reachability and models, and retrieve the configuration for sharing with a client. Since it is an inspection/discovery server, not a management API, there are no obvious missing operations.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Agent Nexus A
app.agentnexus
Agent-native registry to discover APIs, MCP servers and CLIs, with live health checks.
41
jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2
llm-orchestration-agent-2
ai.getvda
MCP-Native LLM Orchestration Agent
Agent Orchestration AI & Machine Learning
1
Apideck MCP A
dev.apideck.mcp
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Developer Tools
42

Related MCP Servers

Ollama MCP Server
RAG Systems Developer Tools
rawveg
A
license
A
quality
D
maintenance
Enables seamless integration between Ollama's local LLM models and MCP-compatible applications, supporting model management and chat interactions.
Updated a month ago (2026-08-13 23:18 UTC)
13
758 npm
171
AGPL 3.0
MCPfinder Server
RAG Systems Developer Tools Autonomous Agents
mcpfinder
A
license
A
quality
Not graded
maintenance
Enables AI assistants to discover, retrieve details about, and manage MCP (Model Context Protocol) servers that provide additional tools and capabilities on demand.
Updated a year ago (2025-07-10 06:25 UTC)
5
63 npm
10
-
WEATHGARDS
Virtualization OS Automation Monitoring
liambuild
F
license
Not graded
quality
D
maintenance
Exposes MCP tools that enable remote LLMs to query local Docker containers, OS processes, and system services in real time.
Updated 3 months ago (2026-06-04 21:45 UTC)
-
Local AI MCPofficial
AI & Machine Learning Developer Tools
TMHSDigital
A
license
A
quality
A
maintenance
Unified MCP server for managing local model runtimes (Ollama, LM Studio, etc.), enabling provider-agnostic discovery, lifecycle management, hardware-fit checks, and delegated inference.
Updated 16 days ago (2026-08-31 06:22 UTC)
16
18 npm
Creative Commons Attribution Non Commercial No Derivatives 4.0 International

model-mcp

Install

Run from a source checkout

Install from npm

Install from Docker

Install from an MCP registry

Configuration

MCP capabilities

Tools

Resources

Development

Publishing checklist

Available Tools

TDQS

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Ollama MCP Server

MCPfinder Server

WEATHGARDS

Local AI MCPofficial