Skip to main content
Glama
Sign In
letoribo

mcp-graphql-enhanced

by letoribo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

introspect-schema

Retrieve GraphQL schema details or a federated manifest: pass typeNames to get SDL definitions for selected types, or omit them for a high-level topology overview.

Instructions

Retrieve GraphQL schema details or system manifest. READ-ONLY: Non-destructive metadata discovery. Usage: 1. If 'typeNames' is provided: Returns the full SDL (Schema Definition Language) for the requested types, including fields and relations. 2. If 'typeNames' is omitted: Returns a Federated Manifest—a high-level summary of connected nodes, their capabilities, and available domain entities (not the full schema). Use this to navigate the federated graph topology before executing queries.

Input Schema

NameRequiredDescriptionDefault
headersNoJSON stringified object of extra HTTP headers for the introspection request (e.g. '{"Authorization": "Bearer token"}').
endpointNoOptional target GraphQL HTTP/HTTPS URL to dynamically switch endpoint before execution.
typeDepthNoDepth of nested fields to retrieve (0 to 5, default: 2)
typeNamesNoList of specific GraphQL type names to introspect (max 20 types per request). If provided, returns the detailed SDL definitions for these types. If omitted, returns a system-wide Federated Manifest overview.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv4.15.4
    • changedInput schema / properties / typeDepth / description
      Previous value: -"Depth of nested fields to retrieve (default: 2)"New value: +"Depth of nested fields to retrieve (0 to 5, default: 2)"
    • changedInput schema / properties / typeNames / description
      Previous value: -"List of specific GraphQL type names to introspect. If provided, returns the detailed SDL definitions for these types. If omitted, returns a system-wide Federated Manifest overview."New value: +"List of specific GraphQL type names to introspect (max 20 types per request). If provided, returns the detailed SDL definitions for these types. If omitted, returns a system-wide Federated Manifest overview."
  2. Changed2 schema fields changedv4.15.2
    • addedInput schema / properties / endpoint
      Added value: +{
+  "description": "Optional target GraphQL HTTP/HTTPS URL to dynamically switch endpoint before execution.",
+  "type": "string"
+}
    • addedInput schema / properties / headers
      Added value: +{
+  "description": "JSON stringified object of extra HTTP headers for the introspection request (e.g. '{\"Authorization\": \"Bearer token\"}').",
+  "type": "string"
+}
  3. Addedv4.13.1
  4. Removedv4.12.0
  5. Changed1 schema field changedv4.9.2
    • removedInput schema / properties / typeDepth / default
      Removed value: -2
  6. Changed2 schema fields changedv4.8.0
    • addedInput schema / properties / typeDepth
      Added value: +{
+  "default": 2,
+  "description": "Depth of nested fields to retrieve (default: 2)",
+  "type": "number"
+}
    • changedInput schema / properties / typeNames / description
      Previous value: -"List of specific GraphQL type names to introspect. If omitted, the full schema is returned (use with caution on large APIs)."New value: +"List of specific GraphQL type names to introspect. If provided, returns the detailed SDL definitions for these types. If omitted, returns a system-wide Federated Manifest overview."
  7. Changed1 schema field changedv4.2.0
    • changedInput schema / properties / typeNames / description
      Previous value: -"List of type names to introspect"New value: +"List of specific GraphQL type names to introspect. If omitted, the full schema is returned (use with caution on large APIs)."
  8. Addedv3.9.3
  9. Removedv2.0.7
  10. Changed3 schema fields changedv1.0.0
    • addedInput schema / $schema
      Added value: +"http://json-schema.org/draft-07/schema#"
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / typeNames / description
      Previous value: -"e.g., [\"Query\", \"User\"]"New value: +"A list of specific type names to filter the introspection."
  11. First observed

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the safety burden and does so: it declares READ-ONLY/non-destructive and explains that the no-parameter mode returns a high-level summary rather than the full schema, preventing an agent from assuming completeness. It is silent on authentication expectations (only the schema's headers param hints at an Authorization header) and on introspection cost or depth limits beyond the parameter's own range.

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?

Front-loads the core action, then a short safety statement, then a numbered two-branch usage block. Every sentence changes how the tool would be called; no filler.

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

Completeness4/5

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

There is no output schema and no annotations, so the description must explain return shapes, and it does for both branches (full SDL with fields/relations vs high-level manifest). It does not cover error behavior, what happens when 'endpoint' switches the target, or the 20-type limit's failure mode, leaving minor gaps for a 4-parameter tool.

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 all four parameters are already documented, making 3 the baseline. The description reinforces the pivotal semantics of 'typeNames' (present vs absent changes the entire response shape), but adds nothing for 'endpoint', 'headers', or 'typeDepth' beyond what the schema states.

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?

States a specific verb (retrieve) and resource (GraphQL schema/SDL or federated manifest), and clearly splits the two behaviors by the presence of 'typeNames'. The closing phrase 'before executing queries' implicitly distinguishes it from the query-graphql sibling, so an agent can tell the two apart without opening either schema.

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?

Gives concrete when-to-use rules: supply 'typeNames' for detailed SDL, omit it for a federation-wide manifest, and use the manifest to orient before running queries. It stops short of naming query-graphql explicitly or stating when NOT to introspect (e.g. cost/latency of deep introspection).

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

Deploy Server

Other Tools