How MCP Servers Can Fix the Biggest Problem with AI Coding Assistants

10 min read Original article ↗

Software Deployment Tools

Xcf Seetan

And why open source projects should ship one alongside their code

If you’ve used an AI coding assistant for more than a week, you’ve encountered the hallucination, the subtle kind. The assistant confidently writes widget->SetSizeBox(x, y, w, h) when the real method is SetSize. Or it imports a module that was removed in version 3.0 or generates a perfectly structured program using an API that simply doesn't exist yet because the library was released last month, after the model's training data was frozen.

This is the knowledge cut-off problem, every LLM is affected by it and for software development, where APIs change, frameworks get released and specifications precede implementations, it causes real, compiler-breaking damage every day.

There’s a fix. It’s not a new model and doesn’t require retraining. It doesn’t require pasting documentation into prompts. It just requires rethinking what it means to distribute software.

The Problem

A large language model learns what it learns from its training corpus, frozen at a point in time. For software, this means the model has implicit knowledge of libraries that were well-represented in that corpus: popular, documented, discussed on Stack Overflow for years. For anything else, it guesses.

“Anything else” is a large and growing category:

  • New releases: every library that ships after the training cut-off is invisible
  • Niche tools: libraries too specialised to appear significantly in public training data
  • Internal frameworks: enterprise or research codebases never exposed publicly
  • Pre-release specifications: APIs designed but not yet implemented
  • Your own little experiments and side projects.

The current workaround is web search augmentation: the assistant searches for documentation and pastes relevant text into its context. This mostly works for popular and indexed content, but fails for anything else be it private, too new to be indexed, or structured in a way that web crawlers don’t handle well (think: API reference databases, Doxygen XML, CMake configurations).

There’s a deeper problem too. Even when documentation is available via web search, the assistant retrieves prose. What it actually needs for code generation is structured semantic content: exact method signatures, parameter types, ownership semantics, deprecation notices, version-specific behavior. These things live in header files and type databases, not in tutorial blog posts.

The Model Context Protocol: A Better Pipe

The Model Context Protocol (MCP) is an open standard, initially proposed by Anthropic and now supported across Claude, LM Studio, and a growing number of AI tools, that gives AI agents structured, tool-callable access to external data sources.

An MCP server exposes two primitives: resources (URI-addressable content you can fetch) and tools (functions the AI can call with parameters and get structured responses). The protocol runs over JSON-RPC 2.0, typically over stdio or HTTP, and requires no framework to implement , a few hundred lines of any systems language is sufficient.

Here’s what this looks like in practice. Instead of:

The AI guesses that Button::SetBounds takes (left, top, width, height) and hopes it's right

You get:

AI calls: get_symbol("Button", "SetBounds")
MCP server returns: {
  "signature": "void SetBounds(i32 left, i32 top, i32 width, i32 height)",
  "header": "include/ui/button.h",
  "notes": "Coordinates relative to parent widget",
  "example": "btn->SetBounds(10, 10, 100, 30);"
}
AI generates: btn->SetBounds(10, 10, 100, 30);  ✓

No hallucination, no web search, no documentation paste: the agent just called a tool, received the authoritative answer, and wrote correct code.

Skill Files: Teaching the Agent When to Ask

An important piece of the puzzle is the skill file: a structured document that tells the AI agent which MCP server to query, and when. Think of it as a configuration contract between the project and the agent’s reasoning process.

A skill file for a C++ framework might look like this:

# MyFramework Programming Skill
Use the `myframework-mcp` server for all questions about:
- Class signatures, method parameters, return types
- Header include paths and CMake configuration
- Event handler signatures and ownership rules
- Any API that might have changed since training
## When to query the MCP server (always):
- Before writing any class instantiation: get_symbol(class_name)
- Before wiring any event: get_symbol(widget, event_name)
- Before any SetBounds/geometry call: confirm parameter order
- Any method you haven't used in this session: verify first
## Never assume from training data alone:
- Method signatures (always verify)
- Ownership semantics (parent/child rules)
- Type aliases (i32 = long, not int in this framework)

The skill file enforces a discipline: the agent is trained to query before generating, not to recall from weights. This transforms the agent from a guesser into a lookup engine with reasoning on top. The skill file is checked into the project repository alongside documentation and becomes part of the project’s AI-readiness contract with contributors.

For the agent harness (Claude Desktop, LM Studio, or a custom pipeline), the skill file is referenced in the MCP server configuration:

{
  "mcpServers": {
    "myframework-docs": {
      "command": "/usr/local/bin/myframework-mcp",
      "args": ["--config", "/path/to/project/config.json"]
    }
  }
}

The combination of skill file + MCP server is what eliminates hallucination systematically not just opportunistically.

The Self-Bootstrapping Insight

Here’s where it gets genuinely interesting for framework and library authors.

The standard development workflow when using AI assistance is: write the framework, then use AI for applications. The AI can’t help you before the framework exists because it has never seen it.

MCP inverts this.

Publish a specification MCP server at the beginning of your development cycle, before writing a single line of implementation. The server exposes your planned APIs as query-able resources, clearly marked as specifications rather than implementations. Now connect an AI agent.

The agent generates application code, tests, and documentation examples against your specification. This code does three things that are genuinely valuable before you’ve written anything:

  1. Validates the API through usage : inconsistencies, missing overloads, and confusing ownership semantics surface when the AI tries to generate code that uses them. Design issues that would have appeared at integration time appear at specification review time instead.
  2. Creates a test harness : the generated application code and tests become the specification’s compliance suite. When you implement the framework, you already have working programs to validate against.
  3. Generates real documentation examples: because the AI is reasoning from the specification, the examples it produces are genuinely learnable by a human newcomer, not artificially simplified.

We experienced this directly building a native C++ UI framework. A specification MCP server was deployed before any widget code was written. An AI agent connected to it generated a multi-form application skeleton with correct event handler wiring, proper ownership semantics, and valid CMake configuration. Review of that code identified some API ambiguities that we corrected in the specification. The framework’s API was refined through AI-generated usage, weeks before the first widget rendered a pixel.

This is the self-bootstrapping property: the distribution mechanism accelerates development of the artifact being distributed.

What Open Source Projects Should Ship

The practical proposal is simple: MCP server as a standard release artifact.

Today, an open source release typically includes:

  • Source tarball
  • Binary packages
  • HTML/PDF documentation
  • Changelog

We propose adding:

  • libfoo-mcp — an MCP server delivering structured API knowledge

A minimal MCP server for a library is a few hundred lines of C, C++, Rust, or Python. It embeds a SQLite database containing:

  • Class and function signatures (extracted from Doxygen or language tooling)
  • Markdown documentation, chunked and full-text indexed
  • Header file contents
  • Version manifests

The server starts in under 100ms, requires no dependencies beyond SQLite, and runs over stdio, making it trivially integrable with any MCP-capable AI tool.

Package managers could support this naturally: apt install libfoo-mcp installs both the library and its knowledge server. The server registers with a local MCP broker, making libfoo's documentation immediately available to any AI tool on the system from the moment of installation.

The Offline-First Property

One detail that matters for production use: the MCP server binary should embed a compile-time snapshot of the documentation and also a compile-time snapshot of the code framework referent at the time of the release. On first startup in a network-isolated environment, the server is immediately functional with documentation current as of the build date and able to provide the full source of the project as well to compile and link the framework apps, completely offline.

When connectivity is available, it can optionally sync with official distribution endpoints to fetch updates. This pattern gives you:

  • Zero-dependency startup: no network required for basic operation
  • Deterministic builds : AI-assisted builds can be pinned to a specific documentation snapshot, ensuring reproducibility across machines and time
  • Graceful online updates : new releases propagate automatically when the server is online

This matters for CI/CD pipelines, air-gapped environments, and any situation where you need to guarantee that two different machines produce identical AI-assisted code output.

Why This Changes the Incentive Structure for Documentation

A persistent challenge in open source is documentation quality. Developers prioritise code and documentation is deferred resulting in suffering for the users.

MCP-native distribution changes the incentive. Good documentation in a machine-readable format translates directly into better AI assistance, which translates into faster development, more contributions, and wider adoption. Documentation stops being an obligation to grudgingly fulfil and becomes a technical asset with a measurable return.

Maintainers who invest in complete, structured API documentation will have projects that AI agents can use correctly and immediately. Maintainers who don’t will have projects where AI assistance generates incorrect code which in turn will generates bug reports and waste the maintainer time. The feedback loop is direct.

Implications for the AI Tooling Ecosystem

This model also has implications for how AI coding tools should be designed. An IDE or agent harness that natively understands MCP-packaged libraries could:

  • Auto-discover installed library MCP servers and make their knowledge available without configuration
  • Present a unified “knowledge surface” composed of multiple library servers to the agent
  • Surface version mismatches between the agent’s queries and the installed library version
  • Provide developers with metrics on hallucination rate before and after MCP adoption

None of this requires changes to the underlying models. It requires better plumbing between the code environment and the AI tool.

Open Questions

This is still in early gestation. There are real open questions the community needs to work through:

  • Standardisation: Should there be a standard MCP tool contract for open source libraries? What tools and resources should every library server expose?
  • Dependency chaining: When a library depends on other libraries, should its MCP server proxy knowledge queries to dependency servers?
  • Security: MCP servers that serve user-contributed content (forum discussions, issue threads) need careful sanitisation against adversarial prompt injection.
  • Dynamic languages: The approach works naturally for statically typed languages with headers and type databases. What’s the right extraction mechanism for Python, JavaScript, Ruby?

Getting Started

If you maintain a library and want to explore this, the minimum viable experiment is:

  1. Generate a Doxygen XML or equivalent structured output from your source code and in a SQLite format database file
  2. Write a small indexer that ingests the documentation into a SQLite FTS5 database
  3. Write a minimal MCP server (JSON-RPC 2.0 over stdio) with get_symbol and search_docs tools
  4. Write a skill file that tells agents to query your server before generating code
  5. Connect it to Claude Desktop or LM Studio and generate some application code

The total implementation effort for a medium-sized library is a day or two. The return is AI assistance that works correctly from day one of your next release.

A working reference implementation covering a complete C++ UI framework, specification documentation, API metadata, offline snapshot embedding, and skill file, will be released as open source in the coming months.

This post summarises research described in more detail in the pre-print “Bridging the Knowledge Gap: MCP-Driven Documentation Injection as a Self-Bootstrapping Distribution Model for Open Source Software”, available at [https://zenodo.org/records/19925469].

The author is an independent researcher. Correspondence: xcf.seetan@protonmail.com