What it does: gives Claude a memory of your work, a sense of time, a refuse-rumination guardrail, and a translator for corporate ambiguity.
Who it's for: neurodivergent people — self-ID only, no diagnosis required, no gatekeeping.
How to install: one command, below.
NeuroDock plugs into Claude Desktop / Claude Code / Cursor (any MCP-aware client). Local-first by default. No telemetry. AGPL-3.0-or-later.
Related MCP server: Coach AI
You chat with Claude exactly like normal. Under the hood, Claude calls NeuroDock's local MCP servers; they read and write your local store; the result flows back into Claude's reply.
Everything runs on your laptop. Nothing leaves your machine unless you explicitly turn on a cloud option.
npx --yes @neurodock/cli@latest install-allOne command. It pip-installs the five MCP servers (plus the neurodock-evals
harness), wires Claude Desktop / Claude Code / Cursor, and drops a starter
profile at ~/.neurodock/profile.yaml.
Then, in any conversation, try one of:
What was I working on yesterday?
Plan my morning.
Decompose this goal into atomic tasks.Claude calls the MCP tools under the hood; you just talk.
🛑 First-time gotcha: full-quit Claude before testing
Claude only reads its MCP config at startup. Closing the window is not enough. This is the #1 silent failure people hit.
macOS:
Cmd + Q(or Claude menu → Quit Claude).Windows: right-click the Claude icon in the system tray → Quit.
Linux: kill the process (
pkill -f Claudeor quit from the tray).Then reopen Claude and try one of the prompts above.
Requires Python 3.11+ and Node 22+. Works on macOS, Linux, Windows.
Why
@latest? If you previously rannpm install -g @neurodock/cli, npx will silently reuse that older global install instead of fetching the current version — and old versions don't haveinstall-all. The@latesttag forces npx to resolve against the npm registry every time. Same reason we use it onupdate.
NeuroDock ships across two registries: the Python MCP servers (MCP = Model Context Protocol — the standard that lets Claude call local tools) on PyPI, and the user-facing CLI on npm. The CLI wraps everything else.
1. Install the six MCP servers
pip install neurodock-mcp-chronometric neurodock-mcp-cognitive-graph neurodock-mcp-task-fractionator neurodock-mcp-translation neurodock-mcp-guardrail neurodock-evals2. Wire them into your MCP-aware client
npx --yes @neurodock/cli@latest initDetects Claude Desktop, Claude Code, or Cursor and writes the server entries automatically.
3. Restart Claude (full quit, not close-window — see the callout above).
About the neurodock command — it lives on npm as @neurodock/cli,
not on PyPI. The pip install step gives you the MCP server binaries
that Claude calls over stdio; the CLI is separate. Two ways to run it:
# Option A — run via npx, no install
npx --yes @neurodock/cli@latest doctor
# Option B — install once, call 'neurodock' from anywhere
npm install -g @neurodock/cli
neurodock doctor@neurodock/cli exposes: init, doctor, validate, update, sync,
uninstall, host install, host uninstall, profile show,
profile validate, install-all, install-hooks, examples,
plugin add/remove/list/enable/disable/validate.
By default NeuroDock waits for you to ask. That's the wrong shape — an ND user in hyperfocus is the one least likely to remember to run a break tool. One command flips it:
neurodock install-hooks --self-testThis wires a small Python script (bundled, stdlib-only — no extra install needed) into Claude Code's hook system. It then runs silently on every tool call and auto-fires the chronometric / rumination / sycophancy heuristics when patterns trip. You get a one-line stderr banner on the next prompt — never blocked, always dismissible.
For host-agnostic coverage (catches you working in the terminal at 02:00 too), add the standalone daemon:
neurodock install-hooks --install-daemon --self-testThat registers a per-user autostart entry (HKCU Run on Windows,
LaunchAgent on macOS, systemd --user on Linux). The daemon polls
every 5 min and surfaces OS-native notifications.
Opt out anytime:
neurodock install-hooks --uninstall # removes both
export NEURODOCK_GUARDRAILS=off # disables without removingThe browser extension carries its own equivalent (Phase 2 watchdog) —
it's enabled by default and toggleable from chrome.storage.local via
the popup Settings tab.
See docs/.../proactive-guardrails for the design behind this and the
opt-out matrix.
Want to see it work without installing from PyPI/npm at all?
TESTING_LOCAL.md walks through the from-clone path.
The install-all command above is the recommended path. The same servers are
also distributed through three standard channels — all install the identical
local stdio servers, so you can pick whichever fits your client:
Claude Code plugin — bundles the five MCP servers and a set of ND-aware
skills in one step. Requires uv (the servers
run via uvx).
/plugin marketplace add tlennon-ie/neurodock
/plugin install neurodock@neurodockClaude Desktop extension (.mcpb) — one-click install, no config editing.
One bundle per server under mcpb/; build with
npx @anthropic-ai/mcpb pack mcpb/neurodock-mcp-translation and drag the
.mcpb onto Claude Desktop → Settings → Extensions. Requires uv.
Official MCP Registry — each server ships a
server.json and is published to
registry.modelcontextprotocol.io
under the io.github.tlennon-ie/* namespace, so MCP-aware clients can discover
them directly.
Hosted remote server (no install) — the stateless tools (translation,
guardrail, and decompose) are also served over OAuth at a hosted HTTPS
endpoint, so you can use them with no local install and no uv:
https://mcp.neurodock.org/mcpIn Claude (claude.ai or Desktop) → Settings → Connectors → Add custom
connector → paste that URL → complete the sign-in prompt. The eight stateless
tools appear immediately. An opt-in memory surface (enable_hosted_storage,
connect_byos_storage, record_fact, recall_entity, …) is also exposed but
does nothing until you explicitly enable storage for your signed-in account. The
personal cognitive graph and neurotype profile are never hosted — they stay
on the local install. Full walkthrough: Hosted server.
The hosted remote server is live at mcp.neurodock.org.
npx --yes @neurodock/cli@latest updateOne command. Upgrades all six MCP servers (pip install --upgrade /
uv tool install), refreshes your wired client configs, and
re-registers the optional native-messaging host. Same flags as
install-all (--client, --profile, --installer, --dry-run,
--no-native-host, --yes).
The browser extension auto-updates through the Chrome / Firefox / Edge
store; sideloaded users git pull and rebuild.
Full-quit Claude after updating so it re-reads its MCP config — same as first install.
Just want to re-shape client configs without touching package versions?
Use neurodock sync.
The cognitive substrate in a real session — you talk to Claude normally; under the hood it calls NeuroDock's MCP tools to remember, pace, and decompose.
https://github.com/user-attachments/assets/bcbf65ce-88dd-4f83-8dc1-d56bdde01bed
The browser extension — translating corporate-speak inline on Gmail, Slack, and the rest, right where you read it, without context-switching back to Claude.
https://github.com/user-attachments/assets/5fa25044-923e-4c25-95bd-f1bd63fb3d6e
Prefer a written walkthrough? Try the Claude Desktop walkthrough.
There's also a browser extension that translates corporate-speak inline on Gmail, Slack, Linear, Notion, GitHub, Google Docs, and Outlook. It calls the same translation tools the MCP server exposes, but surfaces them where you'd actually use them — a floating Translate button plus a right-click menu — so you don't have to context-switch back to Claude just to decode "let's circle back on this."
You pick the LLM provider. Five options: Ollama (local, default), LM
Studio (local), OpenRouter (including its auto-router), Anthropic, OpenAI.
The API key, if you need one, stays in chrome.storage.local and never
leaves the device.
Store submission is still pending (the listing prep is done; the developer accounts and screenshots aren't). Until then, load it manually:
Build it: pnpm --filter @neurodock/extension-browser run build
Chrome / Edge: go to chrome://extensions, turn Developer mode on,
click Load unpacked, and pick packages/extension-browser/.output/chrome-mv3/.
Firefox: go to about:debugging, click This Firefox → Load
Temporary Add-on, and pick manifest.json inside
packages/extension-browser/.output/firefox-mv3/.
Full per-provider setup walkthrough lives in
packages/extension-browser/README.md.
NeuroDock is built around three pillars. Each pillar is made of small, independent packages that you can use one at a time or all together.
flowchart TB
subgraph cognitive[Cognitive substrate]
chrono[mcp-chronometric<br/>time + sessions]
cgraph[mcp-cognitive-graph<br/>memory]
frac[mcp-task-fractionator<br/>decomposition]
end
subgraph comms[Communication layer]
trans[mcp-translation<br/>tone + meetings]
ext[extension-browser<br/>Gmail, Slack, ...]
end
subgraph safety[Clinical guardrails]
guard[mcp-guardrail<br/>rumination / hyperfocus / sycophancy]
clin[clinical<br/>heuristic library]
end
skills[skills/<br/>six markdown bundles] --> cognitive
skills --> comms
skills --> safety
cli[cli/<br/>install + manage] --> cognitive
cli --> comms
cli --> safetyneurodock/
├── packages/
│ ├── mcp-chronometric/ Time + session + break management
│ ├── mcp-cognitive-graph/ Persistent memory + entity recall (SQLite)
│ ├── mcp-task-fractionator/ Decompose vague goals into atomic tasks
│ ├── mcp-translation/ Corporate-speak translator (MCP + browser ext)
│ ├── mcp-guardrail/ Rumination / hyperfocus / sycophancy detectors
│ ├── skills/ Six SKILL.md bundles activating on phrases
│ ├── extension-browser/ WXT-built Chrome / Firefox / Edge extension
│ ├── native-host/ Optional native messaging host (extension <-> profile.yaml)
│ ├── cli/ `npx neurodock init` and friends
│ ├── core/ Shared types, profile schema, plugin spec
│ ├── clinical/ Heuristic library for the guardrail server
│ └── evals/ Eval harness + corpus contribution pipeline
├── docs/ Astro Starlight site (deploys to docs.neurodock.org)
├── plugins/ Drop your own plugins here; auto-discovered
└── profiles/ Curated profile presetsPublic preview shipped. All three substrate pillars (cognitive,
communication, guardrails) are built, on main, and installable from
npm + PyPI. Latest substrate tag: v0.7.3.
neurodock-mcp-chronometric — 5 tools, 22 tests, mypy --strict.
neurodock-mcp-cognitive-graph — 4 tools, SQLite + sqlite-vec
fastembed; 4-rung resolution cascade (exact → alias → fuzzy → embedding).
Latest patch ships friendlier record_fact errors so wrong-shape input
no longer leaks raw Pydantic traces.
neurodock-mcp-task-fractionator — 2 tools, 32 tests; ISO 8601
duration spec.
neurodock-mcp-translation — 4 tools, 29 tests; deterministic
baseline plus LLM refinement envelope.
neurodock-mcp-guardrail — all three detectors live: rumination,
hyperfocus, sycophancy (48 tests, public heuristics).
neurodock-evals — air-gapped harness, 10 seed corpus examples,
contribution pipeline.
neurodock-clinical — reserved name; importable detector library
(currently a stub).
@neurodock/cli — 19 verbs across 7 groups: init, install-all,
examples, doctor, validate, update, sync, uninstall,
host install/uninstall, profile show/validate, install-hooks,
plugin add/remove/list/enable/disable/validate. install-hooks
wires the proactive-guardrail hook into Claude Code and optionally
registers the standalone daemon.
@neurodock/core — profile schema and plugin protocol manifests
(JSON Schema 2020-12).
@neurodock/native-host — optional Chrome Native Messaging host
for the extension ↔ profile sync.
@neurodock/extension-browser — WXT MV3 build for Chrome / Firefox
/ Edge. Seven sites wired. Five real LLM providers: Ollama, LM Studio,
Anthropic, OpenAI, OpenRouter. Includes the Phase 2 proactive watchdog
for hyperfocus / late-night / single-host rumination signals.
Not yet store-published.
Six launch skills — adhd-daily-planner, audhd-context-recovery,
ocd-decision-finalizer (beta), hyperfocus-formatter, visual-organizer,
asd-meeting-translator.
Docs site — builds clean (Astro Starlight), deploys to
docs.neurodock.org.
Browser-store submissions — Chrome Web Store, Firefox Add-ons, Edge Add-ons developer accounts + screenshots; manual step.
TESTING_LOCAL.md — step-by-step guide to running this against your
Claude Desktop, today, from a clone. Takes about 5 minutes.
The docs site lives at docs.neurodock.org.
Source is at docs/src/content/docs/. To preview locally:
pnpm --filter @neurodock/docs run dev
# opens http://localhost:4321The substrate splits into three pillars:
Cognitive substrate — externalises executive function (time, memory, decomposition). MCP servers: chronometric, cognitive-graph, task-fractionator.
Communication layer — translates corporate ambiguity; rewrites outgoing messages for register-appropriate tone; structures meeting transcripts. MCP server: translation. Browser extension surfaces the same prompts in Gmail / Slack / Linear / Notion / GitHub / Docs / Outlook.
Clinical guardrails — detects and intervenes on rumination
(repeat-validation loops), hyperfocus (escalating session-length
nudges), and sycophancy (unconditional agreement). MCP server: guardrail.
Heuristics are public and auditable per ETHICS.md.
All three layers compose via the same MCP protocol the LLM client already speaks. There's no "NeuroDock app" — the surface is your Claude client.
Design rationale lives in docs/decisions/:
ADR 0001 — chronometric tool design
ADR 0002 — cognitive-graph tool design
ADR 0003 — task-fractionator tool design
ADR 0004 — profile schema
ADR 0005 — translation tool design
ADR 0006 — guardrail tool design
ADR 0007 — plugin protocol
ADR 0008 — distribution & remote strategy
CONTRIBUTING.md has the welcome + on-ramp. Pick whichever lane matches
what you want to do:
Smallest first PR (~15 min):
Add a test to an existing skill (packages/skills/<name>/tests/)
Add a seed eval example (packages/evals/corpora/translation/)
Improve a tool's parameter description (the LLM uses these — clearer descriptions = better tool use)
One-afternoon PR:
Write a new skill — markdown bundle activating on specific phrases.
Copy any packages/skills/<name>/ as a template; see
docs/src/content/docs/contribute/write-a-skill.mdx.
Sharpen the task-fractionator heuristics (regex / domain keyword maps).
Add a new entity-resolution heuristic (e.g., phonetic) to
mcp-cognitive-graph.
Multi-day PR:
Build an out-of-tree plugin (skill / mcp-server / profile / translation
pack / language pack / theme) per the ADR 0007 plugin protocol. See
docs/src/content/docs/contribute/write-a-plugin.mdx.
Translation language pack (e.g., Hiberno-English, German directness norms, Japanese keigo).
No code:
Add an anonymised eval example from your own corporate inbox. The
contribution pipeline lives in packages/evals/ and is the highest-
leverage non-code contribution.
All PRs run CI: pnpm turbo run lint typecheck test build + uv run pytest
uv run mypy --strict packages/.... Every published package has its
own CHANGELOG. Use Conventional Commits in PR titles (feat:, fix:,
docs:, test:, chore:, ci:).
Lower friction for users, and for contributors.
Local-first by default; cloud is opt-in.
The user is the authority. Self-ID sufficient.
Composable over monolithic. No god-modules.
Refuse where appropriate. AI that fuels rumination, hyperfocus, or anxiety is a regression, not a feature.
Full text in MANIFESTO.md. Ethics framework in ETHICS.md. Governance
in GOVERNANCE.md.
AGPL-3.0-or-later. Plugins must declare an AGPL-compatible license to load — the SPDX whitelist is in ADR 0007.
Convert a meeting transcript into a four-section structured brief: my_asks, others_asks, decisions, ambiguous_items. Every ambiguous_item is anchored to a verbatim transcript span; the server rejects responses where the anchor cannot be located.
| Name | Required | Description | Default |
|---|---|---|---|
| transcript | Yes | ||
| me | Yes | ||
| project | No | ||
| speakers | No | ||
| reader_context | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. The description adds behavioral context: the anchoring constraint and server rejection for missing anchors. This 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?
The description is two sentences, front-loads the main purpose, and includes a critical constraint. Every sentence adds value with no waste.
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 output schema exists, the description covers the output structure but leaves several parameters unexplained. For a tool with 5 parameters and optional fields, more context would be beneficial.
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%, so the description must compensate but does not explain any parameter meanings. It mentions 'transcript' vaguely but does not define 'me', 'project', 'speakers', or 'reader_context'.
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 converts a meeting transcript into a four-section structured brief, listing the sections explicitly. No sibling tool performs this specific function, so it distinguishes well.
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 tool's purpose implies when to use it (having a meeting transcript to summarize), but it lacks explicit guidance on when not to use it or alternatives. Siblings like recall_decisions exist but are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Classify hyperfocus escalation from a caller-supplied chronometric snapshot into one of (none, gentle, nudge, hard). Stateless; quotes prior_intent verbatim.
| Name | Required | Description | Default |
|---|---|---|---|
| chronometric_snapshot | Yes | Current timing snapshot. Required: 'now' (ISO-8601 timestamp). Optional: 'open_session' as {'session_id', 'started_at' (ISO-8601), 'intent', 'elapsed_seconds'} or null when no session is open, and 'idle_signal' in {active, switched_away, unknown}. | |
| session_id | No | ||
| hyperfocus_break_minutes | No | ||
| end_of_day_local | No | Local end-of-day time as HH:MM, 24-hour, e.g. '18:00'. | |
| escalation_thresholds | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds that the tool is stateless and quotes prior_intent verbatim, but provides no additional behavioral traits beyond these.
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, efficient sentence that conveys the core functionality without redundancy or verbosity.
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 output categories and statelessness, but lacks parameter explanations. Given the output schema exists, the omission is partially mitigated, yet for a tool with 5 parameters, more detail would improve 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?
With only 40% schema description coverage, the description should add parameter context, but it does not mention any parameters or their meanings, leaving a significant gap.
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 classifies hyperfocus escalation from a chronometric snapshot into four specific categories (none, gentle, nudge, hard), distinguishing it from siblings like check_rumination which target different cognitive states.
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 through its verb 'Classify' and input specification, but does not explicitly state when to use this tool versus alternatives or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect whether the user's current prompt is a semantic repeat of recent prompts within a rolling window. Stateless; returns a structured advisory signal.
| Name | Required | Description | Default |
|---|---|---|---|
| current_prompt | Yes | ||
| history | Yes | ||
| window_minutes | No | ||
| threshold_count | No | ||
| similarity_threshold | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds 'Stateless' and 'returns a structured advisory signal' beyond annotations (readOnlyHint, idempotentHint). No contradiction with annotations. Could mention return format or side effects but sufficient given 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?
Two sentences, no fluff. Front-loaded with purpose and key traits. Could add parameter detail without excessive length.
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 5 parameters, 0% schema coverage, and an output schema, description omits parameter meanings and output structure. Incomplete for an agent to invoke correctly without further inference.
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%, yet description only hints at current_prompt and history. No details on window_minutes, threshold_count, similarity_threshold, which are critical for usage. Fails to compensate for schema gaps.
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 verb 'Detect' and resource 'semantic repeat of recent prompts'. Distinguishes from sibling tools which target different behavioral checks (hyperfocus, sycophancy, tone).
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?
Implies usage for detecting rumination but provides no explicit guidance on when to use this tool vs alternatives like check_hyperfocus or check_sycophancy. Lacks when-not or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect over-validation in a candidate response or repeated reassurance-seeking in recent user messages. Returns a counter_prompt the caller MAY surface.
| Name | Required | Description | Default |
|---|---|---|---|
| candidate_response | No | ||
| recent_user_messages | No | ||
| decision_context | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating a safe, side-effect-free operation. The description adds that the tool returns a counter_prompt which the caller 'MAY' surface, adding some behavioral context but not deeply enriching beyond the 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 consists of two efficient sentences. The first sentence states the core functionality, and the second describes the return value. No extraneous information or verbose phrasing is present.
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 has an output schema and three optional parameters, the description adequately covers the high-level purpose and output. However, it lacks parameter details and usage guidance, which are important for correct invocation. The description is minimally complete but not fully informative.
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%, so the description carries the full burden. It mentions 'candidate response' and 'recent user messages' but does not explain their types, formats, or how the 'decision_context' parameter affects behavior. The description fails to add meaning beyond the parameter names in the 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 verb 'detect' and the specific resources (over-validation in candidate response, reassurance-seeking in user messages). It also mentions the output (counter_prompt). This distinguishes it from sibling tools like check_hyperfocus or check_rumination, which target different phenomena.
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 provides no guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. It simply states what the tool does, leaving the agent without context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score an outgoing message on directness / warmth / urgency axes (0..100), optionally relative to a baseline of the sender's prior messages, and flag phrases that deviate substantially from baseline or from a target register. Returns deterministic axes plus an LLM-refinement prompt.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| baseline_messages | No | ||
| target_register | No | ||
| channel | No | ||
| reader_context | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint) are consistent. Description adds behavioral context: returns deterministic axes plus LLM-refinement prompt. 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, each meaningful and efficient. No redundant information.
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?
Covers all key aspects: input, optional parameters, output (axes + prompt). With output schema, return values are sufficiently described.
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%, but description fully explains each parameter: text (required), baseline_messages (prior messages), target_register (enum), channel, reader_context. Adds meaning beyond 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?
Description clearly states scoring of outgoing message on directness/warmth/urgency axes with optional baseline and flagging deviations. Differentiates from sibling tools like check_hyperfocus and check_rumination.
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?
Explains what it does and optional parameters (baseline, target, channel). Lacks explicit when-not-to-use or alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect your own libSQL/Turso database so the NeuroDock memory tools store data in YOUR database, not on NeuroDock. Validates the URL and smoke-tests the connection before saving it. Requires a signed-in NeuroDock account.
| Name | Required | Description | Default |
|---|---|---|---|
| libsql_url | Yes | ||
| auth_token | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that it validates the URL, smoke-tests the connection before saving, and requires a signed-in account. This adds good behavioral context beyond mere purpose, though it could mention error handling for failed connections.
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 wasted words. First sentence states the core purpose, second adds key behaviors and a prerequisite. Front-loads the most critical information.
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 connection tool with 2 parameters and output schema present, the description covers the main aspects: what it does, validation behavior, and prerequisite. Minor missing details like what 'smoke-tests' entails or the output schema are acceptable since output schema exists.
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 input schema has 0% description coverage, so the description must compensate. It only implicitly mentions 'libsql_url' and 'auth_token' but does not explain their formats, purposes, or constraints. This is insufficient for an agent to correctly invoke the tool.
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 connects a user's own libSQL/Turso database, replacing NeuroDock's hosted storage. It distinguishes from siblings like 'enable_hosted_storage' and 'disconnect_storage' by specifying the bring-your-own aspect.
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 indicates when to use this tool: when you want your own database. It implies not to use it if you want hosted storage. However, it does not explicitly list alternatives or state when not to use it, but the sibling names provide context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Break a vague goal into a small ordered list of atomic 5-90 minute tasks with explicit acceptance criteria and dependency edges. Stateless: returns tasks but does NOT persist them.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | ||
| time_budget | No | Optional total time budget as an ISO-8601 duration, e.g. 'PT2H' (2 hours) or 'PT90M' (90 minutes) — not prose like 'a couple of hours'. | |
| max_chunk_size | No | Optional neurotype knob (ADR 0011). Caps the NUMBER of tasks returned, below the normal 3-12 target / hard cap of 20. When the goal naturally needs more steps, the server keeps the lowest-sequence prefix (a valid sub-DAG with no dangling dependencies) and notes the truncation in the rationale rather than silently dropping steps. Omit for default behaviour. | |
| time_buffer_multiplier | No | Optional neurotype knob (ADR 0011). When greater than 1.0, the server attaches an additive 'padded_minutes' to each task equal to round(estimated_minutes * multiplier). 'estimated_minutes' stays RAW so the figure is never padded twice. A value of 1.0 (or omitting it) produces no padding. | |
| motor_fatigue_aware | No | Optional neurotype knob (ADR 0011). When true, the server echoes the preference and names it in the rationale so the client can act on it. The server has no view of actual motor activity and does NOT infer fatigue. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and idempotentHint=true. Description adds 'Stateless: returns tasks but does NOT persist them,' which aligns with annotations and adds context. No contradictions; it clearly conveys the tool's non-persistent, read-only nature.
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: first states purpose and output structure; second adds statelessness. Every sentence adds value with no redundancy or fluff. Front-loads key information.
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 existence of output schema and rich parameter descriptions, the description adequately covers the tool's behavior (stateless, ordered list, acceptance criteria, dependencies). It lacks detail on return structure but output schema fills that gap. No missing critical 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 80%, so baseline is 3. Description does not elaborate on parameters beyond the schema, but the schema already has detailed descriptions for time_budget, max_chunk_size, etc. The description's mention of '5-90 minutes' adds context for task duration but is not parameter-specific.
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?
Title 'Decompose goal into tasks' and description 'Break a vague goal into a small ordered list of atomic 5-90 minute tasks with explicit acceptance criteria and dependency edges' clearly state the verb (break) and resource (goal into tasks). It distinguishes from sibling tools like 'brief_meeting' or 'record_fact' which are unrelated.
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 vague goal decomposition, stating 'Break a vague goal...'. It does not explicitly mention when-not-to-use or alternatives, but sibling tools are diverse so no confusion. The stateless note clarifies that tasks are not persisted, guiding agent behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disable storage and erase it. Hosted: destroys the NeuroDock-managed database NeuroDock provisioned for you. BYOS: clears the stored connection (your own database is left untouched). Either way your stored preference and consent are cleared. Requires a signed-in account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behaviors: it destroys the database for Hosted, clears connection for BYOS, and clears preferences/consent. It also mentions the requirement of a signed-in account. Irreversibility is implied but not explicitly stated.
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?
Three sentences with no wasted words. The first sentence states the main action, the second provides mode-specific details, and the third adds a permission requirement. Every sentence earns its place.
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 zero parameters and no annotations, the description is complete. It covers both hosting modes, what is erased, and the signing requirement. An output schema exists, so return values need not be described.
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?
Zero parameters are present, and schema coverage is 100% (vacuous). The baseline for zero parameters is 4, as the description does not need to add parameter info.
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 verb 'disable and erase' and the resource 'storage'. It distinguishes between Hosted and BYOS modes, providing specific actions for each. This differentiates it from siblings like enable_hosted_storage or disconnect_storage.
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 completely disabling and erasing storage, but does not explicitly state when to use versus alternatives like disconnect_storage. No exclusions or comparisons are provided, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disconnect your BYOS storage database. NeuroDock deletes the connection and retains nothing about your storage. Your data stays in your own database, untouched. (To erase NeuroDock-hosted storage instead, use disable_and_erase_storage.) Requires a signed-in NeuroDock account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the behavior clearly: deletes the connection, retains nothing about the storage, and leaves user data untouched. This goes beyond what annotations would provide, especially since no annotations are given.
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 three sentences plus a parenthetical. Each sentence adds value: action, consequence, alternative, and prerequisite. No wasted 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?
Given zero parameters and an output schema for return values, the description adequately explains the tool's purpose, effect, and usage context. It is complete for the complexity level.
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 input schema has zero parameters, so the baseline is 4. The description does not add parameter information because none exist.
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 action 'Disconnect' and the resource 'BYOS storage database'. It also distinguishes from the sibling tool 'disable_and_erase_storage' by specifying the different effect on data.
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 tells when to use the tool (disconnect BYOS storage) and when not to (to erase NeuroDock-hosted storage, use 'disable_and_erase_storage'). It also includes a prerequisite: 'Requires a signed-in NeuroDock account.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enable NeuroDock-hosted storage: NeuroDock provisions a private database (isolated to your account) and the memory tools store data there. Records your explicit consent and returns a disclosure of what is stored and how to erase it. Requires a signed-in NeuroDock account. For maximum privacy use connect_byos_storage (your own database) instead.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: it provisions an isolated database, records consent, returns a disclosure, and requires authentication. 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?
The description is concise (three sentences), front-loaded with purpose, and every sentence adds value without 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?
Given the tool's simplicity (no params, has output schema), the description covers purpose, usage guidance, behavioral aspects, and outcome, making it fully complete.
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?
There are no parameters, so the baseline is 4. The description adds no parameter details, which is appropriate as none exist.
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 enables NeuroDock-hosted storage, provisions a private database, and distinguishes itself from the sibling 'connect_byos_storage' by noting privacy differences.
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 tells when to use (for convenience) and when not to use (for max privacy, use connect_byos_storage instead), and mentions the prerequisite of a signed-in account.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return decisions recorded against a named project in your connected cognitive graph, newest first, optionally filtered by an ISO 8601 since-date. Requires a signed-in account with connected storage.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | ||
| since | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses ordering, filtering, and a prerequisite but does not explicitly state that it is a read-only operation or describe potential side effects, error cases, or idempotency.
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 two sentences that front-load the main action and parameters, followed by a prerequisite. No redundant information.
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 adequately covers core functionality and prerequisites. Given the existence of an output schema, it does not need to detail return values. However, it could mention behavior when the project does not exist.
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 schema has 0% coverage, so the description adds meaning by explaining that 'since' is an ISO 8601 date filter and 'project' is a named project, but it does not elaborate on the project name format or provide additional constraints.
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 specifies the verb 'Return' and the resource 'decisions recorded against a named project'. It also includes ordering ('newest first') and optional filtering, distinguishing it from sibling tools like recall_entity or record_fact.
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 retrieving decisions but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up everything your connected cognitive graph knows about a named person, project, decision, or concept. Alias-resolves the input. Requires a signed-in account with connected storage (connect_byos_storage).
| Name | Required | Description | Default |
|---|---|---|---|
| name_or_alias | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses alias resolution and a prerequisite, but does not mention whether the operation is read-only, performance implications, or any side effects. This is adequate but not comprehensive.
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: first covers purpose, second covers prerequisite and key behavior (alias resolution). Every word serves a purpose; 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?
Given the output schema exists (so return values need not be described), the description covers purpose, parameter semantics, prerequisite, and a behavioral trait. It lacks details on limits, errors, or expected data volume, but is still sufficient for a single-param tool.
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% (no description for 'name_or_alias'). The description compensates by defining the parameter as a name or alias of a person/project/decision/concept, and notes alias resolution. It adds meaningful context beyond the schema's bare field name.
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 verb ('Look up everything'), the resource ('your connected cognitive graph'), and the scope ('named person, project, decision, or concept'). It distinguishes from sibling tools like 'recall_decisions' by covering broader entity types.
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 provides explicit context for use: it requires a signed-in account with connected storage. It implies that the tool is for broad entity recall, not for specific sub-types. However, it lacks explicit when-not-to-use or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Persist a typed-edge (subject, predicate, object) fact into your connected cognitive graph. Entities referenced by name are auto-created. Requires a signed-in account with connected storage (connect_byos_storage).
| Name | Required | Description | Default |
|---|---|---|---|
| subject | Yes | ||
| predicate | Yes | ||
| object | Yes | ||
| source | No | ||
| confidence | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It discloses auto-creation of entities and storage requirement, but does not mention potential side effects, return value, or error conditions. Adequate but not comprehensive.
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 the core function. Could be slightly more detailed on parameters without becoming verbose. Still efficient for its purpose.
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 tool has an output schema (unknown content) but description does not mention output. With 5 parameters, none documented in schema, the description covers the main action but lacks parameter guidance. Might be sufficient for simple use but not fully complete.
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%. The description explains the main triple (subject, predicate, object) in context, but does not describe the optional 'source' and 'confidence' parameters beyond their names and types. This leaves ambiguity for the agent.
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 persists a typed-edge fact (subject, predicate, object) into a cognitive graph. It specifies auto-creation of entities, distinguishing it from recall or checking tools among siblings.
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 mentions prerequisites: signed-in account with connected storage, and references connect_byos_storage. However, it does not provide explicit when-to-use or when-not-to-use guidance compared to alternatives like recall_decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rewrite an outgoing message toward a target register while preserving caller-named technical terms. The deterministic baseline applies register-specific surface transforms; the LLM refinement prompt produces a stronger rewrite while keeping the same preservation contract.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| target_register | Yes | ||
| preserve_terms | No | ||
| channel | No | ||
| preserve_intent | No | ||
| reader_context | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and idempotentHint, indicating safe, side-effect-free operation. The description adds behavioral detail: a deterministic baseline applies transforms, then an LLM refinement produces a stronger rewrite while preserving terms. This adds value beyond annotations without contradiction.
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. The first sentence clearly states the main function; the second adds nuance about the rewriting process. It is efficient but 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?
The tool has 6 parameters, an output schema, and annotations. The description covers the core function but lacks parameter details and usage context. For a tool with moderate complexity, it is incomplete; more information on parameter roles would improve 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?
Schema coverage is 0%, so the description must compensate. It only mentions 'preserving caller-named technical terms,' which relates to preserve_terms, but does not explain text, target_register, channel, preserve_intent, or reader_context. The description adds minimal meaning beyond the input 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 rewrites an outgoing message toward a target register while preserving caller-named technical terms. The verb 'rewrite' and resource 'outgoing message' are specific, and it distinguishes between deterministic baseline and LLM refinement, which sets it apart from sibling tools like translate_incoming.
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 description implies use for register rewriting but does not mention when not to use it, prerequisites, or comparisons with sibling tools. Usage is implied but not clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report whether you are signed in and which storage mode is active (mode: hosted, byos, or none).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It accurately describes the tool's behavior as a read-only status check returning sign-in status and storage mode. It does not mention side effects or error cases, but for a simple query 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?
The description is a single sentence, front-loaded with the core purpose ('Report whether you are signed in'), and contains no extraneous words. It efficiently conveys the necessary information.
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 simplicity (zero parameters, read-only), the description covers the essential information. The presence of an output schema likely details return values, so the description need not elaborate. However, it could explicitly mention that no authentication is required or that it returns current state without side effects.
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 input schema has zero parameters, so schema description coverage is 100%. The baseline is 3. The description adds no information about parameters (none exist), and the output is not covered by this dimension. It does add meaning about what the tool reports, but that is output-related.
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 reports sign-in status and active storage mode, using specific verbs ('Report') and resources. It distinguishes itself from sibling storage tools like 'enable_hosted_storage' and 'connect_byos_storage' which perform actions, while this tool is purely a status query.
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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites or context for invocation. While the purpose is clear, the lack of usage guidelines leaves ambiguity for the AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode subtext, ambiguity, and the likely implicit ask in an incoming message. Returns a deterministic baseline analysis plus a structured prompt the caller's MCP client MAY execute to refine the baseline against its own LLM.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| channel | No | ||
| thread_context | No | ||
| target_language | No | ||
| reader_context | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds value by explaining the two-part output (baseline analysis + structured prompt) and clarifying that the prompt may be executed by the caller's client, not the tool itself.
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 that are front-loaded with purpose. Could be improved by briefly mentioning key parameters to avoid ambiguity.
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 annotations and output schema, the description omits parameter explanations and usage context. The optional parameters like 'channel', 'thread_context', and 'reader_context' are not addressed, making the tool less complete for agents.
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%, yet the description does not explain any of the 5 parameters. 'target_language' is especially misleading given the description's focus on decoding subtext rather than language translation.
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 decodes subtext, ambiguity, and implicit asks, providing a distinct purpose. However, the name 'translate' and the presence of 'target_language' parameter may confuse agents about language translation. No sibling comparison is needed as no other tool does this.
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 sibling list includes cognitive checks and output rewriting tools, but no exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a server-generated activity summary of your connected cognitive graph for the trailing seven local days, optionally scoped to a project. Requires a signed-in account with connected storage.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the summary is server-generated, time-bound, and optionally scoped. It does not specify side effects or read-only nature, but 'summary' implies no mutation. Lacks details on caching or rate limits.
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 pack purpose, parameters, and prerequisite with no waste. Information is front-loaded.
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, the description need not detail return values. It covers purpose, time range, scoping, and authentication. It could mention what kind of activities are summarized, but overall is adequate for a simple tool.
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%, but the description explains the single optional parameter 'project' as a scoping filter. This adds meaning beyond the schema, though it could define 'project' more precisely.
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 returns a server-generated activity summary for the trailing seven days with optional project scoping. It uses a specific verb and resource, and distinguishes from siblings like recall_decisions or check_hyperfocus.
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?
Description mentions the prerequisite of a signed-in account with connected storage, which helps the agent know when the tool is available. It does not explicitly contrast with alternatives, but the nature of a weekly summary vs. specific checks is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose, grouped into cognitive checks, storage management, graph operations, and communication helpers. Within each group, tools target different aspects (e.g., check_hyperfocus vs. check_rumination) so an agent can easily select the correct one.
All tools use snake_case, and most follow a verb_noun pattern. However, 'storage_status' and 'weekly_rollup' are noun_noun and adjective_noun respectively, which deviates slightly from the dominant verb-first convention. Overall still predictable.
With 17 tools, the surface is well-scoped for a personal cognitive assistant. Each cluster (storage, cognitive checks, graph, communication) has just enough tools to be useful without excessive overlap or bloat.
The tool set covers core workflows: storage lifecycle, cognitive checks, graph operations (CRUD-like with recall and record), and communication helpers. Minor gaps exist, such as the absence of fact update/delete or project creation, but the provided tools enable a coherent agent workflow.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP-native notes and memory for ChatGPT, Claude, and other AI tools.
Persistent AI memory shared across Claude, ChatGPT, coding agents, and compatible MCP clients.
Persistent context for Claude. Your AI always knows your projects and next actions across sessions.
Persistent memory for AI assistants. Save once; recall from Claude, ChatGPT, or any MCP client.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tlennon-ie/neurodock'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
