On this page
- What you need
- Step 1: create an MCP key
- Keep the key out of git
- Step 2: add Graphwake to your assistant
- Step 3: ask who consumes an endpoint
- Step 4: check your local spec before you push
- Step 5: subscribe your team
- The tools
- What Graphwake adds to your assistant
- When your assistant alone is enough
- Next steps
- Questions
What you need
- A Graphwake workspace on a plan with MCP. Graphwake MCP is included in Pro and Enterprise, not in Basic. A trial on Pro includes it. See plans.
- Your OpenAPI specs in Graphwake, and teams subscribed to the endpoints they call. The assistant can only answer from the map Graphwake has. An endpoint nobody subscribes to comes back as a blind spot, not as “safe”.
- An assistant that takes an API key. Works with Claude Code, Cursor, GitHub Copilot and other clients that accept an API key.
Step 1: create an MCP key
Open Settings → AI assistants (MCP)
In the Graphwake dashboard. Choose New key and give it a name, such as the machine it runs on.
Choose the access
Read only is the default: the assistant can ask, nothing more. Read and write also lets it subscribe your team to an endpoint and answer Discovery suggestions. Start with read only.
Copy the setup
The key is shown once and expires after 90 days unless you pick another lifetime (30 to 365 days); then create a new one. The dialog shows the setup for each client below with your key already in it; copy the one you need.
Keep the key out of git
Do not commit a file that contains the key. The setups below keep it in your user settings, in an environment variable, or in your editor’s secret store.
Step 2: add Graphwake to your assistant
Graphwake MCP is a Streamable HTTP server at one address. Every client gets the same two things: the URL and an Authorization header with your key.
Claude Code
claude mcp add --transport http graphwake https://api.graphwake.com/mcp \
--header "Authorization: Bearer YOUR_MCP_KEY"Without --scope, Claude Code stores the server in your own ~/.claude.json for the current project, not in the repository. Add --scope user to use it in every project. Check it with claude mcp list, or /mcp inside a session: the server should show as connected. If it fails, claude mcp get graphwake shows the HTTP status, such as 401 for a wrong or expired key.
Cursor
{
"mcpServers": {
"graphwake": {
"url": "https://api.graphwake.com/mcp",
"headers": {
"Authorization": "Bearer YOUR_MCP_KEY"
}
}
}
}The user-level file makes Graphwake available in every project. Cursor also reads environment variables in headers, so "Bearer ${env:GRAPHWAKE_MCP_KEY}" keeps the key out of the file. If the tools do not show up in chat, open the Output panel and choose “MCP Logs”.
VS Code with GitHub Copilot
{
"inputs": [
{
"type": "promptString",
"id": "graphwake-key",
"description": "Graphwake MCP key",
"password": true
}
],
"servers": {
"graphwake": {
"type": "http",
"url": "https://api.graphwake.com/mcp",
"headers": {
"Authorization": "Bearer ${input:graphwake-key}"
}
}
}
}VS Code asks for the key the first time the server starts and keeps it in its secret store, so this file holds no key. Use Copilot Chat in agent mode, where MCP tools are available. VS Code does not pass prompted keys on to every Copilot surface: for the Copilot CLI or another editor, add the same URL and header the way GitHub’s MCP guide describes for that client.
Other clients
URL: https://api.graphwake.com/mcp
Header: Authorization: Bearer YOUR_MCP_KEYAny client that lets you set a header on a Streamable HTTP server can use this. A client that connects only through OAuth cannot: Graphwake MCP takes an API key.
Step 3: ask who consumes an endpoint
Ask in plain words. The assistant picks the tool; you do not need to name it.
You: Who consumes GET /orders/{id}?
Assistant: → graphwake · get_endpoint("GET /orders/{id}")
Owned by payments-team. Consumed by 2 teams, 1 more suggested:
checkout · 4 people · Slack
mobile-app · 6 people · Slack
storefront · suggested 72 · maybeget_endpoint returns the owner, the consumer teams with their size and alert channel, Discovery suggestions for teams that may also use it, the last 10 shipped changes and any open pull request that breaks it. Each answer links to the matching dashboard page, so you can check it.
Step 4: check your local spec before you push
This is the step that changes how you work. Edit openapi.yaml, then ask: “Check my changes to openapi.yaml.” The assistant sends the spec file to preview_impact, which compares it with the live spec of that service.
You: Check my changes to openapi.yaml.
Assistant: → graphwake · preview_impact(local spec)
2 breaking changes, 2 teams, impact 54 (Medium)
removed total → checkout, mobile-app
required currency → checkout, mobile-app
Checked only. Nothing was stored and nobody was alerted.- What comes back: the changes, breaking first; the affected teams and people; “maybe” teams from Discovery; blind spots; and the impact score with its parts.
- What is kept: nothing. Only the spec is sent, it is compared and deleted, and nobody is alerted. Graphwake never sees your code.
- Which service: Graphwake matches the spec’s title and server URLs to a service. If that is ambiguous, it lists the candidates and the assistant asks again with the service named.
- Limits: OpenAPI 3.x in YAML or JSON (not Swagger 2.0), up to 10 MB, 30 previews a minute per key.
Step 5: subscribe your team
With a read and write key, the assistant can act on the answer: “We call GET /invoices/{id} now. Subscribe checkout.” subscribe_team follows the same permission rules as the dashboard: a member can subscribe only their own team. Admin work (people, billing, single sign-on, ownership, unsubscribing) is never reachable from an assistant.
The tools
| Tool | Ask it | Needs |
|---|---|---|
list_my_teams | Which teams am I in? | Any key |
search | Find endpoints, services or teams by name | Any key |
get_team_dependencies | What does our team depend on, and what is about to change? | Any key |
get_endpoint | Who owns and who consumes this endpoint? | Any key |
get_service | Which endpoints does this service have, and who uses them? | Any key |
list_changes | Which API changes does my team still need to handle? | Any key |
get_change_set_impact | How big is this change set, and who does it reach? | Any key |
get_endpoint_history | What happened to this endpoint, and who subscribed when? | Any key |
list_discovery_suggestions | Which teams might use an endpoint without being subscribed? | Any key |
get_overview | What happened across the workspace this week? | Any key |
preview_impact | What would my local spec break? | Any key |
list_followed_endpoints | Which endpoints do I follow myself? | Any key |
subscribe_team | Subscribe my team to this endpoint | Read and write |
decide_discovery_suggestion | Yes, we use it / Not us | Read and write |
follow_endpoint, unfollow_endpoint | Email me about this endpoint / stop | Read and write |
What Graphwake adds to your assistant
The map it cannot see
Owners and consumer teams come from subscriptions, not from searching the code in front of it.
A dry run before you push
preview_impactchecks a local spec against the live one. Nothing is stored and nobody is alerted.Your dashboard permissions, nothing more
Write access is off until you choose it, a member acts only for their own team, and admin work is never reachable.
Answers you can check
Every answer links to the dashboard page it came from, and the impact score shows its arithmetic.
When your assistant alone is enough
- Diff the spec on its own. Ask it to run oasdiff against the spec on your main branch. That tells you what breaks in the contract, for free, with no account.
- Search the code it can open. In a monorepo where every caller lives next to the API, a search for the path finds most consumers.
Callers in other repositories, and the team behind each one, are outside what the assistant can read. That list is the part Graphwake answers.
Next steps
- Why the assistant needs that map at all: does your AI coding assistant know who uses your API?
- How the alert side works once you push: API breaking change alerts.
- See the questions in action on the home page, or start a 7-day trial on Pro.
Questions
Which AI assistants work with Graphwake MCP?
Works with Claude Code, Cursor, GitHub Copilot and other clients that accept an API key.
Does Graphwake see my code?
No. The assistant asks Graphwake questions and gets data back. When you check a local spec, only that OpenAPI file is sent; it is compared and then deleted. Graphwake has no language model of its own.
Can the assistant change things in Graphwake?
Only with a read and write key, and only what you could do in the dashboard yourself: subscribe your own team, answer a Discovery suggestion, follow an endpoint. Admin work is never reachable.
Which plans include Graphwake MCP?
Pro and Enterprise, and a trial on Pro. Basic does not include it. Prices are on the pricing page.
Does checking a local spec alert anyone?
No. The local spec check is a dry run: nothing is stored and nobody is alerted. Alerts go out only when a spec reaches Graphwake from CI or from a polled spec URL.
Pick an endpoint. See who it reaches. 7-day free trial. Cancel before day 7 and you pay nothing.
Start free trialSources and last verified
- code.claude.com/docs/en/mcp
- cursor.com/docs/context/mcp
- code.visualstudio.com/docs/agents/reference/mcp-configuration
- docs.github.com/en/copilot/how-tos/provide-context/use-mcp/extend-copilot-chat-with-mcp
Sources checked on 2026-11-09.