XMemo

Dream View

dream_view

Idempotent

Show the caller's Dream Workspace: ideas, goals, principles and saved feed cards, with the ids dream_action takes.

Reads the personal space, or one project's space. Feature, identity and entitlement gates apply; a closed gate returns a refusal view instead of cards. Not strictly read-only: with idea lenses on, the ideas tab first retires ideas whose todo is done or whose evidence was contradicted; with outcome events on, each shown idea, principle or saved card is logged once a day as a view impression. Memories and todos are never changed.

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

Input Schema

Name	Required	Description	Default
`tab`	No	Workspace tab: ideas (default), goals, principles, feed, or all. Any other value reads ideas.	ideas
`limit`	No	Maximum cards per tab; defaults to 20.
`scope`	No	personal (default) or project:<project_key>. Any other value reads the personal space.	personal
`project_key`	No	Optional project key; reads that project's space, the same as scope project:<project_key>.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedNov 8, 2026

changedInput schema / properties / limit / description

Previous value: -"Maximum number of results to return."New value: +"Maximum cards per tab; defaults to 20."

removedInput schema / properties / limit / title
```
Removed value: -"Limit"
```

changedInput schema / properties / project_key / description

Previous value: -"Input value for the Dream View tool."New value: +"Optional project key; reads that project's space, the same as scope project:<project_key>."

removedInput schema / properties / project_key / title
```
Removed value: -"Project Key"
```

changedInput schema / properties / scope / description

Previous value: -"Optional scope that narrows memory access; leave blank for the token default."New value: +"personal (default) or project:<project_key>. Any other value reads the personal space."

removedInput schema / properties / scope / title
```
Removed value: -"Scope"
```

changedInput schema / properties / tab / description

Previous value: -"Project Workspace tab to read: overview, memory, todo, decisions, documents, conversations, timeline, settings, or home (Project Workspaces Home level-0 re-read)."New value: +"Workspace tab: ideas (default), goals, principles, feed, or all. Any other value reads ideas."

removedInput schema / properties / tab / title
```
Removed value: -"Tab"
```
removedInput schema / title
```
Removed value: -"dream_viewArguments"
```
removedOutput schema / properties / result / title
```
Removed value: -"Result"
```
removedOutput schema / title
```
Removed value: -"dream_viewOutput"
```

AddedOct 30, 2026

TDQS

A4.1/5.0

Behavior4/5

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

The annotations set readOnlyHint=false, and the description explains why by naming the two side effects: idea lenses retire ideas with completed todos or contradicting evidence, and outcome events log a once-daily view impression. It also scopes the blast radius ('Memories and todos are never changed') and discloses the gate/refusal behaviour, which annotations do not cover. What is missing is any indication of response shape or pagination, though an output schema exists.

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 purpose and the sibling relation, then uses a single dense paragraph for gates and side effects. Every sentence carries information, though the second paragraph packs gate behaviour and three distinct side effects together in a way that could be broken into clearer lines.

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?

Return values are covered by the output schema, and mutation risk, gate behaviour and non-destructive scope are all described, so the definition is nearly self-sufficient for a 4-parameter read tool. The remaining gap is the absence of any pointer to the alternative read tools an agent should consider.

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 100%, so the schema already documents tab, limit, scope and project_key, including defaults and fallback behaviour. The description adds only the mapping of the returned ids to dream_action; it does not explain the interaction between scope and project_key or give format details for project keys.

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?

Names a specific verb and resource ('Show the caller's Dream Workspace') and enumerates the content types returned: ideas, goals, principles and saved feed cards. It also explicitly ties its output to the sibling tool by noting it returns 'the ids dream_action takes', so an agent can distinguish it from dream_action and the other read tools.

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?

States the two reads it supports: the personal space or one project's space, which maps to the scope/project_key parameters. The link to dream_action implies the read-then-act workflow, but it never says when to use this instead of other read tools such as recall or get_project_context, so there is no explicit exclusion guidance.

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

All XMemo tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.