Skip to main content
Glama
Sign In
second-brain-mcp

second-brain-mcp

by myr0IX
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

search_history

Searches past Claude Code conversations and Markdown notes by terms, meaning, ticket, project, or date, returning session-grouped hits to answer questions about prior work.

Instructions

Search the user's whole work history: raw Claude Code conversations (one document per exchange) and, when a notes folder is configured, their Markdown notes (decisions, topics, session notes). Use it before answering about past work: a ticket ("PROJ-123"), "why did we do X", "what was decided about Y", a bug that came back. Exact terms and meaning are both matched; results are grouped by session. Then use read_exchange to read the raw conversation around a hit.

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

Input Schema

NameRequiredDescriptionDefault
limitNoNumber of sessions to return
queryNoWhat to look for, in any wording. Optional when ticket is set.
sinceNoISO date lower bound, e.g. 2026-09-01
untilNoISO date upper bound
ticketNoExact ticket id, e.g. PROJ-123
projectNoRepo or project substring, e.g. acme

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations supplied, the description carries the burden well: it discloses what corpora are searched, that notes are included only if a folder is configured, that matching is both exact-term and semantic, and that results are grouped by session. It stops short of stating read-only guarantees, permissions, or how many hits a session group may contain.

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?

The scope statement is front-loaded and each sentence contributes something: sources, trigger cases, matching behavior, result grouping, and the follow-up tool. It is slightly dense with parenthetical asides but contains no filler that could be cut without losing guidance.

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?

For a six-parameter, zero-required search tool with no annotations and no output schema, the description covers what is searched, how hits are matched and grouped, and what to do next. What a returned session record actually contains, and whether limits or paging apply beyond the 'limit' cap, remain unstated.

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 all six parameters are already documented in structured form. The description adds only marginal meaning: the ticket example and the grouping-by-session statement reinforce that limit counts sessions, but it does not explain how query and ticket interact or how since/until combine with semantic matching.

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?

The description names a specific verb (search) and a precisely scoped resource: raw Claude Code conversations, one document per exchange, plus Markdown notes when a notes folder is configured. It also distinguishes itself from the sibling by marking read_exchange as the follow-up for reading the raw conversation around a hit.

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?

It gives explicit when-to-use guidance ('Use it before answering about past work') and concrete trigger examples: a ticket id, 'why did we do X', 'what was decided about Y', a recurring bug. It also names the alternative step and the condition that selects it ('Then use read_exchange to read the raw conversation around a hit').

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

Deploy Server

Other Tools