mcp-graphql
mcp-graphql
模型上下文协议 (MLM) 服务器,使 LLM 能够与 GraphQL API 交互。此实现提供了架构自检和查询执行功能,允许模型动态发现和使用 GraphQL API。
用法
使用正确的端点运行mcp-graphql ,它将自动尝试检查您的查询。
环境变量(1.0.0 中的重大变化)
**注意:**从 1.0.0 版本开始,命令行参数已被环境变量取代。
环境变量 | 描述 | 默认 |
| GraphQL 端点 URL |
|
| 包含请求标头的 JSON 字符串 |
|
| 启用变异操作(默认禁用) |
|
| MCP 服务器的名称 |
|
| 本地 GraphQL 模式文件的路径(可选) | - |
示例
# Basic usage with a local GraphQL server
ENDPOINT=http://localhost:3000/graphql npx mcp-graphql
# Using with custom headers
ENDPOINT=https://api.example.com/graphql HEADERS='{"Authorization":"Bearer token123"}' npx mcp-graphql
# Enable mutation operations
ENDPOINT=http://localhost:3000/graphql ALLOW_MUTATIONS=true npx mcp-graphql
# Using a local schema file instead of introspection
ENDPOINT=http://localhost:3000/graphql SCHEMA=./schema.graphql npx mcp-graphqlRelated MCP server: mcp4gql
资源
graphql-schema :服务器将 GraphQL 架构公开为客户端可以访问的资源。这可以是本地架构文件,也可以是基于自省查询的。
可用工具
该服务器提供两个主要工具:
introspect-schema :此工具用于检索 GraphQL 架构。如果您无法将架构作为资源访问,请首先使用此工具。它使用本地架构文件或自省查询。
query-graphql :针对端点执行 GraphQL 查询。默认情况下,除非
ALLOW_MUTATIONS设置为true,否则变更功能处于禁用状态。
安装
通过 Smithery 安装
要通过Smithery自动为 Claude Desktop 安装 GraphQL MCP 服务器:
npx -y @smithery/cli install mcp-graphql --client claude手动安装
可以手动安装到 Claude 中:
{
"mcpServers": {
"mcp-graphql": {
"command": "npx",
"args": ["mcp-graphql"],
"env": {
"ENDPOINT": "http://localhost:3000/graphql"
}
}
}
}安全注意事项
出于安全考虑,更改功能默认处于禁用状态,以防止 LLM 修改您的数据库或服务数据。在生产环境中启用更改之前,请仔细考虑。
为您自己的服务器进行定制
这是一个非常通用的实现,它允许完全自省,并允许用户执行任何操作(包括修改)。如果您需要更具体的实现,我建议您创建自己的 MCP 并锁定调用工具,以便客户端仅输入特定的查询字段和/或变量。您可以将其用作参考。
Available Tools
2 toolsintrospect-schemaA
Introspect the GraphQL schema, use this tool before doing a query to get the schema information if you do not have it available as a resource already.
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint | No | Optional: Override the default endpoint, the already used endpoint is: http://localhost:3000/graphql | |
| headers | No | Optional: Add additional headers, the already used headers are: {} |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description mentions timing ('before doing a query') but doesn't explain what the introspection actually returns, whether it's a one-time operation or cached, what format the schema information comes in, or any authentication/rate limit considerations. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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 a single, efficient sentence that front-loads the core purpose ('Introspect the GraphQL schema') followed by usage guidance. Every word earns its place with no redundancy or unnecessary elaboration. The structure is clear and appropriately sized for the tool's complexity.
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 the tool has no output schema and no annotations, the description should do more to explain what the introspection returns and any behavioral considerations. While it adequately covers purpose and basic usage, it lacks details about the return format, error conditions, or operational characteristics that would help an agent use it effectively. The description is minimally viable but has clear gaps in completeness.
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 100%, so the schema already documents both parameters thoroughly with descriptions of their optional nature and default values. The description adds no parameter-specific information beyond what's in the schema. With high schema coverage, the baseline score of 3 is appropriate since the description doesn't need to compensate for schema gaps.
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 verb ('introspect') and resource ('GraphQL schema'), and specifies the purpose is to 'get the schema information'. It distinguishes from the sibling tool 'query-graphql' by indicating this is for schema discovery rather than query execution. However, it doesn't explicitly contrast with the sibling beyond implied timing ('before doing a query').
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 clear context on when to use this tool: 'before doing a query to get the schema information if you do not have it available as a resource already'. It implies an alternative (having the schema as a pre-existing resource) and gives timing guidance. However, it doesn't explicitly state when NOT to use it or provide detailed comparison with the sibling tool beyond the basic distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query-graphqlC
Query a GraphQL endpoint with the given query and variables
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint | No | Optional: Override the default endpoint, the already used endpoint is: http://localhost:3000/graphql | |
| headers | No | Optional: Add additional headers, the already used headers are: {} | |
| query | Yes | ||
| variables | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the action but lacks details on permissions, rate limits, error handling, or response format. This is inadequate for a tool that interacts with an external endpoint, leaving significant gaps in understanding its behavior.
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 a single, efficient sentence with zero waste. It is appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.
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 the complexity of querying a GraphQL endpoint, no annotations, no output schema, and incomplete parameter documentation, the description is insufficient. It fails to address critical aspects like authentication, response structure, or error scenarios, making it incomplete for effective tool use.
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 50% (2 out of 4 parameters have descriptions). The description adds minimal value beyond the schema, as it only mentions 'query and variables' without explaining their formats or relationships. It doesn't compensate for the undocumented parameters (query and variables lack schema descriptions), resulting in a baseline score due to partial coverage.
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 verb ('Query') and resource ('a GraphQL endpoint'), specifying what the tool does. It distinguishes from the sibling 'introspect-schema' by focusing on general query execution rather than schema introspection, though it doesn't explicitly mention this distinction.
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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention the sibling tool 'introspect-schema' or any other context for selection. It simply states the action without usage context.
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.
2 tool updates
v1.0.0- First observed
introspect-schema - First observed
query-graphql
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: introspect-schema retrieves schema information, while query-graphql executes queries. There is no overlap or ambiguity between them, making it easy for an agent to select the correct tool.
The tools use a verb-noun pattern (introspect-schema, query-graphql), which is consistent. However, the hyphenated naming style is less common than snake_case or camelCase, and with only two tools, it's hard to assess full consistency, but they follow the same convention.
With only two tools, the server feels thin for a GraphQL domain, which typically involves operations like mutations, subscriptions, or schema updates. While core querying is covered, the scope is limited, potentially requiring agents to work around missing functionality.
The server covers basic introspection and querying but lacks essential GraphQL operations like mutations (for data modification) or subscriptions (for real-time updates). This creates significant gaps that could lead to agent failures when full lifecycle management is needed.
Maintenance
Related MCP Connectors
Monday.com MCP — wraps the Monday.com GraphQL API (BYO API key)
Product Hunt MCP — wraps the Product Hunt GraphQL API v2 (api.producthunt.com)
An MCP server that provides access to Agility CMS. See https://mcp.agilitycms.com for more details.
- SupabaseOAuthcom.supabase
MCP server for interacting with the Supabase platform
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceTurn any GraphQL endpoint into a set of MCP tools23MIT
- AlicenseAqualityDmaintenanceGraphQL MCP Server that acts as a bridge allowing MCP clients (like Cursor or Claude Desktop) to interact with target GraphQL APIs through standard tools for schema introspection and operation execution.26 npm3MIT
- AlicenseNot gradedqualityDmaintenanceMCP that can proxy any GraphQL API and expose graphql operations as mcp tools.8 npm18Apache 2.0
- AlicenseAqualityAmaintenanceEnhanced MCP server for GraphQL with filtered introspection and full variable support.3827,197 npm3MIT