kernl

Overview Schema Source Related Servers Discussions Admin

kernel_graph_ask

Ask your personal graph a question in plain words. It writes a read-only query from the schema, runs it, corrects its own errors, and returns rows with the query used.

Instructions

Ask Kernl's graph a question in plain words ("which people did I email most last month?", "what tasks depend on the report?"). It writes a read-only query from the graph's schema, runs it, fixes it from its own errors, and returns the rows with the query it used.

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": {
      "question": "<question>"
    },
    "name": "kernel_graph_ask"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No
`question`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.5.1Nov 13, 2026

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses that the tool generates its own query, is read-only, self-corrects from errors, and returns both rows and the query it ran. It omits failure modes (what happens if the query never succeeds), latency, and any cost or rate considerations, which keeps it from a 5.

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?

Two tight sentences: the purpose with examples is front-loaded, followed by a compact description of the internal pipeline and return shape. No filler, and the inline examples do more work than a longer explanation would.

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?

For a natural-language-to-query tool with an output schema, the essentials are covered — input format, read-only nature, self-repair behavior, and what comes back. The gap is the undocumented 'limit' parameter and the absence of any statement about behavior when query generation ultimately fails.

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 0%, so the description must compensate. It effectively illustrates the 'question' parameter through two sample questions, which is real added meaning. However, 'limit' is never mentioned — its purpose and its effect (capping returned rows?) must be guessed from the name and default of 30.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: ask a plain-language question of Kernl's graph, with two concrete example questions. It implicitly distinguishes itself from query-language siblings like kernel_graph_query by emphasizing 'plain words,' but never names an alternative outright, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Usage is implied rather than stated: the examples make clear this is for natural-language questions, but there is no explicit when-to-use, when-not-to-use, or routing to kernel_graph_query or kernel_graph_analyze. An agent can infer the context but must open sibling schemas to be sure.

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

Deploy Server