MemKernel

Overview Schema Source Related Servers Discussions Admin

memkernel_query_state

Returns branch memory as JSON—tasks, decisions, active workspace facts, execution blockers, claims, leases, notices, events—and optional raw logs/scratchpad notes for coordination and audit.

Instructions

Return the consolidated memory of a branch as JSON: tasks, decisions, active workspace facts, deprecated assumptions, execution blockers, file claims, active leases, workspace-wide coordination notices and recent events. Set include_ephemeral=true to also see raw tool-execution logs and scratchpad notes not yet compacted.

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": "memkernel_query_state"
  }
}

Input Schema

Name	Required	Description	Default
`branch_id`	No
`notice_offset`	No
`notice_resource`	No
`include_ephemeral`	No
`notice_token_budget`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.3.1Nov 5, 2026
- addedInput schema / properties / branch_id / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
- changedInput schema / properties / branch_id / default
```
Previous value: -"main"New value: +null
```
- removedInput schema / properties / branch_id / type
```
Removed value: -"string"
```

Changed3 schema fields changedv0.3.0Oct 22, 2026

addedInput schema / properties / notice_offset

Added value: +{
+  "default": 0,
+  "title": "Notice Offset",
+  "type": "integer"
+}

addedInput schema / properties / notice_resource

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Notice Resource"
+}

addedInput schema / properties / notice_token_budget

Added value: +{
+  "default": 1000,
+  "title": "Notice Token Budget",
+  "type": "integer"
+}

First observedv0.1.0Oct 16, 2026

TDQS

B3/5.0

Behavior2/5

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

No annotations exist, so the description carries the full behavioral burden. 'Return' and 'query' imply a read, and the include_ephemeral sentence usefully discloses what is excluded by default, but nothing states that the call is side-effect free, what a null branch_id means, or how notice_offset and notice_token_budget paginate the notices — an omission that matters because a token budget implies truncation of results.

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?

Two sentences, front-loaded with the return payload before the optional flag, and no filler. The long content enumeration is dense but each item is meaningful, though it could be trimmed slightly since an output schema exists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the description need not enumerate return fields — doing so is a bonus rather than a gap-filler. The real gaps are the undocumented branch_id and notice pagination parameters and the absence of any read-only / side-effect statement for a mutation-free but permission-sensitive query tool.

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

Parameters2/5

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

Schema description coverage is 0% across five parameters. The description explains only include_ephemeral; branch_id, notice_offset, notice_resource and notice_token_budget are entirely undocumented in both places, and there are no defaults or semantics given for the notice pagination trio. Four of five parameters remain opaque.

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 gives a specific verb ('Return') and a specific resource ('the consolidated memory of a branch') and then enumerates the concrete content categories (tasks, decisions, facts, blockers, leases, notices, events), which is far more informative than the bare tool name. It does not, however, contrast itself with adjacent read tools such as memkernel_history or memkernel_list_branches, so an agent still has to infer the boundary.

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?

There is only one conditional hint of usage — set include_ephemeral=true when raw logs and uncompacted scratchpad notes are wanted — which implies the default is the compacted view. Nothing states when to prefer this over memkernel_history, memkernel_diff_branches or memkernel_list_branches, and there are no prerequisites or exclusions.

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