golestan_code_mcp

Overview Schema Source Related Servers Discussions Admin

recall

Read-only

Load stored facts from earlier sessions to reuse findings about a codebase before searching, ranked by freshness, confidence, or topic; stale facts flag changed code to verify.

Instructions

Call this at the start of a session, and before searching, to load what earlier sessions already worked out about a codebase. Returns the stored facts, fresh first and most confident first, or most related to topic when one is given, and the most recent tool calls. Each fact has its subject (a symbol or wiki page), its text, a confidence from 0 to 1, whether it is fresh or stale (and why), what wrote its text (a configured model or the template distiller), the IDs of the runs it was distilled from, and the repository, path and line range of the code it describes. A stale fact describes code that has changed since; check it with get_symbol before relying on it. Facts are distilled from earlier calls by ccctx memory consolidate and after every ingestion. Next step: get_symbol on a fact's subject to read its source, or search_code for what recall does not cover.

Input Schema

Name	Required	Description
`repo`	No	Recall only this registered repository, for example flask. list_repositories gives the valid names. Default: all repositories.
`limit`	No	How many facts to return, 1 to 50. Default 20.
`topic`	No	Put the facts most related to this first, for example "sessions" or "url_for". Default: most confident first.

Output Schema

Name	Required	Description	Default
`runs`	No
`facts`	No
`total`	No
`reason`	Yes
`status`	Yes
`truncated`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.4.2Oct 23, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, it discloses the ordering of results (fresh first, most confident or topic-relevant first), the exact fields per fact, what 'stale' means and why it matters, the distillation source, and when distillation occurs. This is rich behavioral context an agent cannot get from the annotation.

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-loaded with purpose and timing, then return shape, then next steps. It is long and dense, but nearly every sentence carries functional detail (staleness semantics, provenance, next step) rather than padding.

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

Completeness5/5

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

With an output schema present, the description still covers return semantics, staleness handling, and follow-up actions, plus the readOnlyHint annotation covers safety. Nothing an agent needs to call it correctly is missing.

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 coverage is 100%, so the schema already documents all three parameters. The description only echoes the topic-ordering behavior and repo scoping that the schema states, adding little beyond it. Baseline 3 is appropriate.

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?

States a specific verb and resource: loads facts earlier sessions derived about a codebase. It clearly distinguishes itself from siblings by framing recall as the pre-search memory step versus search_code and get_symbol.

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?

Explicitly says when to call it ('at the start of a session, and before searching') and routes the agent elsewhere for gaps ('get_symbol ... or search_code for what recall does not cover'). Alternatives and conditions are named.

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

Deploy Server