KSJ MCP Server

Overview Schema Source Related Servers Discussions Admin

search_captures

Search all journal entries by concept, keyword, or phrase across every template type to find notes by idea rather than tag. Supports natural language queries and optional filters.

Instructions

Search all journal entries by concept, keyword, or phrase — across every
template type (RC, SYN, REV, DC, ISO, WA, AIEX) at once.

This is the primary way to find entries by idea rather than tag. Use it
whenever the user asks to find notes, recall something they wrote, or
explore a topic. Natural language queries work well.

Examples:
  "neural networks"        → entries mentioning neural networks
  "why does attention"     → entries with that question or phrase
  "spaced repetition"      → concept search across all templates
  "dream flying"           → DC entries with flying imagery

Args:
    query:      The concept, keyword, or phrase to search for.
    tag_filter: Optional tag value to narrow results (e.g. "machine-learning").
    date_from:  Optional ISO date lower bound (e.g. "2025-09-01").
    date_to:    Optional ISO date upper bound (e.g. "2025-12-31").
    entry_type: Optional type filter: RC, SYN, REV, DC, ISO, WA, AIEX.
    wa_reason:  Optional Wild Art reason filter (id_conflict,
                unrecognized_template, ocr_low_confidence,
                validation_error, loose_capture, manual, other).

Note: search matches terms that appear in the journal text. For tag-only
browsing without a text query, use list_by_tag instead.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`query`	Yes
`date_to`	No
`date_from`	No
`wa_reason`	No
`entry_type`	No
`tag_filter`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv3.9.0Oct 2, 2026

addedInput schema / properties / entry_type

Added value: +{
+  "default": "",
+  "title": "Entry Type",
+  "type": "string"
+}

addedInput schema / properties / wa_reason

Added value: +{
+  "default": "",
+  "title": "Wa Reason",
+  "type": "string"
+}

First observedv0.1.0Feb 20, 2026

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It discloses a useful behavioral constraint ('search matches terms that appear in the journal text' and natural-language queries work), but says nothing about ranking, pagination, result limits, or performance characteristics of a search operation. Some value added, but significant behavioral gaps remain.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded and generally well-structured, but the four-line query example block is lengthy, and the parameter list is formal (Google-style 'Args:') where the schema already names each field. Some repetition between the intro sentence and the args adds bulk without new 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?

Output schema exists, so return values need not be explained. The description covers purpose, usage, routing to a sibling, and all six parameters with the enum values. The main remaining gap is behavioral detail on search semantics (ranking, limits) which annotations also don't cover. Strong for a search tool overall, with room for behavioral specifics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it largely does: each parameter is explained with purpose and examples, including the wa_reason enum values (id_conflict, unrecognized_template, ocr_low_confidence, etc.) and entry_type codes. This adds substantial meaning beyond the bare schema. It stops short of full coverage (e.g. how tag_filter matches, date format edge cases), so not a 5.

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 specific verb+resource: 'Search all journal entries by concept, keyword, or phrase.' It further scopes by naming the coverage ('across every template type') and explicitly distinguishes itself from the tag-browsing sibling list_by_tag. An agent can tell exactly what this tool does vs neighbors.

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 when-to-use ('whenever the user asks to find notes, recall something they wrote, or explore a topic') and an explicit alternative with its selecting condition ('For tag-only browsing without a text query, use list_by_tag instead'). This is the strongest form of routing guidance.

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