Skip to main content
Glama
murilojrpereira

mcp-graphql-bridge

mcp-graphql-bridge

npm version CI License: MIT Node.js >= 20

A generic MCP (Model Context Protocol) server that bridges any GraphQL API to Claude Code. It introspects your GraphQL schema and exposes each query and mutation as an individual tool, letting Claude interact with your API directly.

How it works

On startup the server will:

  1. Look for a schema-introspection.json file in the working directory (fast, no network call)

  2. If not found, run live introspection against GRAPHQL_INTROSPECTION_URL

  3. Register one tool per query (query__<name>) and one per mutation (mutation__<name>)

  4. Always register a generic execute_graphql fallback tool and a get_type_details explorer tool

Related MCP server: GraphQL MCP Server

Requirements

  • Node.js >= 20

Setup

Step 1: Install

npm install -g mcp-graphql-bridge

Option B: Clone and build from source

git clone https://github.com/murilojrpereira/mcp-graphql-bridge.git
cd mcp-graphql-bridge
npm install
npm run build

Step 2: Configure environment variables

Variable

Required

Description

GRAPHQL_API_URL

No

Endpoint used for queries and mutations. Defaults to a public demo API (countries.trevorblades.com) if unset — replace with your own for real use.

GRAPHQL_INTROSPECTION_URL

No

Endpoint used for schema introspection. Defaults to GRAPHQL_API_URL if unset.

GRAPHQL_TOKEN

No

Bearer token for GraphQL authentication (used for query/mutation execution). Omit for public APIs.

GRAPHQL_INTROSPECTION_TOKEN

No

Bearer token for schema introspection, if it requires different credentials than execution (e.g. a separate schema registry). Defaults to GRAPHQL_TOKEN if unset.

MCP_AUTH_TOKEN

No

Bearer token required by the hosted /mcp HTTP endpoint when MCP_TRANSPORT=http

GRAPHQL_MAX_TOOLS

No

Maximum number of query/mutation tools to register. Queries are prioritized over mutations when truncating. Default 128.

GRAPHQL_INCLUDE_MUTATIONS

No

Set to false to exclude every mutation field entirely, for a read-only deployment. Default true.

GRAPHQL_MAX_RETRIES

No

Retries (0–5) for 429/502/503/504 responses, honoring Retry-After when present. Default 0 (disabled).

For schemas with hundreds of fields (GitHub's GraphQL API has 284 root fields — 32 queries, 252 mutations), GRAPHQL_MAX_TOOLS and GRAPHQL_INCLUDE_MUTATIONS are what keep registration bounded and predictable. If the cap truncates the schema, stderr logs exactly how many queries/mutations were registered vs. available.

No configuration is required to try the server — with nothing set, it starts against the public demo API above and logs that it's doing so. See docs/architecture.md for the full token model and why the GraphQL endpoint is fixed per deployment rather than a per-request parameter.

You can set these in a .env file at the project root:

GRAPHQL_API_URL=https://your-api.example.com/graphql
GRAPHQL_INTROSPECTION_URL=https://your-api.example.com/graphql
GRAPHQL_TOKEN=your-bearer-token

Or pass them directly via the claude mcp add command (see below).

Step 3: (Optional) Pre-generate schema snapshot

By default the server introspects your schema live on startup — no file needed, and it automatically retries at a shallower query depth if your API rejects the full-depth attempt (some APIs, especially CDN-fronted ones, enforce a query depth limit). Use this step only if your API has introspection disabled entirely in production, or you want faster startup times:

curl -s -X POST https://your-api.example.com/graphql \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer your-bearer-token" \
  -d '{"query":"{ __schema { queryType { fields { name description args { name description defaultValue type { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name } } } } } } } } type { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name } } } } } } } } } mutationType { fields { name description args { name description defaultValue type { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name } } } } } } } } type { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name } } } } } } } } } } }"}' \
  > schema-introspection.json

If your API rejects this with a depth/complexity-limit error, shrink the ofType { ... } nesting (each level resolves one more NonNull/List wrapper — most real-world types need 2-3 levels; only doubly-wrapped lists like [[Int!]!]! need more).

Adding to Claude Code

Option A: User scope (just for you)

If installed from npm:

claude mcp add --transport stdio \
  --env GRAPHQL_API_URL=https://your-api.example.com/graphql \
  --env GRAPHQL_INTROSPECTION_URL=https://your-api.example.com/graphql \
  --env GRAPHQL_TOKEN=your-bearer-token \
  graphql-bridge -- mcp-graphql-bridge

If cloned from source:

claude mcp add --transport stdio \
  --env GRAPHQL_API_URL=https://your-api.example.com/graphql \
  --env GRAPHQL_INTROSPECTION_URL=https://your-api.example.com/graphql \
  --env GRAPHQL_TOKEN=your-bearer-token \
  graphql-bridge -- node /absolute/path/to/mcp-graphql-bridge/dist/index.js

Important: Make sure to use mcp-graphql-bridge/dist/index.js (the compiled output), not mcp-graphql-bridge/index.js. The TypeScript source must be built first with npm run build, and the entry point is in the dist/ folder.

Option B: Project scope (shared with your team via .mcp.json)

claude mcp add --transport stdio --scope project \
  --env GRAPHQL_API_URL=https://your-api.example.com/graphql \
  --env GRAPHQL_INTROSPECTION_URL=https://your-api.example.com/graphql \
  --env GRAPHQL_TOKEN=your-bearer-token \
  graphql-bridge -- mcp-graphql-bridge

Note: Use absolute paths. All --env and --transport flags must come before the server name.

Verify the connection

claude mcp list

Then in a Claude Code session, run /mcp to see available servers and tools.

Examples

Two worked walkthroughs — a small public schema with no configuration needed, then a large, real enterprise-scale schema requiring auth and tool-count limits.

Example 1: Countries API (small schema, no auth)

This is the zero-config default — nothing to install or configure beyond the server itself.

  1. Add the server with no environment variables at all:

    claude mcp add --transport stdio graphql-countries -- mcp-graphql-bridge
  2. Restart Claude Code (or run /mcp to confirm graphql-countries is connected). You should see tools like query__country, query__countries, and query__continents.

  3. Ask Claude:

    Using graphql-countries, find the country with code "BR", then list its continent's other countries.

    Claude calls query__country({ code: "BR", __fields: "{ name continent { code name } }" }), then query__continent or query__countries({ __fields: "{ name }" }) filtered by the result.

  4. Try an invalid code to see error passthrough:

    Look up the country with code "ZZZ".

    Returns the GraphQL API's own error text — the bridge passes it through rather than masking it.

Example 2: GitHub GraphQL API (large schema, auth + tool limits)

GitHub's GraphQL API has 284 root fields (32 queries, 252 mutations) — far more than the GRAPHQL_MAX_TOOLS default of 128, and it needs a token for every request, including introspection (unlike GitHub's REST API, which allows some anonymous reads).

  1. Add the server, scoped to read-only access:

    export GH_TOKEN=ghp_your_personal_access_token  # or: source a gitignored .env file first
    
    claude mcp add --transport stdio graphql-github \
      --env GRAPHQL_API_URL=https://api.github.com/graphql \
      --env GRAPHQL_INTROSPECTION_URL=https://api.github.com/graphql \
      --env GRAPHQL_TOKEN=$GH_TOKEN \
      --env GRAPHQL_INCLUDE_MUTATIONS=false \
      graphql-bridge -- mcp-graphql-bridge

    GRAPHQL_INCLUDE_MUTATIONS=false registers all 32 (read-only) queries and zero mutations — comfortably under the cap, and a meaningfully safer default for an AI agent than exposing all 252 write operations.

  2. Ask Claude:

    Using graphql-github, look up the repository facebook/react and tell me its star count.

    Claude calls query__repository({ owner: "facebook", name: "react", __fields: "{ name stargazerCount }" }).

  3. To also reach mutations, drop GRAPHQL_INCLUDE_MUTATIONS=false and raise the cap (GRAPHQL_MAX_TOOLS=400), understanding that this exposes write access to your GitHub account scoped to whatever permissions your token has.

Available tools

Tool

Description

query__<name>

One tool per GraphQL query field

mutation__<name>

One tool per GraphQL mutation field

execute_graphql

Generic fallback — run any query or mutation (mutations rejected if GRAPHQL_INCLUDE_MUTATIONS=false)

get_type_details

Explore fields of a specific GraphQL type

All per-operation tools accept a special __fields argument where you can provide a custom GraphQL selection set (e.g. { id name status }). If omitted, only scalar fields are returned.

Per-call auth override: every tool (including execute_graphql) also accepts bearer_token and custom_headers arguments. If provided, they override GRAPHQL_TOKEN/no-auth for that single request only, letting Claude switch credentials per call without restarting the server.

Security

  • The target API is fixed per deployment, never a per-request parameter. Individual tool calls can override credentials (bearer_token, custom_headers) but never the destination host — GRAPHQL_API_URL is set once at deployment time. A shared server that let callers redirect it to an arbitrary destination would be a Server-Side Request Forgery (SSRF) primitive; this design rules that out by construction.

  • Configured and per-call secrets are redacted from every response before it reaches the calling LLM.

  • GRAPHQL_INCLUDE_MUTATIONS=false excludes every mutation field from registration for a genuinely read-only deployment — a meaningful trust boundary GraphQL's type system already encodes, rather than relying on token scope alone. This is enforced for execute_graphql too: it parses the query and rejects any mutation when this flag is off, rather than only omitting the convenience mutation__* tools while leaving the generic fallback able to run anything.

  • MCP_AUTH_TOKEN gates the HTTP transport's /mcp endpoint for public-routable deployments; requests are capped at 10MB.

See docs/architecture.md for the full design rationale and SECURITY.md to report a vulnerability.

Docker

Build the image

docker build -t mcp-graphql-bridge .

Add to Claude Code via Docker

claude mcp add --transport stdio \
  --env GRAPHQL_API_URL=https://your-api.example.com/graphql \
  --env GRAPHQL_INTROSPECTION_URL=https://your-api.example.com/graphql \
  --env GRAPHQL_TOKEN=your-bearer-token \
  graphql-bridge -- docker run -i --rm \
  -e GRAPHQL_API_URL -e GRAPHQL_INTROSPECTION_URL -e GRAPHQL_TOKEN \
  mcp-graphql-bridge

Note: The -i flag (no -t) is required — it keeps stdin open for the MCP stdio protocol.

HTTP deployment

For hosted MCP access, run the HTTP transport instead of stdio:

docker build -f Dockerfile.http -t mcp-graphql-bridge-http .
docker run --rm -p 8080:8080 \
  -e GRAPHQL_API_URL=https://your-api.example.com/graphql \
  -e GRAPHQL_INTROSPECTION_URL=https://your-api.example.com/graphql \
  -e GRAPHQL_TOKEN=your-bearer-token \
  mcp-graphql-bridge-http

Health checks are available at /health; MCP requests are served at /mcp.

For public-routable deployments, set MCP_AUTH_TOKEN and configure clients to send Authorization: Bearer <token> to /mcp.

See docs/deployment.md for AWS, Cloudflare, and other container hosting options.

Development

npm run dev   # watch mode: rebuilds and restarts on file changes
npm run build # one-off TypeScript compile
npm start     # run the compiled server

Troubleshooting

Error: Cannot find module '.../index.js'

If you see an error like:

Error: Cannot find module '/path/to/mcp-graphql-bridge/index.js'

You are pointing to the wrong file. The TypeScript source must be compiled first, and the entry point is in the dist/ folder:

Correct path: /path/to/mcp-graphql-bridge/dist/index.js Wrong path: /path/to/mcp-graphql-bridge/index.js

Fix:

  1. Ensure you ran npm run build (creates the dist/ folder)

  2. Update your MCP configuration to use the full path ending in /dist/index.js

Schema introspection fails

If the server starts but shows "Schema introspection failed", your GraphQL API may have introspection disabled in production. Use the curl command in step 3 of Setup to pre-generate a schema-introspection.json file.

Tools not appearing in Claude Code

  1. Run claude mcp list to verify the server is registered

  2. Run /mcp in a Claude Code session to see available tools

  3. Check that your GraphQL API's environment variables are set correctly (GRAPHQL_API_URL, GRAPHQL_INTROSPECTION_URL, GRAPHQL_TOKEN) — these are optional and default to a public demo API, so if tools still aren't appearing with your own API configured, check its credentials and endpoint URLs

Available Tools

2 tools
execute_graphqlA

Execute any GraphQL query or mutation against the API. Use this when no specific tool exists for your operation.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesFull GraphQL query or mutation string including selection set
variablesNoVariables for the operation
bearer_tokenNoBearer token to authenticate this request (overrides GRAPHQL_TOKEN)
custom_headersNoAdditional request headers as key-value pairs, e.g. {"X-Tenant-ID": "abc"}

TDQS

A3.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must disclose behavioral traits. It does not mention potential side effects of mutations, authentication requirements (beyond parameter hints), rate limits, or error handling. The description is too minimal to convey safe usage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences pack purpose and usage guidelines with zero waste, frontloading the key action and fallback use.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema; description does not explain return format, errors, or the fact that the endpoint is pre-configured. Despite the complexity of a generic GraphQL executor, the description is incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (all 4 parameters have descriptions). The description adds no additional parameter semantics. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Execute any GraphQL query or mutation against the API', specifying the verb and resource. It distinguishes itself from sibling 'get_type_details' by being a generic executor.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use this when no specific tool exists for your operation', providing clear when-to-use guidance. No exclusions, but the instruction is direct.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_type_detailsB

Get fields of a specific GraphQL type to know what to put in __fields

ParametersJSON Schema
NameRequiredDescriptionDefault
typeNameYesGraphQL type name, e.g. 'Repository', 'User', 'Issue'

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose all behavioral traits. It indicates a read operation, but does not mention error handling (e.g., invalid type name), response structure, or any side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence with no extraneous text. It is front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite the tool's simplicity, the description omits output details. The agent does not know whether the response returns field names, types, or full schema; this is critical given no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers the single parameter with a clear description and examples. The tool description adds no extra meaning beyond prompting usage of '__fields'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool gets fields of a specific GraphQL type and its purpose in GraphQL introspection. However, it does not differentiate from sibling tool execute_graphql, which may also retrieve type information.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'to know what to put in __fields' implies a use case, but there is no explicit guidance on when to use this tool versus execute_graphql, nor any when-not-to-use advice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv2.1.0
    • Changedexecute_graphql2 fields changed
      • addedInput schema / properties / bearer_token
        Added value: +{
        +  "description": "Bearer token to authenticate this request (overrides GRAPHQL_TOKEN)",
        +  "type": "string"
        +}
      • addedInput schema / properties / custom_headers
        Added value: +{
        +  "additionalProperties": {
        +    "type": "string"
        +  },
        +  "description": "Additional request headers as key-value pairs, e.g. {\"X-Tenant-ID\": \"abc\"}",
        +  "type": "object"
        +}
    • Changedget_type_details1 field changed
      • changedInput schema / properties / typeName / description
        Previous value: -"GraphQL type name, e.g. 'Machine', 'WorkOrder', 'Shift'"New value: +"GraphQL type name, e.g. 'Repository', 'User', 'Issue'"
  2. 2 tool updatesv1.0.1
    • First observedexecute_graphql
    • First observedget_type_details

TDQS

A3.9/5.0

Scored across 2 tools

Disambiguation5/5

The two tools serve clearly distinct purposes: executing GraphQL operations vs. retrieving type metadata. No overlap in functionality.

Naming Consistency5/5

Both tool names follow a consistent verb_noun pattern using snake_case (execute_graphql, get_type_details), making the intent clear and predictable.

Tool Count4/5

For a GraphQL bridge, two tools is minimal but still covers the essential operations of executing queries and exploring types. Slightly under-scoped but reasonable.

Completeness4/5

The tool surface covers core GraphQL operations (any query/mutation) and type introspection. Minor gaps exist (e.g., no dedicated tool for listing mutations), but the generic execute tool and type details suffice for agents familiar with GraphQL.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    F
    maintenance
    A MCP server that exposes GraphQL schema information to LLMs like Claude. This server allows an LLM to explore and understand large GraphQL schemas through a set of specialized tools, without needing to load the whole schema into the context
    114 npm
    47
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that enables LLMs to interact with GraphQL APIs by providing schema introspection and query execution capabilities.
    1,006 npm
    3
    MIT