Skip to main content
Glama
Sign In
kernl

kernl

by fastslack
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

kernel_facts_explain

Explain why an agent acted by comparing the facts it believed at decision time with what later proved true, and return a verdict: consistent, late_information, or wrong_belief.

Instructions

Why did Kernl (or an agent) act that way? Give the person or thing (subject ref or name) and the moment of the decision — at, or action_ref, the id of what the action produced or touched (an email, a task…). Returns what Kernl believed then against what is now known to have been true then, fact by fact, who wrote each belief and from what source, and a verdict: consistent, late_information (the world changed but Kernl learned it after the decision) or wrong_belief (the stored fact was later corrected as a mistake).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "kernel_facts_explain"
  }
}

Input Schema

NameRequiredDescriptionDefault
atNoThe moment of the decision (ISO).
nameNoOr a name to find the subject by.
subjectNoA fact subject, e.g. "Person:<id>".
predicateNoOnly this predicate (works_at, email…).
action_refNoOr the id of what the action produced or touched; its first recorded call gives the moment.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.1

TDQS

A3.7/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 behavioral burden, and it delivers the non-obvious part: the verdict taxonomy (consistent, late_information, wrong_belief) and what each means, plus the fact that source and author of each belief are returned. It never explicitly states that this is a read-only, side-effect-free operation, nor mentions permissions or cost, which is the remaining gap for an unannotated tool.

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

Conciseness3/5

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

It is front-loaded with the motivating question and stays in a single paragraph, but the rhetorical opener and the scattered parentheticals ('an email, a task…') add bulk without adding precision. Dense and mostly earned, yet it could be tightened into a cleaner input/return split.

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?

Five optional parameters and an output schema mean the description only needs to cover selection semantics and result interpretation, both of which it does. The main omission is the absence of any read-only/authorization statement for a tool with zero annotations, and no guidance on what happens if neither a subject nor an action_ref is supplied.

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?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: it clarifies that subject and name are alternative ways to identify the subject, that at and action_ref are alternative ways to fix the moment, and that action_ref's 'first recorded call' supplies the timestamp. That alternative-pairing logic is not obvious from the schema alone.

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 names a specific verb and resource — explaining why an action happened — and enumerates the outputs (beliefs at decision time vs. later-known truth, per-fact attribution, and a verdict). That is far more than a restatement of the name. It stops short of naming a sibling such as kernel_facts_as_of, so the boundary with the closest alternative is left implicit.

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?

It tells the agent what inputs select the subject and the moment ('give the person or thing ... and the moment of the decision'), which effectively describes the invocation pattern. But there is no explicit when-to-use vs. when-not, and no routing to kernel_facts_as_of or kernel_facts_query, which are the obvious near-neighbors for retrospective fact lookups. Usage is implied rather than stated.

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

Deploy Server

Other Tools