This read-only MCP server lets you explore and analyze a corpus of timeline-shift folklore, Mandela Effect reports, and symbolic stories, with evidence grading, source citation, and clear separation of belief, neutral, and skeptical framings. Key capabilities:
Search reports (timeline_search_reports) by text, motifs, phenomenon type, source type, stance, evidence grade, or date range, with pagination.
Retrieve full reports (timeline_get_report) with labeled claims, source metadata, anchors, motifs, related reports, safety flags, and recommended phrasing for agents.
Browse Mandela catalog (timeline_mandela_catalog) for remembered vs. on-record variants and mainstream explanations.
Explore motif map (timeline_motif_map) for recurring symbols, definitions, families, frequencies, and co-occurrence edges.
Read story threads (timeline_story_threads) in belief, neutral, and skeptical versions.
Browse timeline events (timeline_events) separating official science milestones, community waves, and symbolic anchors.
Compare framings (timeline_compare_sources) across belief, neutral, and skeptical perspectives, highlighting shared officially-sourced facts and disputed points.
Deepen research (timeline_deepen_story) with source-search queries, related motifs, story prompts, and verification checklists without inventing sources.
Get corpus statistics (timeline_stats) broken down by phenomenon, motif, source type, evidence grade, stance, and flagged items needing sources.
Load agent manifest (timeline_agent_manifest) for usage rules, safe language, citation policy, and recommended workflows.
Access is available via MCP server CLI or stateless HTTP API, with raw JSON data for reports, Mandela items, motifs, events, story threads, and sources.
The machine went quiet. The stories didn't.
Timeline Pulse is an open-source MCP server and interactive atlas of timeline-shift folklore, Mandela Effect reports, collider-era myths, and symbolic reality stories — every claim labeled, every source graded.
On 2026-06-29 the LHC was switched off for Long Shutdown 3, and won't collide again until ~2030 (CERN). Communities tell stories around machines like this. This project files those stories properly: official facts on one shelf (always cited), beliefs and symbols on another (always labeled), and tools so humans and AI agents can explore both without confusing them.
Timeline Pulse treats its material as cultural, symbolic, experiential, and speculative storytelling. It does not claim that CERN, the LHC, particle physics, timelines, or Mandela Effects prove supernatural or physical timeline manipulation.
Package: timeline-pulse on npm — no keys, no backend, read-only
Built end-to-end with Claude (Claude Code + Claude in the browser designed, documented, and implemented this repo), reviewed by a human
{
"mcpServers": {
"timeline-pulse": {
"command": "npx",
"args": ["-y", "timeline-pulse"]
}
}
}The seed corpus ships inside the package: 20 reports, 17 motifs (24 co-occurrence edges), 6 Mandela catalog items, 8 story threads, 9 timeline events with 5 officially-sourced CERN anchors.
Related MCP server: lithtrix-mcp
Default is stdio. Optional Streamable HTTP — no session id, JSON responses, loopback only:
npx -y timeline-pulse --http
# GET http://127.0.0.1:3000/health
# POST http://127.0.0.1:3000/mcp (sessionless)Env: TIMELINE_PULSE_HOST, TIMELINE_PULSE_PORT, TIMELINE_PULSE_TRANSPORT=http.
Tool | Purpose |
| The rules of the corpus: safe language, citation policy, first calls. Call this first. |
| Search reports by text, motif, phenomenon, source type, date, stance, or evidence grade. Paginated. |
| One full report with labeled claims, anchors, related reports, safety flags, and recommended phrasing. |
| Mandela Effect items: remembered vs on-record variants, community and mainstream notes side by side. |
| Recurring symbols and their co-occurrence graph — the constellation, as JSON. |
| Curated arcs written three ways: belief, neutral archive, skeptical. |
| Official science milestones and community waves on one axis, never blended. |
| Belief / neutral / skeptical framings for one topic, plus officially-sourced shared facts. |
| Research prompts and follow-up angles — never fabricated sources. |
| Corpus totals by phenomenon, motif, source type, year, grade — and what still needs sources. |
Every tool is read-only (readOnlyHint: true), local-first, and returns
structured JSON with uncertainty made visible.
https://timeline-pulse.vercel.app is the same corpus as a public instrument:
Archive — searchable reports with evidence-grade filters and a full-record drawer.
Timeline — official CERN anchors above the line, community waves and symbolic anchors below. One axis, never one claim.
Motifs — an interactive constellation of 17 recurring symbols (machine silence, rainbow bridge, serpent time, heart collider…).
Mandela Catalog — classic memory variants with the mainstream explanation always attached.
Story Threads — eight arcs, each readable through a belief / neutral / skeptic lens switch.
For agents — MCP install, raw JSON endpoints, llms.txt, and the language rules.
Plus one honest easter egg: press M and the site quietly Mandela-affects
itself. See if you notice everything that changed.
/reports.json · /mandela-items.json · /motifs.json · /events.json ·
/story-threads.json · /sources.json · /llms.txt · /openapi.json
The site serves the exact JSON files the npm package ships — one corpus, three doors (site, MCP, raw JSON).
Grade | Meaning |
| Published by the institution itself — always linked |
| A person reporting their own experience |
| Shared accounts: forums, polls, threads |
| Community meaning-making on top of events |
| Allegory and teaching language, filed as such |
| Unverified conjecture, clearly flagged |
npm install
npm test # policy guard + build + corpus validation + site-sync check + MCP smoke test
npm run build # compile the server to dist/
npm run sync-site # copy data/ JSON into site/ after editing the corpus
npx serve site # run the site locallyThe repo enforces its own content policy in CI: official claims must carry
official URLs, speculative claims must carry safety flags, and one symbolic
source family is never named — checked by hash, so the name appears nowhere,
including in the check itself (scripts/check-policy.mjs).
Reports, corrections, and motifs are welcome — see
CONTRIBUTING.md and the issue templates. The fastest way to
help: find official sources for anything flagged ⚑ needs source.
Source and content policy ← the contract
Code is MIT. Data: original summaries and metadata authored by the project; official facts link to their institutional sources; excerpts stay short and attributed. Details in docs/SOURCE_POLICY.md.
EST. 2026 · SEED CORPUS v0.1 · NO PHYSICS WERE HARMED ◉
The rules of the corpus: what it is, safe language, citation policy, recommended first calls, install snippet, and raw data endpoints. Call this first.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide safety profile (readOnly, idempotent, not destructive). The description adds that it contains rules and policies, which is consistent. It doesn't detail behavioral nuances like rate limits or auth, but for a read-only manifest, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste. The first sentence lists key contents, the second gives usage instruction. Perfectly front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple manifest tool with no parameters and safe annotations, the description covers the main aspects. It doesn't specify output format (e.g., text or JSON), but the contents are listed sufficiently for an agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description need not provide parameter semantics. Baseline for 0 parameters is 4. The description adds value by explaining what the tool returns, which compensates for lack of output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'rules of the corpus' including specific components like safe language, citation policy, and raw data endpoints. It distinguishes itself from siblings by being the first call to get an overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this first,' giving clear when-to-use guidance. It does not explicitly state when not to use, but the context of sibling tools makes it obvious this is introductory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare belief-framed, neutral-archive, and skeptical framings for one topic, with the shared facts (officially sourced) and disputed points separated out.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | e.g. 'CERN shutdown and timeline shifts', 'mandela waves', 'apophis window' | |
| frames | No | subset of frames; default all three |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is clear. The description adds value by disclosing that the tool separates shared facts and disputed points, which is behavioral information not captured by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys purpose and output structure. It is front-loaded and free of fluff, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (comparing framings, multiple parameters) and lack of output schema, the description adequately explains the output (shared facts and disputed points). It is mostly complete for an agent to understand what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with topic and frames parameters well-described (topic has examples, frames has enum). The description does not add parameter-specific semantics beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares different framings (belief, neutral, skeptical) for a topic, separating shared facts and disputed points. It includes specific verb 'Compare' and resource 'framings', distinguishing it from sibling tools like timeline_events or timeline_mandela_catalog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when comparing framings but does not explicitly state when to use or when not to use, nor does it mention alternatives like timeline_deepen_story or timeline_search_reports. It provides minimal guidance on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate research directions for a report, motif, or thread: source-search queries, related motifs, comparison questions, story-expansion prompts, and a verification checklist. Never invents sources.
| Name | Required | Description | Default |
|---|---|---|---|
| motif | No | ||
| report_id | No | ||
| thread_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds a critical behavioral constraint ('Never invents sources'), which is valuable for agent safety. Does not describe output format or side effects beyond generation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key outputs, followed by a critical constraint. Every word adds value. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite clear purpose, the description lacks details on output format, which is important since there is no output schema. No examples or guidance on how the information is structured. All parameters are optional, but the description does not clarify the default behavior when none are provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for 3 optional parameters. Description maps parameters to concepts (motif, report_id, thread_id) but provides no usage guidance, format constraints, or how to choose which parameter to use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool generates research directions for a report, motif, or thread, listing specific output types. However, it does not differentiate itself from sibling tools like timeline_events or timeline_compare_sources, which handle related concepts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, when not to use, or context where other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Timeline events on one axis, three labeled layers: official-science (always cited), community-wave (interpretation), symbolic-anchor (reading). Layers never blend.
| Name | Required | Description | Default |
|---|---|---|---|
| layer | No | ||
| date_end | No | ||
| date_start | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds that layers never blend and describes each layer (official-science always cited, community-wave interpretation, symbolic-anchor reading), providing structural context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two short sentences) with no wasted words. It front-loads the purpose and key structural rule immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and zero parameter documentation, the description should provide more detail about what constitutes an event, the structure of results, and how filtering works. It only covers the layering concept but omits essential usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters (layer, date_start, date_end) at all. It fails to add meaning or usage hints for these filtering options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns timeline events on one axis with three labeled layers. It distinguishes the tool by the unique layering concept, but does not explicitly differentiate from siblings like timeline_search_reports or timeline_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus its siblings. The description does not specify any prerequisites, limitations, or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one full report: long summary, labeled claims, source metadata, anchors, motifs, related reports, safety flags, and recommended phrasing for agents.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | report id, e.g. 'tp-001' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it's a safe, idempotent read. The description adds details about the returned data but does not mention error handling, authentication, or other behavioral traits beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently lists the report components without redundancy. However, it is dense and could benefit from slight structural separation for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides a solid inventory of return fields (long summary, claims, metadata, etc.), which is adequate for an agent to understand what the tool fetches. It lacks details on data relationships or format but is sufficient for a read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the single parameter 'id' already described in the schema as 'report id, e.g. 'tp-001''. The tool description does not add any additional meaning or usage context for the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns a single full report and enumerates all contained components (long summary, labeled claims, etc.), distinguishing it from sibling tools like timeline_search_reports (search) or timeline_events (list events).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus siblings, such as timeline_deepen_story or timeline_search_reports. The required 'id' parameter implies a specific report fetch, but no exclusionary or preferential context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse Mandela Effect catalog items: remembered vs on-record variants, why communities link them to timeline lore, and the mainstream memory-science explanation for each.
| Name | Required | Description | Default |
|---|---|---|---|
| motif | No | motif id filter | |
| query | No | free text over titles and variants | |
| status | No | ||
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds context about the nature of the content (variants, explanations) but doesn't disclose pagination, rate limits, or other behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, moderately long sentence that fronts the key action 'Browse Mandela Effect catalog items'. It includes relevant specifics without wasted words, though it could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the catalog items are about but does not mention return format, pagination, or how to use the filters. Without an output schema, more detail on the response structure would improve completeness for a tool with 4 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only motif and query have descriptions). The tool description does not clarify the purpose or effect of the parameters, leaving agents to rely solely on the schema for understanding filtering options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool browses Mandela Effect catalog items, specifies what content it provides (remembered vs on-record variants, timeline lore explanations, mainstream science explanations), and distinguishes it from sibling tools like timeline_events or timeline_motif_map.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The verb 'browse' hints at exploratory usage, but there is no mention of when to use it instead of timeline_search_reports or timeline_deepen_story.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The motif constellation: recurring symbols with definitions, families, frequencies, and weighted co-occurrence edges — ready for graph rendering or motif-based filtering.
| Name | Required | Description | Default |
|---|---|---|---|
| motif | No | focus on one motif: returns it plus its direct neighbors | |
| family | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by detailing the output components (definitions, families, frequencies, edges) and use case (graph rendering, filtering). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, dense sentence that front-loads the core purpose and key outputs. Every phrase earns its place, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two optional parameters and no output schema, the description covers the output structure and use case. However, it omits behavior when no parameters are provided (returns all?) and does not explain the `family` parameter values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%. The description mentions 'families' but does not explain the `motif` or `family` parameters beyond the schema. With only two optional params, the description adds minimal semantic value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a 'motif constellation' with definitions, families, frequencies, and co-occurrence edges. It specifies it is for graph rendering or motif-based filtering, effectively distinguishing it from sibling tools like timeline_events or timeline_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for motif analysis but lacks explicit guidance on when to use this tool versus alternatives like timeline_events or timeline_story_threads. No when-not-to-use or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the report archive by free text, motifs, phenomenon type, source type, stance, evidence grade, or date range. Returns brief records with grades and safety flags; use timeline_get_report for the full record.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | free text matched against title, summary, motifs, phenomenon | |
| cursor | No | opaque cursor from a previous call | |
| motifs | No | motif ids — a report must carry ALL listed motifs; call timeline_motif_map for valid ids | |
| stance | No | ||
| date_end | No | ISO date — reports observed on/before | |
| date_start | No | ISO date — reports observed on/after | |
| source_types | No | e.g. 'firsthand-report', 'forum-thread', 'social-post', 'symbolic-teaching-summary', 'project-note', 'article' | |
| evidence_grade | No | ||
| phenomenon_types | No | e.g. 'mandela-effect', 'cern-lore', 'timeline-shift', 'synchronicity', 'simulation-glitch', 'symbolic-alchemy', 'dream-vision' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds that it returns brief records with grades and safety flags, complementing annotations that indicate read-only and idempotent behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no unnecessary words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes return value as 'brief records with grades and safety flags' and links to get_report. Lacks exact structure of records but is adequate for a search tool without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 70% schema coverage, the description does not add significant meaning beyond the schema. It groups search dimensions but does not elaborate on parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the report archive by multiple criteria and distinguishes it from the sibling timeline_get_report for full records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says returns brief records and directs to timeline_get_report for full details, but does not provide when-not-to-use or alternatives for other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Corpus statistics: totals by phenomenon, motif, source type, evidence grade, stance, year, and language, plus catalog/thread/event counts and flagged items.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint (true), destructiveHint (false), and idempotentHint (true). The description adds the specific dimensions counted, which is useful behavioral context beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose and lists the breakdown dimensions efficiently. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no parameters, the description is reasonably complete in explaining what statistics are returned. However, it could mention output format or data scope (e.g., time range) for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the baseline is 4. The description does not need to provide parameter details, and it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns corpus statistics, breaking down counts by multiple dimensions (phenomenon, motif, source type, etc.). It distinguishes from sibling tools like timeline_events (which returns events) and timeline_story_threads (which returns threads).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for aggregate statistics but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Curated narrative arcs, each written three ways (belief / neutral / skeptical) with motif chips, timeline anchors, member reports, and research prompts.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | one thread id, e.g. 'machine-silence-calibration' | |
| lens | No | optionally mark one frame as active |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows it's a safe read operation. The description adds valuable context about the structure of the output (three lenses, motif chips, etc.), which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, well-crafted sentence with no filler. Front-loaded key concept (curated narrative arcs). Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists the components (motifs, anchors, reports, prompts) but does not explain the output format (e.g., returns a list or single object). No mention of pagination or result size. Adequate but not comprehensive for a retrieval tool with multiple optional filters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema (100% coverage). The description explains the 'three ways' which directly informs the lens parameter's purpose. The id parameter example ('machine-silence-calibration') provides concrete guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides curated narrative arcs with three lenses and multiple components. It distinguishes from sibling tools like timeline_events (events) and timeline_motif_map (motifs) by combining these aspects, but could be more explicit when to use this vs. timeline_agent_manifest.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives (e.g., timeline_compare_sources, timeline_deepen_story). No when-not-to-use or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct aspect of the timeline corpus (manifest, comparison, deepening, events, reports, catalog, motifs, search, stats, story threads) with no overlap in functionality, ensuring clear differentiation.
All tools follow the 'timeline_<descriptive_name>' pattern using snake_case, creating a predictable and uniform naming scheme with no mixing of conventions.
With 10 tools, the server provides a comprehensive yet focused set of functions for exploring a timeline/Mandela effect corpus, avoiding both excessive and insufficient numbers.
The tool surface covers the full range of exploration needs: introduction, comparison, deep dives, event timelines, report retrieval, catalog browsing, motif mapping, search, statistics, and story arcs – no obvious gaps for the intended use.
Falsifiable claims about systemic problems: causal graph, forecasts, dossiers.
Search, read & publish paid essays. Pay-per-read in USDC on Base (x402); wallet-only, no account.
Evidence-first news archive: briefs, breaking news, search, Palestine claims, conflict monitor.
A memory your AI can prove and the market of the present tense. SHA-256, verifiable offline.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/davidmosiah/timeline-pulse'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
