How do you ask your codebase questions via an API?

You ask your codebase questions via an API by putting an MCP server in front of it: the calling program sends a plain-language question and gets back prose, together with the commits it was derived from. That is a different operation from reading the repository through the GitHub API, which hands back files and metadata and leaves the entire job of understanding them to the caller.

The hard part is not the protocol. It is that the caller is no longer a person, so nobody proof-reads the answer before it gets used.

"Via an API" means MCP server, not a home-made endpoint

The Model Context Protocol is a standard socket between a data source and the software that queries it; we have covered the plain-language definition elsewhere. An MCP server declares tools; a client calls one of them with arguments and receives content back.

For a codebase, that means a tool whose main argument is the question itself. No query language, no schema to learn. A sentence. That is the shape a product expert server run per project takes.

Going through the standard instead of a bespoke REST endpoint pays off in one line. Anything that speaks MCP can already call your server — Claude, Cursor, a support agent platform, or your own code through an SDK. There is no client to write and no API documentation to keep alive.

One call, traced hop by hop

Follow a single question all the way through. The payloads below are schematic and illustrative: they show the shape, not an API signature to copy.

Hop 1 — the calling program. A release webhook, a nightly job, a bot drafting a ticket reply. None of them has eyes.

Hop 2 — the tool call. The question travels as written, with its window spelled out.

{
  "name": "ask_product",
  "arguments": {
    "question": "Has the response format of /v2/invoices changed since September 1st?"
  }
}

Hop 3 — resolution. This is where everything happens. The server reads the code, re-synced at every push, and the git history including commits and diffs, then checks the code before asserting anything.

Hop 4 — the answer, and what it carries besides text.

{
  "answer": "Yes. The `total` field changed unit on September 9th: amounts are now in cents rather than euros.",
  "sources": [{ "commit": "4f2ac91", "date": "2026-09-09" }],
  "asOf": "2026-09-24T04:12:00Z"
}

Hop 5 — what the program does with it. It cites, it relays, it triggers something else. And it can check its own work: freshness and commits are fields, not turns of phrase.

The trace makes visible what a repository API does not do. Hops 1, 2, 4 and 5 it handles without trouble. Hop 3, the step from question to answer, is left entirely to whoever is calling.

"What changed in the product this week?", asked by a program

This is the question we use as a yardstick, and it behaves differently depending on who asks. A person putting it to an assistant re-reads, raises an eyebrow, rephrases, notices a date that does not add up. The back-and-forth repairs whatever was shaky in the first answer.

A program does none of that. It takes the first answer and treats it as settled.

So the question does not change, but its contract does. It has to carry its window in the argument, because "this week" means nothing without a reference date. And the answer has to come back with everything needed to check it without reading it.

The four things that change when nobody reads

Sources travel with the answer. A human in doubt opens the commit. A program is never in doubt, it relays — so the only way to keep an answer verifiable is to attach its commits from the start, inside the payload.

"I don't know" has to be a result, not a phrasing. A cautious answer and a wrong answer look identical to a parser. We have written about why an agent invents product features: a missing answer must surface as an identifiable state, or it gets passed along as fact.

Freshness is a field. A written knowledge base has no way of announcing that it has aged. A source derived from code, re-synced at every push, can state when it was read — and a program can refuse an answer that is too old.

The caller is a service, not a person. This is the constraint that rules out the most options. A support bot, a CI job or a customer's agent platform cannot each be handed repository credentials; the safe access model is to serve them answers and never the code.

"I'll just call the GitHub API myself"

It is the first idea anyone has, it is a good one, and for part of the cases it is enough. A well-equipped developer with repository credentials writes a script in an afternoon that lists a week of commits and feeds them to a model. It is free and it is yours.

Three things limit it, and none of them is about skill.

First, the API mostly returns metadata. Commit message, author, files touched. But "the total field changed unit" only reads in the diff — and it reads there even when the commit message says nothing more than "fix invoices".

Second, there is a cost. Pulling diff content takes one call per commit, as our field notes on the official GitHub MCP server show: over a busy week, the call bill arrives before the answer does.

Third is the point from the section above. Your script runs under your own rights. It does not answer a customer's support agent, nor a contractor under NDA.

And what exactly does our server read?

It reads your repository, and that answer belongs here rather than in a footnote. The GitHub connection is read-only, one server is run per project, and access is revocable at any time.

What the server returns is prose sourced from commits and diffs, never raw source. You can see the difference in hop 4: a sentence and a list of commits. A native GitHub connector, by contrast, exposes the file tree to whoever holds the credentials.

Mini-FAQ

What client do I need to write to call this server? In most cases, none: MCP SDKs exist in the usual languages and agent platforms accept a server URL. The integration work is about which question to ask, not about transport.

Does it work on a monorepo? Yes, and it is rather the favourable case: one server per project queries the scope it was given, with no need to split the repository.

Can I ask about a past window? Git history being the source, the window is an argument like any other. "Since v2.3" and "between the 1st and the 15th" are handled the same way, provided the question carries its bounds.

How long does a call take? Long enough that a synchronous webhook is the wrong place for it. The reflex worth having is to treat the answer as background work, then write it where it will be used.

What to remember

Asking your codebase questions via an API is not exposing your repository behind a URL. It is moving the work of understanding to the server side, so the caller receives a sentence and its evidence.

Everything else follows from the fact that no human re-reads: sources attached, absence made explicit, freshness in the payload, and callers who never hold credentials on the code.

DeployIt is free during early access; paid plans arrive in January 2027. The MCP server stays in early access: the design partner program is open to teams who want to plug their own programs into these answers.