If you already understand why ContextMCP Dockerized matters, the next question is simple: how do you actually connect it to the AI tools you use every day?
This page is the short answer. It gives you the MCP endpoint to point at, the config shapes for OpenCode and Claude Code, and one important update about the project architecture.
What Changed
ContextMCP Dockerized now runs on top of our own fork of context-mcp. That matters because the local-mode and code-indexing improvements are no longer just described as future work in a wrapper layer. They now live in the fork-backed implementation path we are actually using.
In practice: J3ys/ContextMCPDocker remains the Dockerized setup and operational wrapper, while the underlying ContextMCP behavior now comes from our own forked J3ys/context-mcp repository.
What You Need First
Local app running
Have the local app reachable at http://localhost:8787/mcp before you configure your AI tool.
Indexed content
The tool connection is only useful once you have already indexed the repositories or documentation you care about.
For the standard local workflow, that typically means:
That bootstrap step pulls the default embedding model into the local Dockerized Ollama service before reindexing starts.
Or pull it manually into the local Docker Ollama service:
Once that is done, your MCP endpoint should be available at http://localhost:8787/mcp.
OpenCode Setup
Current OpenCode docs describe remote MCP servers in opencode.json using a type: "remote" entry under the mcp object. For a local ContextMCP server, the simplest version looks like this:
If you keep an OpenCode project config in the repository, this makes the ContextMCP server available as part of the project setup rather than something you have to remember manually later.
Claude Code Setup
Current Claude Code MCP docs support HTTP MCP servers through a dedicated MCP configuration file. A minimal setup for a local ContextMCP endpoint looks like this:
The important part is that Claude Code talks directly to the HTTP MCP endpoint. If you later expose the server through a different hostname or proxy, only the URL needs to change.
Why This Still Complements Context7
This setup does not replace Context7. It completes it.
Context7 is still the fast path for public framework and library docs.
ContextMCP Dockerized is the missing path for your private repos, internal docs, architecture notes, and team-specific code conventions.
That is still the strongest combination for AI-assisted development: public docs from Context7, private and project-specific context from your own MCP server.
Where To Go Next
If you want the broader why and trade-offs behind this setup, read the original article comparing Context7 and ContextMCP Dockerized. If you are already convinced, go straight to the repo and run it locally.
Connect Your Own Context
Wire the MCP endpoint into your coding tool, index what matters, and give your AI assistant access to the context public tooling will never know by default.
View on GitHubOpen source • Local-first • Fork-backed implementation