Krusgraph

Suggest a GraphQL or T-SQL query for a question (runs nothing)

answer_query_draft

Read-only

Turns a question in Swedish or English about given tables into T-SQL over the plan's safest join path, and with api into GraphQL in that API's field names, or says why GraphQL cannot answer it. Requires workspace, source, question and tables. Returns JSON with the query, each join step with its rule, and what it assumed. Runs nothing; query_graphql runs the GraphQL version. 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>",
      "source": "<source>",
      "question": "<question>",
      "tables": "<tables>"
    },
    "name": "answer_query_draft"
  }
}

Input Schema

Name	Required	Description	Default
`api`	No	API for GraphQL item over the source; when given, a GraphQL query is drafted too. Default: none (T-SQL only). Example: "shop_api".
`keys`	No	Primary keys replacing the inferred ones. Default: inferred. Example: {"order_items": ["order_id", "line_no"]}.
`schema`	No	Schema in the source. Default "dbo".	dbo
`source`	Yes	Lakehouse, warehouse or SQL database, name or id.
`tables`	Yes	Tables the question is about, exact names. Example: ["orders", "customers"].
`question`	Yes	The question, in Swedish or English. Example: "total amount per customer last month".
`confirmed`	No	Relationships the user confirmed, added to the plan. Default none. Example: [{"source": "orders", "source_cols": ["ship_to_id"], "target": "addresses", "target_cols": ["address_id"]}].
`workspace`	Yes	Fabric workspace, name or id.
`show_personal_data`	No	true includes columns named like personal data; false (default) masks or omits them.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedOct 29, 2026

addedInput schema / properties / api / description

Added value: +"API for GraphQL item over the source; when given, a GraphQL query is drafted too. Default: none (T-SQL only). Example: \"shop_api\"."

addedInput schema / properties / confirmed / description

Added value: +"Relationships the user confirmed, added to the plan. Default none. Example: [{\"source\": \"orders\", \"source_cols\": [\"ship_to_id\"], \"target\": \"addresses\", \"target_cols\": [\"address_id\"]}]."

addedInput schema / properties / keys / description

Added value: +"Primary keys replacing the inferred ones. Default: inferred. Example: {\"order_items\": [\"order_id\", \"line_no\"]}."

addedInput schema / properties / question / description

Added value: +"The question, in Swedish or English. Example: \"total amount per customer last month\"."

addedInput schema / properties / schema / description

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

addedInput schema / properties / show_personal_data / description

Added value: +"true includes columns named like personal data; false (default) masks or omits them."

addedInput schema / properties / source / description

Added value: +"Lakehouse, warehouse or SQL database, name or id."

addedInput schema / properties / tables / description

Added value: +"Tables the question is about, exact names. Example: [\"orders\", \"customers\"]."

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

First observedOct 27, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already flag readOnly and non-destructive, and the description reinforces and extends this with 'Runs nothing', the exact return payload (query, each join step with its rule, stated assumptions) and the error envelope {error, kind, hint}. That is materially more than the annotations convey.

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?

Three dense sentences with the core purpose front-loaded and no filler. The middle clause ('and with api into GraphQL in that API's field names') is grammatically tangled, costing some readability.

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?

For a 9-parameter drafting tool with an output schema, everything an agent needs is present: required inputs, default behaviour without api, return content and error shape. Nothing critical is left ambiguous.

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 coverage is 100%, so per-parameter meaning is already documented, including the api option's effect. The only genuine addition is that with api the tool either emits GraphQL or explains why GraphQL cannot answer — the rest restates schema content, so baseline 3 applies.

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 names a precise transformation (question → T-SQL over the safest join path, and optionally → GraphQL in the API's own field names) rather than a vague 'query helper'. The title and first sentence make clear it drafts and runs nothing, which separates it from query_graphql.

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?

It explicitly states 'Runs nothing; query_graphql runs the GraphQL version', giving the agent a concrete execute-vs-draft alternative. It stops short of positioning against the modelling siblings like join_path or suggest_relationships, which an agent might also reach for.

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.