Turn Your Coding Agent into a Grounded Coding Assistant

Large language models are great at producing syntactically correct code, but they often suffer from outdated context, hallucinations, and version ambiguity because they were trained on snapshots of the web. If your project depends on up-to-date documentation you need a way to ground your Coding in the real docs that actually matter to your stack.

Docs-MCP-Server solves precisely this problem: it scrapes, processes, and indexes official documentation for any library so your agents can retrieve that precise, current context before generating code.

In this post you’ll learn:

• What Docs-MCP-Server actually does
• Why embedding models are essential
• A concrete coding example with and without Docs-MCP
• How to index docs with an agent prompt

What Docs-MCP-Server Is

Docs-MCP-Server provides a local, always-current knowledge base for your AI coding assistants. It solves:

• Stale Knowledge: models trained on old data don’t know recent APIs
• Code hallucinations: LLMs invent plausible but incorrect code
• Version ambiguity: generic answers rarely match the version you’re using

It scrapes documentation sources websites, GitHub repos, npm, PyPI, local files, chunks them semantically into meaningful pieces, generates vector embeddings, and exposes search tools via the Model Context Protocol (MCP) so your LLM can retrieve relevant doc content before generating outputs.

Docs-MCP combines semantic chunking with hybrid search (vector similarity + text search) to deliver accurate, version-aware answers that reduce hallucination and improve reliability

Why an Embedding Model Matters

Embedding models convert text into numerical vectors where semantic similarity is meaningful not just literal keyword matches. These vectors let your search system find the most relevant contextual doc passages for a given query, even if the terms don’t match exactly.

For example, a query about creating a UI component with modern accessibility conventions can retrieve documentation on ARIA best practices, hook patterns, and recommended APIs*, even if the user’s prompt doesn’t exactly mirror the location or wording in the docs*. That’s the practical power of semantic search.

Without embeddings, search is keyword matching, which often misses contextually relevant material. With embeddings, search is meaning matching.

MCP Config with LM Studio Embeddings Model

Here’s the mcp.json snippet you can add so we can launch Docs-MCP alongside other MCP servers:

{
  "mcpServers": {
    "docs-mcp-server": {
      "command": "npx",
      "args": ["@arabold/docs-mcp-server@latest"],
      "env": {
        "OPENAI_API_KEY": "lmstudio",
        "OPENAI_API_BASE": "http://localhost:1234/v1",
        "DOCS_MCP_EMBEDDING_MODEL": "text-embedding-nomic-embed-text-v2-moe"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

This tells your agent to run Docs-MCP using your local LM Studio API, pointing to a specific embedding model for semantic search results.

Same Prompt, Very Different Output

Prompt (Generic Across Any Toolset)

“Create a new button component for a UI library that follows accessibility best practices and supports primary/secondary styling.”

Without Docs-MCP(Generic LLM Completion)

function Button({ type = "primary", children }) {
  const className = type === "primary"
    ? "btn-primary"
    : "btn-secondary";
  return (
    <button className={className}>
      {children}
    </button>
  );
}

export default Button;

Characteristics:

• Reasonable structure but shallow context
• Generic class names with no semantic accessibility attributes
• No grounding in current best practices for any specific UI library

The model simply guessed based on patterns it learned during training, no retrieval step, no real docs consulted.

Doc-Aware Agent

import { useAccessibleFocus } from "ui-accessibility-utils";

export function Button({ variant = "primary", children, ...props }) {
  const { focusProps } = useAccessibleFocus();

  const className =
    variant === "primary"
      ? "bg-primary text-on-primary ring focus-visible:ring-2"
      : "bg-secondary text-on-secondary ring focus-visible:ring-2";

  return (
    <button
      type="button"
      aria-pressed={variant === "primary"}
      {...focusProps}
      className={className}
      {...props}
    >
      {children}
    </button>
  );
}

Under the hood:

1. The agent issued a search_docs call to Docs-MCP with a vectorized query based on your prompt
2. Docs-MCP returned the most semantically relevant doc passages from your indexed libraries
3. The LLM fused that context into the generated component

How to Index Documentation

Once LM Studio + Docs-MCP is running, use an agent prompt like:

Scrap docs from https://docs.example.com/ui-library for Library “ui-library” version “2.3.0” using scrap_docs tool from docs-mcp-server

This instructs your agent to fetch and index the official docs for that library, storing them in the MCP server so future search_docs calls return relevant, updated context.

Conclusion

Using **Docs-MCP-Server **turns your Coding Assistant from a pattern generator into a knowledgeable assistant. You get code grounded in current document context for whatever libraries and frameworks matter to you. This dramatically improves reliability, reduces hallucination, and keeps your AI tooling aligned with the real world, not a stale snapshot of it.

Originally published at https://medium.com/@moosezidan/turn-your-coding-agent-into-a-grounded-coding-assistant-b334d08d4e9a.