Skip to main content
Glama
blurrah

mcp-graphql

by blurrah

mcp-graphql

대장간 배지

LLM이 GraphQL API와 상호작용할 수 있도록 하는 모델 컨텍스트 프로토콜 서버입니다. 이 구현은 스키마 내부 검사 및 쿼리 실행 기능을 제공하여 모델이 GraphQL API를 동적으로 검색하고 사용할 수 있도록 합니다.

용법

올바른 엔드포인트로 mcp-graphql 실행하면 자동으로 쿼리를 검사하려고 합니다.

환경 변수(1.0.0의 주요 변경 사항)

참고: 버전 1.0.0부터 명령줄 인수가 환경 변수로 대체되었습니다.

환경 변수

설명

기본

ENDPOINT

GraphQL 엔드포인트 URL

http://localhost:4000/graphql

HEADERS

요청에 대한 헤더를 포함하는 JSON 문자열

{}

ALLOW_MUTATIONS

돌연변이 작업 활성화(기본적으로 비활성화됨)

false

NAME

MCP 서버의 이름

mcp-graphql

SCHEMA

로컬 GraphQL 스키마 파일에 대한 경로(선택 사항)

-

예시

지엑스피1

Related MCP server: mcp4gql

자원

  • graphql-schema : 서버는 GraphQL 스키마를 클라이언트가 액세스할 수 있는 리소스로 노출합니다. 이는 로컬 스키마 파일이거나 인트로스펙션 쿼리를 기반으로 합니다.

사용 가능한 도구

서버는 두 가지 주요 도구를 제공합니다.

  1. introspect-schema : 이 도구는 GraphQL 스키마를 검색합니다. 스키마에 리소스로 접근할 수 없는 경우 먼저 이 도구를 사용하세요. 로컬 스키마 파일이나 인트로스펙션 쿼리를 사용합니다.

  2. 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 tools
introspect-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.

ParametersJSON Schema
NameRequiredDescriptionDefault
endpointNoOptional: Override the default endpoint, the already used endpoint is: http://localhost:3000/graphql
headersNoOptional: Add additional headers, the already used headers are: {}

TDQS

A3.5/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault
endpointNoOptional: Override the default endpoint, the already used endpoint is: http://localhost:3000/graphql
headersNoOptional: Add additional headers, the already used headers are: {}
queryYes
variablesNo

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

  1. 2 tool updatesv1.0.0
    • First observedintrospect-schema
    • First observedquery-graphql

TDQS

B3.1/5.0

Scored across 2 tools

Disambiguation5/5

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.

Naming Consistency3/5

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.

Tool Count2/5

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.

Completeness2/5

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

ActivityInactive
ResponsivenessUnresponsive

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    Turn any GraphQL endpoint into a set of MCP tools
    23
    MIT
  • A
    license
    A
    quality
    D
    maintenance
    GraphQL 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.
    2
    13 npm
    3
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    MCP that can proxy any GraphQL API and expose graphql operations as mcp tools.
    13 npm
    18
    Apache 2.0
  • A
    license
    A
    quality
    A
    maintenance
    Enhanced MCP server for GraphQL with filtered introspection and full variable support.
    85
    2
    27,915 npm
    6
    MIT