This server is a GraphQL MCP server providing four fixed tools for AI agents to interact with a GraphQL API. You can:
Fetch the GraphQL schema (graphql_schema) → Get the full SDL with documentation to understand types, fields, and operations.
Validate queries pre‑execution (graphql_validate) → Check syntax, valid fields, and nesting depth without executing; receive errors and depth info.
Execute read‑only queries (graphql_query) → Fetch data with complex nested selections and variables; mutations are rejected.
Execute mutations (writes) (graphql_mutate) → Perform create/update/delete operations only when the server is started with GRAPHMCP_ALLOW_MUTATIONS=1 (or equivalent).
Safety & self‑correction → Enforces configurable limits on depth, complexity, and result size; returns structured GraphQL errors to aid agent self‑correction.
Mock blog dataset → In‑memory sample data (users, posts, comments) that resets on restart, ideal for testing.
Performance → Internal caching avoids re‑parsing and re‑validating repeated queries.
MCP integration → Works with any MCP client (Claude Desktop, VS Code agent mode, etc.).
Provides a GraphQL interface over configurable data sources, enabling agents to discover the schema, validate queries, and execute read/write operations through a single typed API.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@GraphMCP Who commented on Grace Hopper's posts?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that speaks GraphQL. Named for the spider who owns all stories: instead of exposing one tool per endpoint, Anansi spins your backend into a single typed web. The agent reads the schema, then composes exactly the query it needs — nested relations in one call, only the fields it wants.
Ships with a mock blog dataset (users → posts → comments) so you can try it the moment you clone it.
Concern | Tool-per-endpoint MCP server | Anansi |
Tool count | Grows with the API (tool explosion) | 4 fixed tools |
Over-fetching | Full payloads → wasted tokens | Agent selects only needed fields |
Related data | One round trip per relation | Nested selections, single call |
Discoverability | Prose tool descriptions | Typed schema (SDL) with doc strings |
Self-correction | Errors only after execution | Pre-flight |
Related MCP server: anyapi-mcp-server
With uv installed, add this to your MCP client config (Claude Desktop, VS Code, etc.):
{
"mcpServers": {
"anansi": {
"command": "uvx",
"args": ["anansi-mcp"],
"env": { "ANANSI_ALLOW_MUTATIONS": "1" }
}
}
}Requires Python 3.10+.
git clone https://github.com/NarglesCS/anansi.git
cd anansi
python -m venv .venv
# Windows
.venv\Scripts\python.exe -m pip install -e ".[dev]"
.venv\Scripts\python.exe -m pytest -q # verify: 12 tests
# macOS / Linux
.venv/bin/python -m pip install -e ".[dev]"
.venv/bin/python -m pytest -qnpx @modelcontextprotocol/inspector .venv/Scripts/python.exe -m anansi.serverOpens a browser UI where you can list the tools, read the graphql://schema
resource, and run queries by hand.
.vscode/mcp.json is preconfigured. Open the repo in VS Code,
start the anansi server from the MCP view, then ask Copilot agent mode things
like "Who commented on Grace Hopper's posts?" and watch it discover the schema
and compose queries.
{
"mcpServers": {
"anansi": {
"command": "/absolute/path/to/anansi/.venv/bin/python",
"args": ["-m", "anansi.server"],
"env": { "ANANSI_ALLOW_MUTATIONS": "1" }
}
}
}(On Windows the command is ...\anansi\.venv\Scripts\python.exe.)
Kind | Name | Purpose |
Resource |
| The SDL, loadable as context up front |
Tool |
| Same SDL for clients that prefer tools over resources |
Tool |
| Parse + validate + measure depth without executing |
Tool |
| Read-only execution; mutations rejected |
Tool |
| Writes, only when |
query($role: Role) {
users(role: $role) {
name
posts(limit: 2) {
title
comments { author { name } text }
}
}
}with variables {"role": "ADMIN"} returns, in one round trip:
{"data": {"users": [{"name": "Ada Lovelace", "posts": [{"title": "...", "comments": [...]}]}]}}mutation($input: CreatePostInput!) {
createPost(input: $input) { id published }
}with {"input": {"authorId": "u3", "title": "Hello", "body": "..."}}.
The store is in-memory — restart the server and you're back to the seed data.
Env var | Default | Effect |
| off | Set to |
|
| Max query nesting depth (fragment-cycle safe) |
|
| Max total fields selected per request (breadth guard) |
|
| Max serialized result size; |
Other rails: graphql_query hard-rejects mutations, subscriptions are always
rejected, and all errors come back as standard GraphQL {message, locations, path}
shapes that models know how to read and repair. Guard failures include a
remediation hint so agents can self-correct. Repeated queries skip
re-parsing/re-validation via an internal cache (execution is never cached).
flowchart LR
Agent["AI agent (MCP client)"] -- "MCP stdio" --> Tools
subgraph Anansi["Anansi server"]
direction TB
Tools["Tools: graphql_query / graphql_validate / graphql_mutate / graphql_schema"]
Schema["Resource: graphql://schema (SDL)"]
Engine["Engine: parse → gate ops → validate → depth-check → execute"]
Resolvers["Resolvers"]
end
Tools --> Engine --> Resolvers --> Store[("In-memory mock store<br/>(swap for DB / REST fan-out / services)")]
Agent -. "reads schema" .-> SchemaEach layer is independently swappable:
src/anansi/data.py — in-memory mock dataset. Replace with any real backend.
src/anansi/schema.py — SDL with doc strings (they travel to the model) + resolver wiring.
src/anansi/engine.py — execution pipeline with safety rails; no MCP dependency.
src/anansi/server.py — thin MCP wiring: tools, resource, instructions.
Swap data.py for a real datasource (SQL, REST fan-out, microservices) — the
classic GraphQL gateway pattern, now agent-facing.
Per-field auth, query cost analysis, timeouts, result-size caps.
Persisted-query allowlists for high-trust deployments.
GraphQL subscriptions mapped onto MCP notifications.
Contributions and issues welcome.
Execute a GraphQL mutation (write operation).
Only permitted when the server is started with GRAPHMCP_ALLOW_MUTATIONS=1. Example:
mutation($input: CreatePostInput!) { createPost(input: $input) { id } }
| Name | Required | Description | Default |
|---|---|---|---|
| mutation | Yes | ||
| variables | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the mutating nature and the server-side permission requirement, which are essential. However, it does not describe side effects, idempotency, or other behavioral details beyond the write nature and the environment variable condition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, front-loaded with the core purpose, and includes a useful example. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, return values need no explanation. The description provides the key permission context and clarifies the write nature, but it omits guidance on error handling, authentication specifics beyond the env var, and explicit differentiation from sibling tools. It is minimally adequate for a simple two-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'mutation' or 'variables' parameters beyond an example. The parameter names are self-explanatory, but the description adds no explicit semantic detail about expected formats, required variables, or how variables map to the mutation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute a GraphQL mutation (write operation)', using a specific verb and resource, and explicitly labels it as a write operation, which distinguishes it from sibling tools like graphql_query. The example mutation reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It indicates when the tool is permitted (server must have GRAPHMCP_ALLOW_MUTATIONS=1) and labels it as a write operation, implying it should be used for mutations rather than queries. However, it does not explicitly name alternatives like 'use graphql_query for read operations'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a read-only GraphQL query and return {"data", "errors"}.
Select only the fields you need. Example:
query($role: Role) {
users(role: $role) { name posts(limit: 2) { title } }
}with variables {"role": "ADMIN"}. Mutations are rejected here.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| variables | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses critical behavioral details: it is read-only, returns both data and errors, and explicitly rejects mutations. It also gives a concrete example of query and variables, adding useful context. It could mention auth requirements or rate limits, but for a simple read-only query tool, this is above average.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, a clear guidance to select only needed fields, and a single example that covers both parameters. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no annotations, the description provides all necessary context for an agent to invoke the tool correctly: purpose, read-only guarantee, mutation rejection, parameter format, and return shape. The sibling tools are distinguishable, and the output schema is mentioned via the return {'data', 'errors'}. It is complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, but the description fully compensates by providing a complete example showing both the 'query' string and 'variables' object with a role variable. This demonstrates the exact format for both parameters and their relationship, adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute a read-only GraphQL query' with a specific verb and resource, and explicitly distinguishes it from the sibling graphql_mutate by noting 'Mutations are rejected here.' This leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly indicates read-only usage and rejects mutations, which tells the agent when not to use this tool. However, it does not explicitly name alternatives like graphql_schema or graphql_validate, though the 'read-only' and 'mutations rejected' framing implies the correct context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the GraphQL schema (SDL). Call this before writing queries.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states the tool returns the schema, implying a read-only action, but doesn't disclose any additional behavioral details such as authentication requirements or side effects. Adequate for the simple operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action and a usage hint. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters), output schema exists, and the description provides both the purpose and a usage trigger. Complete for its scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and with schema coverage at 100% (vacuously), the description doesn't need to explain parameters. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and identifies the exact resource ('the GraphQL schema (SDL)'), clearly distinguishing it from sibling tools that validate, query, or mutate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to 'Call this before writing queries,' providing clear contextual guidance for when to use the tool, though it doesn't explicitly state exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a GraphQL query without executing it.
Returns {"valid": bool, "errors": [...], "depth": int}. Use this to catch typos and invalid fields cheaply before calling graphql_query.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It honestly states that the query is not executed and provides the return structure (valid, errors, depth), plus a hint about low cost. While it does not detail error semantics or auth requirements, the essential behavior is transparent for a validation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, immediately front-loaded with the core purpose, followed by return format and usage guidance. No extraneous words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and an output schema, the description is quite complete: it explains the operation, non-execution, return type, and when to use it in relation to a sibling. It does not allude to potential limitations (e.g., query size or schema dependence), but these are not critical for basic validation usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It identifies the parameter as 'a GraphQL query', giving meaning beyond the generic schema title 'Query', but it does not provide format examples, constraints, or additional details. This is moderate compensation for a single simple parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('validate') and resource ('GraphQL query') while explicitly noting it does not execute the query. This distinguishes it from sibling tools like graphql_query and graphql_mutate, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use this to catch typos and invalid fields cheaply before calling graphql_query.' It names an alternative tool and specifies the exact scenario (pre-execution validation), fulfilling the when-to-use criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0graphql_mutategraphql_querygraphql_schemagraphql_validateEach tool has a clearly distinct role: retrieving the schema, validating queries, executing read-only queries, and performing mutations. No overlap or ambiguity between them.
All tools share the 'graphql_' prefix and follow a predictable pattern, though 'schema' is a noun while the others are verbs. The minor inconsistency does not impede readability.
Four tools perfectly cover the core GraphQL workflow (introspect, validate, query, mutate) without unnecessary redundancy. The count is well-scoped for the server's purpose.
The tool surface is complete for a GraphQL client: schema access, validation, read and write operations. No obvious missing functionality for typical use cases.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The Grafbase MCP server sits in front of a GraphQL API and exposes an MCP protocol-compliant interface that allows AI agents and LLMs to explore and query GraphQL APIs using natural language. It provides tools to search schemas, introspect types and fields, and execute GraphQL queries while minimizing context bloat by returning only relevant schema subsets, with built-in support for authentication, authorization, and configurable access control.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Hosted MCP server for live public-data APIs and Skills for AI agents.
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/NarglesCS/Anansi'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
