Choosing the Right Context Is Where the Magic Happens

Our promise is that you can build absolutely anything, with the right context. We spent today on the second half of that sentence.

Connecting your documents to an AI assistant is the part everyone talks about. It is also the easy part. What decides whether you get a useful answer is much smaller and much less glamorous: out of everything you connected, which handful of paragraphs does the assistant actually get to read?

That choice is where the magic happens, so we spent the day enhancing it and taking it to the next level.

Why the choice matters more than the connection

An AI assistant cannot tell what it was not given.

Hand it five paragraphs and it will write you a confident, well-structured answer using those five paragraphs. If four of them were only loosely related, you still get the confident answer. Nothing in the reply tells you that the useful paragraph never made it in.

That is the quiet failure mode of every "connect your docs to AI" tool, and it is worse than it sounds, because it does not look like a failure. It looks like an answer.

What changed

Three practical differences:

Your question no longer has to use the same words as your documentation. People ask about "logging in"; the docs say "authentication". Passages are now matched on meaning as well as wording, so the mismatch stops costing you the answer.

Close calls get a second, closer look. When the top candidates are hard to separate, MCP Studio takes another pass to work out which one genuinely answers the question rather than which one merely looks similar.

You stop getting the same paragraph twice. Long pages are read in overlapping sections, which used to mean a reply could contain five passages that were really one. Now they are five different ones, so the assistant gets five times the information in the same space.

The results

We check this by asking a fixed set of 61 questions we know the answers to, then measuring how often the right material comes back. The last measure is the one we care about most, and it is the subject of the next section.

One more number, because it is the one closest to how it feels to use: on 98.4% of those questions, the passages that came back were enough to actually act on.

These are our own documentation sets, so treat the figures as a record of our progress rather than a score against anyone else. We would rather show you a real measurement with its limits than a rounder number with none.

The part we are proudest of: saying "I don't know"

Everything above makes good answers more likely. This makes bad ones rarer, and we think it matters more.

When nothing in your content is a genuine match for the question, the reply now says so before it says anything else. Your assistant is told to pass that on rather than piece something together from whatever was nearest.

You: How do I tune the message queue timeout?

Assistant: Nothing in this server's content covers message queue tuning. The closest material is about API request timeouts, which is a different thing. You would need to add that documentation as a source.

That is not an impressive-looking answer. It is an honest one, and it is the difference between a tool you can trust and a tool you have to double-check.

A connected assistant that quietly invents an answer is worse than one with no connection at all, because you have no reason to be suspicious of it. Getting this right meant tuning it carefully in both directions: warn too rarely and it is decoration, warn too often and you learn to ignore it, which is the same thing as not having it.

Three things we learned

Being more careful on every single question made the answers worse. When the best match is already obvious, taking a second look only introduces doubt. Extra effort is worth spending where the outcome is genuinely uncertain, and not everywhere.

A smaller set of documents was harder to search well than a huge one, which is the opposite of what we expected. When a collection was small, fewer of its own passages were getting far enough through the process to be compared properly. Fixing that helped the most common case there is: one product's documentation rather than an enormous library.

Testing everything is what made the difference. Several of our most sensible-sounding ideas turned out to change nothing once we measured them, and some of what helped most we would not have guessed. Being able to run a real experiment on every idea is the thing that turned a day of opinions into a day of improvements.

What this means if you use MCP Studio

Nothing to configure and nothing to migrate. Every improvement here is already live on every MCP server in MCP Studio, including ones you created months ago. Your next question simply gets a better answer.

If you have not connected anything yet: point MCP Studio at a documentation site, a GitHub repository, or a folder of files, and connect the endpoint to Claude Desktop, Cursor, or any other AI tool you use.

We care about connected sources. We care more about what happens in the seconds after you press enter, because that is where an AI answer is either genuinely grounded in your material or merely dressed up to look like it. That is where we will keep spending our time.

Read more in how it works, or see what's new.