KSJ MCP Server

Overview Schema Source Related Servers Discussions Admin

dream_correlation

Reports co-occurrence between Dream Capture and RC/REV journal entries sharing a #tag within a chosen day window, including match counts and base rates to separate coincidence from pattern.

Instructions

Report co-occurrence between Dream Capture entries and RC/REV entries
sharing #tag, within window_days of each other. Descriptive only.

This deliberately never uses the word "correlation" in its own output
(window size is a free parameter, and with a small journal, trying a
few window widths will surface something that looks meaningful — the
same researcher-degrees-of-freedom failure mode your own experimental
methodology is built to defeat). Every result reports window_days, the
match count, and the base rate of #tag in each population, so a
coincidence and a pattern don't read the same on the page.

Args:
    tag:         The # topic/theme tag to check (e.g. "resilience").
                 Matched against DC's #theme tags and RC/REV's #topic
                 tags — same prefix, same normalized value, different
                 template role.
    window_days: How many days apart counts as "near" (default 3).
                 Symmetric — checks both before and after each dream.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`tag`	Yes
`window_days`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv3.9.0Oct 2, 2026

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does well: it discloses that output is purely descriptive, that every result includes window_days, match count, and per-population base rates, and it explains the researcher-degrees-of-freedom rationale for not labeling results as 'correlation'. This goes well beyond a bare read/analysis disclosure. It does not state computational complexity, refresh behavior, or permission requirements, which keeps it short of a 5.

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?

Core purpose is front-loaded in the first sentence, which is good, but the parenthetical about researcher degrees of freedom is lengthy and partly editorializing rather than specification. It earns some place by justifying the descriptive-only stance, yet a tighter phrasing could convey the same behavioral guarantee. Args block is well structured.

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?

Given two parameters, no annotations, a presence of output schema (so return values needn't be explained), and the analytic nature of the tool, the description is largely complete. It covers what is computed, how matching works, the symmetric window, and what each result reports. It omits any mention of performance implications for large journals or how ties/duplicates are handled, keeping it just short of fully exhaustive.

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: it explains that tag is a # topic/theme value matched across DC's #theme and RC/REV's #topic tags (same prefix, normalized value, different template role) and that window_days is a symmetric day-distance threshold with default 3. This adds real semantic meaning absent from the schema. Minor gaps remain: no format examples beyond one, no bounds on window_days.

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 states a specific verb (report co-occurrence), the two concrete resources it spans (Dream Capture entries and RC/REV entries), and the exact matching dimension (#tag within window_days). It is clearly distinguishable from siblings like dream_patterns or bridge_dream_research, which do different analyses. An agent can tell exactly what this tool computes without inspecting the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied (analyze tag co-occurrence between dreams and research entries), but there is no explicit statement of when to choose this over dream_patterns or bridge_dream_research, nor any exclusion criteria. The 'descriptive only' caveat hints at a usage boundary but does not name an alternative. An agent gets a reasonable sense of context but must infer relative routing.

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