Krusgraph

Run a GraphQL query

query_graphql

Read-only

Runs a read-only GraphQL query against an API for GraphQL item; given question instead of query, it builds the query as answer_query_draft does and runs it. Requires workspace and api, plus query, or question with tables and source. Returns JSON with the data, size-bounded, and for a question the query used. Mutations and subscriptions are refused; changes nothing. describe_backend gives the field names. Errors: {error, kind, hint}.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "workspace": "<workspace>",
      "api": "<api>"
    },
    "name": "query_graphql"
  }
}

Input Schema

Name	Required	Description	Default
`api`	Yes	API for GraphQL item, name or id (list_sources: graphql_apis).
`query`	No	GraphQL query text; mutations and subscriptions are refused. Default "" (then question is used). Example: "{ customers(first: 5) { items { customer_id name } } }".
`schema`	No	Schema in the source. Default "dbo".	dbo
`source`	No	With question: the lakehouse or warehouse the API reads. Default: none. Example: "demo_lh".
`tables`	No	With question: the tables it is about. Default: none. Example: ["orders", "customers"].
`question`	No	Instead of query: a question in Swedish or English, built into a query as answer_query_draft does and run. Default: none. Example: "orders per customer".
`variables`	No	GraphQL variables for query. Default: none. Example: {"id": 42}.
`workspace`	Yes	Fabric workspace, name or id.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedOct 29, 2026

addedInput schema / properties / api / description

Added value: +"API for GraphQL item, name or id (list_sources: graphql_apis)."

addedInput schema / properties / query / description

Added value: +"GraphQL query text; mutations and subscriptions are refused. Default \"\" (then question is used). Example: \"{ customers(first: 5) { items { customer_id name } } }\"."

addedInput schema / properties / question / description

Added value: +"Instead of query: a question in Swedish or English, built into a query as answer_query_draft does and run. Default: none. Example: \"orders per customer\"."

addedInput schema / properties / schema / description

Added value: +"Schema in the source. Default \"dbo\"."

addedInput schema / properties / source / description

Added value: +"With question: the lakehouse or warehouse the API reads. Default: none. Example: \"demo_lh\"."

addedInput schema / properties / tables / description

Added value: +"With question: the tables it is about. Default: none. Example: [\"orders\", \"customers\"]."

addedInput schema / properties / variables / description

Added value: +"GraphQL variables for query. Default: none. Example: {\"id\": 42}."

addedInput schema / properties / workspace / description
```
Added value: +"Fabric workspace, name or id."
```

First observedOct 27, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and destructiveHint:false, but the description adds real value beyond them: mutations and subscriptions are refused, results are size-bounded, and errors come back as {error, kind, hint}. It stops short of saying what size-bounding does when a result is truncated or what auth/permission constraints apply under openWorldHint.

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?

Dense and front-loaded: the core action leads, then requirements, then return and error behavior. It is slightly crammed with subordinate clauses, but nearly every sentence carries information an agent needs.

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?

An output schema exists, so return values needn't be explained, yet the description still gives the shape (data plus the query used for question mode) and the error contract. For an 8-parameter open-world tool this is nearly complete; a note on size-bound behavior would close the gap.

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

Parameters5/5

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

Schema coverage is 100%, so baseline is 3, but the description earns more by explaining the coupling the schema's required list hides: query OR question+tables+source, with question being built as answer_query_draft does and describe_backend supplying field names. That is semantic guidance the schema cannot express.

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 and resource ("Runs a read-only GraphQL query against an API for GraphQL item") and immediately distinguishes its two operating modes: raw query text versus a natural-language question built the same way as answer_query_draft. An agent can tell this apart from siblings like answer_query_draft or describe_backend without opening the 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?

Explicitly states the requirements ("Requires workspace and api, plus query, or question with tables and source") which resolves the either/or the required fields alone don't convey, and points to describe_backend for field names. It gives clear context for use but doesn't say when NOT to use it versus answer_query_draft when the intent is still an open question.

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

All Krusgraph tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.