Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Toki Toki no Mi Record: rejected Redis due to lack of persistence."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that remembers why each decision was made — a local, searchable decision log.
A Model Context Protocol (MCP) server — one focused tool you plug into an MCP-compatible client (Claude Desktop, Claude Code, Cursor, and others).
A conversation's context window forgets. A few sessions later, the reasoning behind an architectural choice is gone, and you re-litigate decisions you already settled — or quietly reverse them without noticing.
Toki Toki no Mi is a causality ledger. It records each decision, the alternatives you rejected, and why you chose as you did, then lets your assistant retrieve that history later — and flag a new proposal that contradicts a past decision.
Related MCP server: Decision State MCP
Two tools:
log_causality_point — record a decision, the rejected alternatives, and the justification
time_leap_retrieval — recall past decisions (all of them, or filtered by keyword)
Decisions are stored locally in SQLite under ~/.grandline/ and also mirrored to
a Markdown file, so any external search tool can be pointed at the folder to read
them.
Tool reference: log_causality_point(decision_made, alternatives_rejected, justification) · time_leap_retrieval(query: str = "")
Self-contained, no API key, fully local. The ledger is a single SQLite file on your machine with no external dependencies. Nothing is sent anywhere.
Requires Python 3.10 or newer.
pip install toki-toki-mcpThis installs the toki-toki command.
Then register it with your MCP client — either run claude mcp add toki-toki -- toki-toki,
or add this to the client's config (e.g. claude_desktop_config.json):
{
"mcpServers": {
"toki-toki": { "command": "toki-toki" }
}
}Restart the client and the tool is available.
Toki Toki no Mi is part of a four-tool set. Each tool stands alone, but installing all of them unlocks a final surprise via Laugh Tale.
Package | ||
🗿 | Road Poneglyph | |
⚔️ | Conqueror's Haki | |
⏳ | Toki Toki no Mi · ← this repo | |
🏴☠️ | Laugh Tale |
git clone https://github.com/xfloukiex-lab/toki-toki
cd toki-toki
python -m venv .venv && . .venv/Scripts/activate # macOS/Linux: source .venv/bin/activate
pip install -e ".[dev]"
python tests/test_toki_toki.pyReleased under the Apache-2.0 license. The icon is original artwork
(see icon.svg), generated locally; the repository ships no third-party assets.
This is a fan-inspired project. It is not affiliated with, sponsored by, or endorsed by the creators or rights holders of One Piece (Eiichiro Oda / Shueisha / Toei Animation). "One Piece" and related names are used only as thematic flavour and remain the property of their respective owners.
Anchor a moment in time. Record a project decision, the alternatives rejected, and why it was chosen — for future historical reference.
Args: decision_made: The final path / feature / architecture settled on. alternatives_rejected: What other options were considered and discarded. justification: Why this decision was made over the alternatives.
| Name | Required | Description | Default |
|---|---|---|---|
| decision_made | Yes | ||
| alternatives_rejected | Yes | ||
| justification | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly discloses that the tool records a decision, alternatives, and justification for future reference. It does not mention any side effects or requirements, but for a logging tool, the behavior is adequately transparent.
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 concise with a one-sentence purpose followed by a structured Args section. It front-loads the main action and avoids redundant or unnecessary words.
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 covers the purpose and parameters completely. An output schema exists to document return values, so the description need not explain them. However, it does not address any prerequisites or common usage patterns, leaving minor gaps.
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?
Despite the input schema having 0% description coverage, the description provides a detailed docstring explaining each parameter (decision_made, alternatives_rejected, justification) with clear semantics beyond the schema's type information.
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 uses specific verbs ('anchor', 'record') and a clear resource ('project decision, alternatives, justification'). It distinguishes from the sibling tool 'time_leap_retrieval' which is about retrieval, while this tool is about logging.
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 recording decisions with reasoning, but does not explicitly state when to use this tool versus alternatives, nor does it provide any 'when not to use' guidance. The sibling tool name suggests retrieval, but no direct comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Leap backward into the timeline. Retrieve past decisions and the reasons behind them to understand how the current state came to be.
Args: query: Optional keyword to find a specific past decision. Empty returns the 10 most recent anchors.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adequately discloses behavior: it retrieves past decisions, uses query parameter, and returns anchors. No mention of side effects or permissions, but appropriate for a read operation.
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 plus a concise Args explanation. No redundancy, front-loaded with purpose. Every sentence 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?
With an output schema present, description suffices by explaining return (anchors). Single parameter fully described. Complete for its complexity.
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 0%, so description compensates fully: explains 'query' is optional, default empty, returns 10 recent anchors. Adds meaning beyond schema type/title.
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 'retrieve past decisions and the reasons behind them', specifying the verb and resource. It distinguishes from sibling 'log_causality_point' by focusing on retrieval rather than logging.
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 explains when to use the 'query' parameter (optional, empty returns 10 most recent). No explicit contrast with sibling, but usage is clearly for introspection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0log_causality_pointtime_leap_retrievalScored across 2 tools
The two tools have clearly distinct purposes: one records decisions, the other retrieves them. No overlap or ambiguity.
Both tools use a consistent verb_noun pattern with snake_case (log_causality_point, time_leap_retrieval), following a predictable convention.
With only 2 tools, the server is minimal but focused. While it covers the core operations of logging and retrieving decisions, more tools could be expected for a broader time-travel theme.
The set covers create (log) and read (retrieval) but lacks update and delete operations for decisions. This is a notable gap for full lifecycle management.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Markdown-based note-taking with a hosted MCP server. Your notes serve you and your AI.
MCP server for generating rough-draft project plans from natural-language prompts.
Hosted MCP memory: save sessions/decisions once, search from Claude, Cursor, ChatGPT. EU-hosted FTS.
Append-only decisions with provenance, supersession, retrieval, and audited MCP actions.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/xfloukiex-lab/toki-toki'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
