Best AI Agent Skills for GraphQL APIs (2026)

Our directory currently lists 97 agent skills that mention APIs. Seven of them mention GraphQL. That ratio tells you most of what you need to know about where the tooling stands in 2026: it caught up on REST and OpenAPI, and GraphQL teams are working with a much thinner shelf.

That is not a reason to skip skills entirely. It is a reason to be deliberate about which ones you install, and to know which parts of GraphQL work an agent still handles badly without help. Here is the honest inventory, ordered by how much they change day-to-day work.

What is actually available

Note the install-type column. Only Apollo Client installs as a true agent skill (claude skill add). The rest are MCP servers, which is a different thing: a skill teaches the model how to write code, an MCP server hands it a live connection to something. Both are useful and they solve different problems, which is worth reading our MCP servers versus agent skills explainer on if the distinction is fuzzy.

1. Apollo Client: the only real GraphQL skill

claude skill add apollographql/apollo-client

Repo: apollographql/apollo-client. Verified tier, MIT, community-reviewed, and the only entry here that installs as a skill rather than a server.

What it earns its place on is cache behavior. An agent writing Apollo code without guidance produces queries that technically run and then quietly break the moment two components request overlapping fields. Normalization, cache policies, fetchPolicy choice, optimistic updates that roll back correctly: this is the layer where GraphQL client code goes wrong, and it is the layer generic coding models get wrong most consistently.

The skill covers TypeScript codegen alongside React, Vue and Angular bindings. If your stack is Apollo, install it. If you are on urql or graphql-request, the cache concepts still transfer but the API calls will not.

2. Grafbase: federation without hand-editing supergraph config

claude mcp add grafbase -- npx -y grafbase/grafbase

Repo: grafbase/grafbase. Verified, MPL-2.0. Last updated July 2026 in our data.

Federation is where GraphQL gets genuinely hard, and where an agent with no context makes expensive mistakes: entity keys that do not resolve across subgraphs, @shareable sprinkled to silence composition errors, ownership boundaries drawn where the org chart is rather than where the data is.

A federation gateway with MCP access lets the agent inspect the composed supergraph instead of guessing at it. That changes the failure mode from "generates plausible subgraph SDL" to "generates SDL that composes."

MPL-2.0 is a weak copyleft license. It is fine for the overwhelming majority of commercial use, but if your legal team maintains an approved-license list, check it is on there before the pilot rather than after.

3. Data API Builder: GraphQL over a database you already have

claude mcp add data-api-builder -- npx -y Azure/data-api-builder

Repo: Azure/data-api-builder. Verified, MIT, maintained by Microsoft.

This generates REST and GraphQL endpoints (plus MCP tools) over Azure databases and on-prem stores from configuration rather than code. For an agent workflow the appeal is obvious: instead of asking the model to write resolvers, you ask it to write config, and config is far easier to review than a resolver layer nobody will read again.

The tradeoff is the usual one for generated APIs. You get a schema shaped like your tables, which is exactly what GraphQL was invented to avoid. Good for internal tools and admin surfaces. Bad as your public product API.

4. mcp2cli: the underrated one

claude mcp add mcp2cli -- npx -y knowsuchagency/mcp2cli

Repo: knowsuchagency/mcp2cli. Verified, MIT.

It turns any GraphQL, OpenAPI, or MCP server into a CLI at runtime with no codegen step. That sounds like a developer-convenience toy until you watch an agent use it. Given a CLI, the model can explore your graph by running commands and reading output, which is a much tighter loop than reasoning about a schema file it was handed once.

Cheapest install on this list for what it costs you in context, and the one I would try first if you want to see whether agent-driven GraphQL work is worth pursuing at all.

5. Webiny: if the graph is a CMS

claude mcp add webiny-js -- npx -y webiny/webiny-js

Repo: webiny/webiny-js. Verified, license listed as Other, which means read it.

Open-source self-hosted headless CMS on AWS serverless, with a GraphQL API, multi-tenancy, and lifecycle hooks. Relevant here only if you are choosing a CMS. Nobody should install this to get better at GraphQL generally.

6. Apollo MCP Server: useful, and the one to audit

claude mcp add apollo-mcp-server -- npx -y apollographql/apollo-mcp-server

Repo: apollographql/apollo-mcp-server. MIT, but community tier with security status listed as unreviewed and 301 stars.

The concept is sound: expose your graph's operations to an agent as MCP tools, so it calls real operations against a real schema instead of hallucinating field names. Apollo maintaining it is a meaningful signal of intent.

Unreviewed status still means what it says. An MCP server that talks to your graph is a server that can execute operations against your graph. Read the config, scope the credentials to a read-only role for anything past local development, and do not point it at production on day one.

The gap nobody has filled

Four GraphQL problems have no dedicated skill in our directory, and they are the four that cost real money:

N+1 resolvers. DataLoader batching is the single most common GraphQL performance bug, and a general coding model writes the naive version by default. You have to ask for batching explicitly, every time.

Schema evolution. Deprecating a field on a public graph without breaking a client is a discipline, not a code change. Nothing here helps with it. Atlas covers declarative migration workflows on the database side, which is adjacent but not the same problem.

Query cost limiting. Depth limits, complexity scoring, persisted queries. No skill covers the abuse surface that GraphQL opens by design.

Authorization. Field-level auth in GraphQL is where most real security bugs live, because permission checks scattered across resolvers are easy to get subtly wrong. Nothing on this list addresses it.

Until those exist, the practical workaround is unglamorous: keep your own conventions in CLAUDE.md, and put the specific rules there (always batch with DataLoader, never expose a resolver without an auth check, cap depth at N). Project instructions are worse than a good skill and better than nothing.

The stack I would actually run

For a team building on GraphQL today:

1. Apollo Client skill, if you are on Apollo. It is the only one that improves generated code directly. 2. mcp2cli, so the agent can explore the graph rather than guess. 3. Grafbase, if you run federation. Skip it if you have one service. 4. A database-layer skill, because most resolver bugs are really data-access bugs. Prisma or Drizzle depending on your ORM, and our Prisma versus Drizzle versus Supabase comparison covers the choice. 5. Written conventions for N+1, auth, and cost limiting, since no skill covers them.

Teams doing REST alongside GraphQL should also read the API design and OpenAPI skills roundup, which has a considerably deeper bench, and the database schema design roundup for the layer underneath.

More broadly, our full list for developers covers the tooling that sits around all of this.

FAQ

Is there an official Anthropic skill for GraphQL? No. The official skills in our directory cover frontend design, MCP building, and document work. GraphQL support comes from vendor repos like Apollo and Grafbase.

Should I use an MCP server or an agent skill for GraphQL? Both, for different jobs. Install the Apollo Client skill so generated code follows correct patterns. Add an MCP server so the agent can inspect a live schema. Code quality and schema awareness are separate problems and one does not substitute for the other.

Can Claude write GraphQL resolvers without any skill installed? It can write resolvers that work. What it will not do reliably is batch them. Expect a working N+1 that passes tests and falls over under load, and review data-access patterns specifically rather than trusting a green test suite.

Is it safe to connect an MCP server to my production graph? Not without scoping. Use read-only credentials, limit the operations the server exposes, and start against staging. For the Apollo MCP Server in particular, its unreviewed security status means you should read the source before it touches anything with customer data.

What about GraphQL Yoga, urql, or Relay? Nothing dedicated in our directory yet. The Apollo Client skill's cache and codegen concepts partially transfer, but the API surface is different enough that you will be correcting generated calls. If you use Relay, written project conventions will do more for you than any skill currently available.