Planning System MCP Server

recall_knowledge

Query a universal knowledge graph to retrieve facts, entities, recent episodes, and contradictions. Control output size with result_kind for efficient planning.

Instructions

Universal knowledge graph query. Returns facts, entities, recent episodes, and contradictions in one shape. Use result_kind to control payload size. Replaces recall_knowledge legacy + find_entities + get_recent_episodes + check_contradictions.

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

Input Schema

Name	Required	Description	Default
`query`	No	Search query — required for facts/entities, optional for episodes
`scope`	No
`since`	No	ISO 8601 — only return episodes after this
`entry_type`	No		all
`result_kind`	No		all
`max_results`	No
`include_contradictions`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.8.1Apr 29, 2026

TDQS

A3.8/5.0

Behavior3/5

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

No annotations exist, so description carries full burden. It discloses that the tool returns multiple data types in one shape and that result_kind controls payload. However, it doesn't mention side effects, auth needs, rate limits, or behavior with no results. Adequate but not thorough for a complex tool.

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 sentences, front-loaded with purpose, efficient. Every sentence adds value: states what it does, mentions result_kind control, and notes replacement of legacy tools. No waste.

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?

Given 7 parameters including nested objects and no output schema, the description is brief. It doesn't explain the output shape ('one shape') or how to interpret combined results. With siblings like search and list_goals, more context on when to use this vs. others would help. Adequate but incomplete for full understanding.

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 29% (low). Description adds value for result_kind ('controls payload size') but does not explain query, scope, since, entry_type, max_results, or include_contradictions beyond schema. With such low coverage, description should compensate more; it falls short.

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?

Description clearly states it's a universal knowledge graph query returning facts, entities, episodes, and contradictions. It specifically mentions replacing legacy tools (recall_knowledge legacy, find_entities, get_recent_episodes, check_contradictions), distinguishing it from those. The verb 'query' and resource 'knowledge graph' are specific.

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?

Explicitly says it replaces multiple tools, giving clear context for when to use it over those legacy alternatives. Suggests using result_kind to control payload, but does not provide guidance on when not to use it or alternatives among siblings (e.g., search). Implied usage but no exclusions.

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