Turnbook

by goyohan0611-png

Overview Schema Source Related Servers Discussions Admin

Python

Local

brain_recall

Read-onlyIdempotent

Raw lookup: the matching memories and turns as structured rows, not a ready context.

Instructions

Raw lookup: the matching memories and turns as structured rows, not a ready context.

    `source`: open the conversation around one turn. Pass the part after "Source: <app> / "
    of a conversation item in brain_context's packet. A packet shows one excerpt of each turn;
    when it is cut off, or the answer is likely in the rest of that exchange (your reply
    right after the user's request, a list you gave, the line before), this returns those
    turns in full, in order (`limit` caps how many follow; two come before).

    To answer the user's question from their past, use brain_context instead; it returns one
    bounded text packet ready to read. Use brain_recall to inspect or list: the ids and fields
    of what matched (e.g. before brain_forget or `supersedes_memory_id`), one thing's history
    in order, or what the store knows about.

    `entity` answers "what happened to X, in order": every memory about that one thing (the
    auth module, this project, my address), oldest first, with replaced entries marked and the
    current one picked out. Similarity search returns only the nearest one or two of four
    decisions made about one thing in four sessions; this returns all four. With neither
    `query` nor `entity`, it lists what the store knows about, busiest first.

    `recent`, `since`, `about_assistant` and `around` mean the same as in brain_context.

Input Schema

Name	Required	Description
`as_of`	No	ISO time: only what had happened by then (default now).
`limit`	No	Most items to return.
`query`	No
`since`	No
`around`	No
`entity`	No
`recent`	No
`scopes`	No	Only these scopes, e.g. ["global"] or a project; default all.
`source`	No
`about_assistant`	No
`knowledge_cutoff`	No	ISO time: only what had been saved by then (default as_of).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.9.39Oct 22, 2026

addedInput schema / properties / source

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

Changed4 schema fields changedv0.9.5Oct 19, 2026

addedInput schema / properties / as_of / description

Added value: +"ISO time: only what had happened by then (default now)."

addedInput schema / properties / knowledge_cutoff / description

Added value: +"ISO time: only what had been saved by then (default as_of)."

addedInput schema / properties / limit / description
```
Added value: +"Most items to return."
```

addedInput schema / properties / scopes / description

Added value: +"Only these scopes, e.g. [\"global\"] or a project; default all."

First observedv0.1.0Oct 15, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already establish the read-only, idempotent, non-destructive profile, and the description layers on real behavior: `source` returns following turns in full and in order with two preceding turns included, `entity` returns oldest-first with replaced entries marked and the current one picked out. It doesn't state what happens on an empty match or how rows are shaped, but the remaining gaps are minor given annotation coverage.

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?

Front-loads the one-line summary, then organizes remaining text by parameter with backticked anchors, so it is scannable despite length. Some phrasing ("when it is cut off, or the answer is likely in the rest of that exchange") is more verbose than needed, but nothing is filler.

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 shape needn't be described, and the description covers the modes an agent must choose between plus ordering semantics for the two most important ones. The unanswered parameters and the reliance on brain_context's description for shared parameters keep it short of complete.

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?

With only 36% schema coverage and 11 parameters, the description carries heavy burden. It gives rich semantics for `source`, `entity` and `limit` (in the source context), but `query`, `as_of`, `knowledge_cutoff` and `about_assistant` are never explained, and four parameters are deferred wholesale via "mean the same as in brain_context" — a cross-reference that requires the sibling's description to be in context.

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?

Opens with a precise characterization ("Raw lookup: the matching memories and turns as structured rows, not a ready context") that names both the verb and the resource, and immediately contrasts it with brain_context's packet output. An agent can distinguish it from every sibling without opening a schema.

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

Usage Guidelines5/5

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

Explicit routing guidance: "To answer the user's question from their past, use brain_context instead" versus "Use brain_recall to inspect or list" with three concrete inspection cases (ids before brain_forget, one thing's history, store inventory). It also tells exactly when to escalate from a brain_context packet via `source`.

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

Deploy Server