Vibe Coding Without the Hallucinations

It compiled. That was the problem.

You described what you wanted. The AI wrote thirty lines that read beautifully. Sensible variable names, a neat little helper, an import at the top that looked exactly like every other import in the file.

Then you ran it. TypeError: config.onReady is not a function.

You go looking. onReady does not exist. It has never existed. The library has onLoad, and the AI wrote onReady because in a world where onLoad exists, onReady is an extremely reasonable thing for a library to also have.

The short version: your AI is not lying. It is filling a gap. When it does not have the real documentation in front of it, it produces the most plausible thing it can, and plausible code is much harder to catch than obviously broken code. An MCP server gives it the actual docs to search first. Setting one up takes about two minutes and involves no terminal.

Why it invents things instead of saying "I don't know"

A language model has two sources of information: whatever it absorbed during training, and whatever is in the current conversation. That is the entire list.

Training happened at a fixed point in the past. The library you installed this morning may have shipped three major versions since then. Your framework renamed half its config keys. The service you are calling deprecated the endpoint the model remembers.

And critically: a model that does not know something has no reliable way to notice that it does not know. From the inside, "recalling a real function" and "generating a plausible function name" feel identical. So it generates, confidently, and you find out later.

This is why the failures cluster in a specific way:

• Function names that fit the naming pattern perfectly and do not exist
• Config options that sound like they should be supported
• Imports from a module path that was reorganised
• Answers that blend syntax from two libraries that solve similar problems

Every one of those is the model doing its best with an empty space where the documentation should be.

The fix is not a better prompt

The usual advice is to prompt harder. Tell it not to hallucinate. Tell it to say when it is unsure. Paste the docs into the chat.

The first two do not work, because the model cannot detect the gap. The third does work, and that is the clue — pasting the docs works because it puts real content in front of the model. The problem with pasting is that you have to do it every time, for every question, and you have to already know which page has the answer, which is usually the thing you were trying to find out.

What you want is for the AI to do the lookup itself, automatically, before it answers. That is what an MCP server is.

What an MCP server is, in plain terms

MCP stands for Model Context Protocol. It is a shared standard that lets an AI editor call out to a lookup service.

The server sits in front of a set of documents you chose and offers the AI a few abilities: search this, pull the exact passage, find a code example. Your editor calls it, gets real text back, and answers from that instead of from memory.

You do not need to understand the protocol. You need to know that it exists and that any modern AI editor speaks it.

Build one in about two minutes

Here is the whole thing. No terminal, no server, no configuration file to write from scratch.

1. Collect your links. Whatever documentation you keep open in browser tabs while you build — the framework docs, the UI library, the deployment guide. Copy those URLs into a note. Three or four is plenty to start.
2. Open the wizard. Go to MCP Studio and start a new server. Give it a name you will recognise later, like my-app-docs.
3. Paste the links in. One per source. If a docs site is huge, paste the URL of the section you actually use rather than the homepage — you get better answers from a narrower source.
4. Keep the suggested tools. The defaults are fine. If you want to be deliberate about it, make sure ask_question and get_code_examples are on. The first lets you ask in plain English; the second returns snippets that the library authors actually wrote.
5. Press Deploy. You get a URL and a small block of JSON.

Plug it into your editor

The block you get back looks like this:

{
  "mcpServers": {
    "my-app-docs": {
      "url": "https://appatools.com/mcp-studio/api/mcp/my-app-docs-q7t4n1"
    }
  }
}

Paste it into your editor's MCP settings and restart the editor. In Cursor that is a file called .cursor/mcp.json in your project folder — create it if it is not there. Claude Desktop and Windsurf each have a settings screen for this; the connection guide has the exact location for each.

Restart matters. Editors read MCP config at startup, and skipping the restart is the single most common reason people think it did not work.

Test it on something it got wrong before

Go back to the thing that broke. Ask again.

The tell that it is working is not that the answer is longer — it is that the answer cites where it came from. You will see the page and the passage. If the AI says the function is called onLoad, you can see the line in the docs that says so, and you are done arguing with it.

Some questions that tend to show the difference immediately:

• "What options does this component actually accept?"
• "Show me the real example from the docs for setting this up."
• "Is this function still supported, or was it replaced?"

That last one is the one that used to be unanswerable. A model working from memory cannot tell you what changed after its training cutoff. A model reading current docs can.

Two things that trip people up

Restart your editor. Said twice on purpose.

Narrow your sources. The instinct is to add everything — every docs site, the whole framework, the entire API reference. Broad sources retrieve worse, because the search has more irrelevant material to sort through. Three well-chosen sources beat ten sprawling ones almost every time. You can always add more later.

It is not really about hallucinations

Fixing wrong answers is the obvious win. The quieter one is that you stop double-checking.

When you cannot trust the output, you verify everything, and verifying everything is slower than writing it yourself. That is the real cost of a hallucinating assistant — not the bugs, the tax on every single suggestion. Once the answers come with a source attached, you skim the citation instead of auditing the code, and the whole loop gets faster.

That is the actual point of vibe coding. Stay in the flow. Do not spend the afternoon discovering that onReady was never real.

Build your first MCP server for free →

Keep going

• MCP for vibe coders — the short version, with the common questions answered
• Tutorial: your first context server — the same steps as a click-by-click walkthrough
• Create an MCP server in less than 2 minutes — the general version of this post
• Connect to Claude, Cursor, or VS Code — exact settings location for each editor
• Adding sources — what makes a good source, and what to do with huge sites