Skip to main content
Glama
Jambozx

OnlineCyberTools MCP (280+ filterable tools)

webdev_graphql_formatter

Read-onlyIdempotent

Format, minify, and validate GraphQL documents (queries, mutations, schemas) with configurable indentation and bracket-balance checking.

Instructions

GraphQL Formatter and Minifier. Pretty-print or minify a GraphQL document (query, mutation, subscription, fragment, or SDL schema) with configurable indentation, and report bracket-balance validation plus document statistics. Use webdev_sql_formatter for SQL and webdev_json_formatter for JSON. This is a syntactic formatter only: it never sends the document to a GraphQL server or executes any operation. Runs locally on the text you provide: read-only, non-destructive, contacts no external service, and is rate-limited (60 requests/minute for anonymous callers). Returns the formatted document, an isValid flag with any brace/parenthesis/bracket errors and warnings, and statistics.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
graphqlYesThe GraphQL document to format. Must not be blank.
formatNoWhen true, reindent the document; when false, return the input unchanged.
compactModeNoMinify: keep comma-separated items on one line instead of one per line.
indentSizeNoNumber of spaces per indent level (used only when indentType is spaces).
indentTypeNoIndent with spaces (honouring indentSize) or with a single tab per level.spaces
removeCommentsNoStrip GraphQL hash (number-sign) comments before formatting.
sortArgumentsNoAccepted for forward compatibility; field arguments are not reordered in the current implementation.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
originalNoThe submitted GraphQL document, echoed back.
formattedNoThe reindented (or minified) GraphQL document.
isValidNoTrue when braces, parentheses, and brackets are all balanced.
errorsNoBracket-balance errors found during validation.
warningsNoNon-fatal notes (for example, no operations or type definitions detected).
statsNoSize and content metrics for the document.
Behavior5/5

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

Beyond the annotations (readOnlyHint, destructiveHint, idempotentHint), the description adds that it runs locally, contacts no external service, and is rate-limited (60 requests/minute). It also explains that it returns validation (isValid flag, errors, warnings) and statistics, providing comprehensive behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured, front-loading purpose and usage, then behavior and return value. It is slightly verbose but every sentence adds value. Minor redundancy (e.g., 'read-only, non-destructive' partially repeats annotations) but overall efficient.

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

Completeness5/5

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

Despite having a rich input schema and output schema, the description covers all necessary aspects: purpose, when to use, behavioral constraints, parameter options, and return value summary. It leaves no critical gaps for an agent to misuse the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers 100% of parameters with detailed descriptions. The tool description adds value by summarizing the main parameters (indentation, compact mode, remove comments) and clarifying that sortArguments is forward-compatibility only 'accepted for forward compatibility; field arguments are not reordered'. This extra context justifies a score above baseline 3.

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?

The description clearly states 'GraphQL Formatter and Minifier' and specifies it can pretty-print or minify GraphQL documents (queries, mutations, subscriptions, fragments, or SDL schemas). It distinguishes itself from sibling tools by name-dropping webdev_sql_formatter and webdev_json_formatter, 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.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when to use alternatives: 'Use webdev_sql_formatter for SQL and webdev_json_formatter for JSON.' It also clarifies that the tool is syntactic only and never sends documents to a server, so the agent knows not to use it for execution or server interaction.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Jambozx/onlinecybertools-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server