Skip to content
R1-MCP
Get Support

GraphQL API support

The GraphQL feature adds call_r1_gql, which queries the RUCKUS AI internal GraphQL services — the data behind Network Health, Incidents, IntentAI, Service Validation, and Zoom Call QoE. It answers questions the REST API doesn’t expose.

This is an Early Access feature: unlock Early Access on your account, then enable it under Features in the dashboard.

call_r1_gql takes a service argument that picks the endpoint. All four run on the same host and the same bearer token as REST, so there is no extra credential to configure.

serviceWhat it covers
analyticsNetwork Health, Incidents, Config Change, client and incident troubleshooting
intentAIIntentAI
serviceGuardService Validation — has real mutations
callQoeZoom Call QoE

Beyond service and query, it accepts variables, operationName for a document that defines several operations, and retryOn429.

All four services refuse introspection. That is a property of the RUCKUS services, not a restriction R1-MCP adds — so there is no way to discover the schema by probing it.

Instead, R1-MCP ships curated schema documents that Claude fetches with get_reference before composing a query:

DocCovers
gql-analyticsThe analytics surface, and IntentAI
gql-troubleshootingClient and incident troubleshooting, and Call QoE
gql-service-guardService Validation

The docs are organized by surface, not one per service — which is why IntentAI lives in gql-analytics and Call QoE in gql-troubleshooting.

A GraphQL request can fail while returning HTTP 200, because execution-time errors arrive in-band. call_r1_gql hoists both data and gqlErrors onto the response so this is hard to miss: gqlErrors is null when the query was clean and populated on every failure. A populated gqlErrors means the query failed, whatever the HTTP status says.

Validation failures arrive as HTTP 400. On analytics, intentAI, and serviceGuard those errors are genericDATAAPI-10102 or SERVICEGUARD-10102 — and do not name the offending field. Only callQoe identifies the bad field. So when a query fails validation, the fix is to re-check it against the reference doc rather than to expect the error to point at the problem.

GraphQL requests are always POSTs, so a 429 is never auto-retried by default — unlike the idempotent REST methods described in How code mode works.

retryOn429: true opts in, and is safe only for read queries. serviceGuard has real mutations, which are not safe to replay.

Everything else behaves like call_r1: the same 401 refresh-and-retry, the same structural error envelope, and the same shared run budget.