Giving AI agents knowledge they were never trained on

I love coding my own stuff, and my clients typically have lots of internal specifications and libraries to use.

But since LLMs haven't been trained on that, it's hard to get them to code accurately using those specs, libraries, or frameworks.

You can, of course, let the agents parse everything, but that wastes tokens and your patience :)

The same goes for well-known libraries, but you are stuck on a specific version that you must follow. You don't want it to guess the API.

docs-mcpserver exists to deal with both.

What it is

It is an MCP server that provides an agent with accurate knowledge of a framework or specification using documentation as the medium. It reads three kinds of docs:

• Markdown docs — your *.md files.
• API reference — C# XML documentation, or TypeDoc JSON.
• Schema — JSON Schema, OpenAPI 3.x, Swagger 2.0.

What the agent gets out of it is the same in every case: the real names, the real
signatures, the real shapes. Sources can come from a
local folder or straight from a GitHub URL. A single
server instance can host several libraries side by side. For instance, your in-house framework, a client's framework, and a specific version of some public library.

The agent picks which one to query.

I personally have used it to code against a specification called DATEX (traffic information for roads), which is HUGE, my own SPA library, and against sound format specifications for a sound app I'm building.

Why not just give the agent the files

You could point the agent to the folders and let it read them. The MCP server does a few things that raw file access does not:

• It is sandboxed. Each source is scoped, with path-traversal protection. The agent reads what you exposed, nothing else on the disk.
• It reads in pieces. Instead of loading a 4000-line reference file, the agent asks for the table of contents, then pulls the one chapter it needs.
• It searches properly. Dedicated search tools with regex and glob support, instead of the agent improvising its own grep.
• It is self-describing. With several libraries configured, the agent calls one tool to discover what is available. You do not have to spell out every path.
• GitHub works without cloning. Give it a repo URL and it handles the rest.

The multi-library part is the point. Instead of running several MCP servers for
documentation, you get one with a small toolset. No token waste.

Setting it up

Install and build:

npm install
npm run build

The quick way, a single folder:

docs-mcpserver ./docs --name "My Docs"

For the real use case — several libraries — use a config file. Here is an
in-house framework served from disk, next to a pinned version of a public
library pulled from GitHub:

{
  "name": "dev-docs",
  "description": "Frameworks the model has not been trained on",
  "cacheDir": "./cache",
  "libraries": [
    {
      "name": "acme-core",
      "description": "Our internal application framework",
      "sources": [
        { "type": "disk", "origin": "./frameworks/acme-core/docs", "kind": "docs" },
        { "type": "disk", "origin": "./frameworks/acme-core/api",  "kind": "api"  }
      ]
    },
    {
      "name": "somelib-3.2",
      "description": "SomeLib, pinned to v3.2.0",
      "sources": [
        {
          "type": "github",
          "origin": "https://github.com/someorg/somelib/tree/v3.2.0/docs",
          "kind": "docs"
        }
      ]
    }
  ]
}

Start it with the config:

docs-mcpserver --config dev-docs.json

And register it with Claude Code:

claude mcp add mydocs -- node /path/to/markdown-docs-mcp/dist/index.js --config /path/to/dev-docs.json

For private GitHub repos, set GITHUB_TOKEN in the environment.

What the agent actually sees

Each library exposes tools based on the kind of its sources:

• docs — get_doc_index, get_sub_index, read_doc_file, get_file_toc, get_chapters, search_docs.
• api — get_api_index, get_api_type, get_api_member, search_api.
• schema — list_schemas, list_definitions, get_definition, search_definitions, search_all_schemas.

A typical run looks like this. The agent calls list_libraries and sees
acme-core and somelib-3.2. It needs to know how acme-core handles
configuration, so it calls search_docs with library: "acme-core", finds the
right file, asks for its table of contents with get_file_toc, then pulls the
one relevant section with get_chapters. It answers the question without ever
loading the whole file.

When multiple libraries are configured, every tool takes a library parameter.
When there is only one, the parameter disappears, and the tools behave like a
plain single-library server.

The same applies to schema sources. For an OpenAPI spec, path operations show up
as definitions named like GET /pets, so the agent can ask for one endpoint
without reading the whole document. Useful when you want the agent to call your
API correctly rather than guess at the shape of it.

Generating the API input

One thing worth knowing up front: the api pipeline does not read source code.
It consumes a generated documentation file.

• TypeScript / JavaScript — use TypeDoc's JSON serializer: typedoc --json api.json src/index.ts. Point the source at that .json file. The markdown output from typedoc-plugin-markdown is not supported — it has to be the JSON serializer output.
• C# — enable <GenerateDocumentationFile>true</GenerateDocumentationFile> and point the source at the generated *.xml file, or the build output folder that contains it.

What it does not do

It does not read source code. If you want API reference, you generate the doc
file first, as above.

Try it

The code is on GitHub, or on npm as docs-mcpserver.

Feel free to leave feedback, or check my other MCP servers on GitHub.

Comments

[Raju Dandigam]

This is a practical MCP use case because it solves a real developer pain: agents guessing APIs they were never trained on. I like the scoped-docs approach, especially the ability to expose TypeDoc JSON and schemas without giving the agent the whole repo. A useful next layer could be tracing which docs/tools the agent consulted before producing code, so teams can debug bad generations more easily. That is close to what I’m exploring with agent-inspect for TypeScript agent execution inspection.

[Jonas Gauffin]

I got a MCP server for typescript too, including code quality inspection to find the next mess to fix ;) I'll write about it next. github.com/jgauffin/ts-language-mcp

[Harjot Singh]

Giving agents knowledge they were never trained on is the whole game for real-world usefulness, because the training cutoff and the absence of your private/proprietary data are the two biggest gaps between a clever general model and something useful in your actual business. Retrieval is the right lever, and the framing I'd stress is that you're not teaching the model, you're feeding it: the knowledge lives in an external, updatable store and you surface the relevant slice at inference time, which is why RAG beats fine-tuning for facts that change (you update the source, not the weights). Two things decide whether this works: retrieval quality (the model can only use what you actually fetch, so chunking and ranking are the ceiling) and grounding discipline (prefer the retrieved knowledge over the model's priors, and abstain when the docs don't cover it, rather than blending in a confident guess). The nice property is freshness, your agent's knowledge is as current as your store, no retraining required. Feed it the right external knowledge at query time, ground answers in it, and keep the source updatable. That retrieve-don't-retrain-for-changing-knowledge instinct is core to how I think about Moonshift. For the knowledge it was never trained on, are you leaning on RAG retrieval, or also doing any lightweight fine-tuning for the domain style?

[xulingfeng]

Your benchmarks are making my laptop feel personally attacked 😂 Did you consider any alternatives before settling on this?

Great stuff — followed for more! 👍