Does your AI assistant know who uses your API?

Usually not. Your AI assistant knows the code and files it can open, and the teams that call your endpoint keep their code somewhere else. So when you ask it whether a change is safe, it answers from your side of the contract only.

It reads your code, not the other team's

Ask your AI assistant to remove a field from a response and it will do a careful job. It searches the repository, finds no reader of that field, updates the spec, fixes the tests and writes a tidy commit message. From inside the repository, that's the right answer.

The mobile app that reads the field lives in another repository, owned by another team, and nobody told the assistant it exists. The change is correct for the code it could see and wrong for the code it couldn't.

What the assistant sees, and what it doesn't

It can see	It cannot see
Your repository and the files you open	Repositories it has no access to
Your OpenAPI spec and your tests	Which teams call each endpoint, and how often
Docs and tickets you paste or connect	What another team agreed to in a thread last year
Tools you connect to it	Anything those tools don't know either

A smarter model doesn't help here: it reasons better about the same files, but it still doesn't see more of them.

Why it guesses instead of saying "I don't know"

When the answer isn't in what it can read, an assistant fills the gap with what's likely. "No usages found" becomes "unused". "Looks internal" becomes "safe to change". That's fine for a private helper function. For an API it's exactly the assumption that breaks another team in production.

A better prompt won't fix that. The assistant needs a source that actually knows who the consumers are.

Where the map can come from

Source	What it knows	Where it falls short
Code search	Callers in the code you can open	Misses every other repository
Static analysis across repositories	Call sites in every repository it scans	Needs read access to every consumer's code
Gateway or access logs	Which clients called recently	Client ids, not teams; misses rare callers
Contract tests (Pact)	Consumers that wrote a contract	Only those that wrote one
A service catalog	What someone wrote down	Goes stale when nobody updates it
Subscriptions	Teams that declared the endpoints they call	Needs each team to subscribe once; gaps show as blind spots

To be fair, sometimes your assistant alone is enough. In a monorepo where every caller lives in the same repository, a code search finds them. If your consumers publish Pact contracts, the Pact Broker shows who depends on you. And if every caller identifies itself at the gateway and you can tie each client to a team, recent traffic is a good list.

Give the assistant the map, not more code

That's what we built Graphwake to keep. The map comes from your OpenAPI specs and from subscriptions: each consumer team declares the endpoints it calls, and owners are named per service or endpoint. Graphwake never reads code. It needs only the spec.

With Graphwake MCP, your AI assistant asks that map directly. Graphwake has no language model of its own. The model is your assistant, and Graphwake answers its questions with data. It works with Claude Code, Cursor, GitHub Copilot and other clients that accept an API key.

Example: two questions your assistant can now answer with data instead of a guess.

What it can ask:

• "Who consumes this?" returns the owner and the consumer teams of an endpoint, with the channel each one is alerted in.
• "What would this break?" runs a dry run of your local spec against the live one. Nothing is stored and nobody is alerted.
• "Who might we be missing?" brings in Discovery, which suggests teams that may use an endpoint, with the reason for each. Those suggestions come from fixed rules, not a model.

A local check sends only the OpenAPI file, which is compared and then deleted. Graphwake never sees your code.

Questions to ask before you change an endpoint

• Who owns this endpoint, and who consumes it?
• Which of those teams would this change break, and how badly?
• Is there an endpoint here that nobody has claimed?
• Is another open pull request already breaking the same endpoint?

Your assistant can answer what changes from your repository. Who it reaches, and who owns it, needs the map. The setup guide connects it in a few minutes.

---

Originally published on graphwake.com.

Has your assistant ever told you a field or endpoint was unused when another team was relying on it? How did you find out?