Waymark is a shared memory and handoff hub for AI agents, enabling seamless context transfer and task coordination across sessions via a local MCP server backed by SQLite.
Resume a workspace session (workspace_resume): Restore compact, token-budgeted project state (metadata, open tasks, ranked memories, active handoffs) for a new agent session — reducing orientation context by ~91.5% vs. cold reading.
Get task-specific context (context_get): Build focused, deterministically ranked project context tailored to a specific task, filtered by memory types and constrained to a token budget.
Write & manage memory nodes (memory_write, memory_read, memory_search): Create, read, search, and update named memory records (decisions, handoffs, references, feedback, etc.) with lifecycle statuses (active, superseded, stale, archived), confidence/importance ratings, and supersession of old records.
Coordinate tasks (task_create, task_list, task_update, task_claim): Create tasks with priorities, dependencies, and required capabilities; list/update them; and atomically claim pending tasks — ensuring only one agent takes a task after validating capabilities and resolved dependencies.
Log sessions (session_log): Record session outcomes (completed, partial, blocked) with summaries, decisions, commits, and files touched. Partial/blocked sessions automatically create handoff memories so the next agent can resume without retelling.
Register agents: Agents can register themselves with provider/model/client identity for tracking.
Manage projects: List, get, upsert, and set the status of projects to organize work.
Monitor usage & experiments: Log usage reports and manage experiments, including creation, listing, updating, and summarizing results.
Dashboard: A read-only web panel to view projects, tasks, memory, sessions, agents, and benchmark results.
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., "@Waymark Resume my workspace for project 'doc-bot'"
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.
Shared memory and handoff hub for AI agents. A waymark is a trail sign left for whoever walks the path next — Waymark does the same for agent sessions: Claude Code finishes work, and the next session of Codex, Claude Desktop, or any other MCP client starts already knowing what was done, what was decided, and what to do next.
No retelling. No re-reading the repo. One token-budgeted call.
Every new agent session starts cold: it re-reads files, re-asks questions, and burns tokens rediscovering context that another agent had five minutes ago. Waymark replaces that with a local MCP server over a single SQLite database shared by all your agents:
workspace_resume — one call returns a compact packet (project metadata,
open tasks, ranked memory, recent sessions, active handoff) within a token
budget you set (default 1,200 tokens).
Automatic handoffs — session_log(outcome: "partial", next_steps: [...])
writes a handoff memory that tops the next agent's resume. Logging
completed retires it. No discipline required.
Task queue with atomic claims — task_claim guarantees only one agent
takes a task, with capability and dependency checks.
Memory lifecycle — supersede instead of accumulate; feedback ratings demote stale records in ranking.
Provider-neutral — agents register with provider/model/client identity; nothing in the core is tied to one vendor.
Related MCP server: Shared Memory MCP Server
Continuation scenario (fresh session must orient in a project and name the next
step), estimated cohort, reproducible via node scripts/benchmark-orientation.cjs:
median tokens | |
Cold orientation (reading README, docs, sources, git log) | 13,540 |
Waymark resume (packet + core tool schemas + follow-up reads) | 3,392 |
Net saving | 74.9% |
The orientation context itself shrinks from ~13.1k tokens of raw files to a 1.1k-token ranked packet (−91.5%) — and unlike cold reading, the packet contains what files can't: what the previous agent actually did and decided. The exact-token A/B protocol with live clients is in docs/BENCHMARK_RUN.md.
Requires Node.js 22+.
npm install -g waymark-hub
waymark-hub init # registers the hub in Claude Code / Codex, offers the hook
waymark-hub doctor # verifies the whole installationinit asks before touching anything; init --yes enables everything
applicable. The database lives in ~/.waymark/hub.db (survives package
upgrades); override with WAYMARK_HOME or DB_PATH.
From source instead:
git clone https://github.com/SerjMihashin/waymark && cd waymark
npm install && npm test # build + 20 integration testswaymark-hub init --claude, or manually:
claude mcp add --scope user waymark node "<install>/dist/server.js"Optional but recommended — waymark-hub init --hook installs a SessionStart
hook that injects the resume packet into every new session (zero tool calls
spent on orientation).
waymark-hub init --codex, or manually:
# ~/.codex/config.toml
[mcp_servers.waymark]
command = "node"
args = ["<install>/dist/server.js"]waymark-hub serve --http # listens on 127.0.0.1:3747Add a custom connector: http://localhost:3747/mcp. Also available via
docker compose up -d / podman compose up -d.
Session start — one call, not three:
workspace_resume(project_id, task?, agent_id?, max_tokens=1200)Session end:
session_log(started_at, summary, outcome, next_steps?) # partial/blocked → auto-handoff
memory_write(...) # only durable decisions/factsCross-agent handoff happens automatically: agent A logs a partial session
with next_steps; agent B's workspace_resume surfaces that handoff first,
with the session trail and files touched. When someone logs completed, the
handoff retires itself.
Greedy MCP clients inject every tool schema into context each turn. Waymark
defaults to a core profile of 10 tools (~1.8k tokens instead of ~4.7k for
all 28). Set HUB_TOOLS=full where you need the admin surface (projects,
agents, experiments, telemetry).
Group | Tools |
Context |
|
Memory |
|
Tasks |
|
Projects |
|
Agents |
|
Sessions & telemetry |
|
Deep dives: docs/CONTEXT.md, docs/MEMORY_LIFECYCLE.md, docs/TASK_COORDINATION.md, docs/BENCHMARKING.md.
npm run dashboard → read-only web panel on http://localhost:4747: projects,
tasks, memory (FTS search), sessions, agents, benchmark results. Opens the DB
in read-only mode — it physically cannot mutate hub state.
src/server.ts entry point: stdio / HTTP (--http), tool profiles
src/db/client.ts SQLite singleton (WAL) + idempotent migrations 001..005
src/tools/ projects · memory · tasks · sessions · agents · context · telemetry
src/context/builder.ts deterministic ranking + token budget (no LLM calls)
src/cli/benchmark.ts A/B experiment CLI
dashboard/ read-only Express panelStorage: SQLite + FTS5. The core never calls an LLM or any external service.
Context on demand — summaries + ids by default; bodies only when asked.
Budget first — every aggregated response fits a token budget.
Evidence over retelling — link files/commits/tasks instead of copying text.
Replace, don't accumulate — supersede outdated memory, no duplicates.
Provider-agnostic — any MCP client is a first-class citizen.
MIT
Build task-specific project context using deterministic ranking within a token budget.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | ||
| agent_id | No | ||
| client_id | No | ||
| max_tokens | No | ||
| project_id | Yes | ||
| memory_types | No | ||
| include_sources | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond the readOnlyHint annotation by mentioning 'deterministic ranking' and 'token budget', which imply predictable, constrained output. However, it does not disclose edge cases (e.g., behavior when token budget is exceeded) or clarify if the tool modifies state (contradicting the annotation only if 'build' is interpreted as mutation; but readOnlyHint=true suggests it is safe).
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, making it very concise, but it omits crucial information. While there is no wasted text, the lack of structure (e.g., parameter explanation) reduces its effectiveness.
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 (7 parameters, no output schema, no schema descriptions), the description is severely incomplete. It does not explain the return format, how ranking works, or how parameters like memory_types affect behavior. The presence of readOnlyHint partially compensates, but the description leaves major 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?
With 0% schema description coverage, the description carries the full burden of explaining parameters, but it does not mention any of the seven parameters (task, project_id, max_tokens, etc.). The agent receives no help understanding parameter roles, constraints, or defaults from the description.
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's function: building task-specific project context using deterministic ranking and token budget. It implies a distinct purpose from sibling tools like memory_read and memory_search, which likely retrieve raw memories rather than curated context.
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 is provided on when to use this tool versus alternatives such as memory_read or memory_search. The description does not mention prerequisites, exclusions, or typical use cases, leaving the agent without decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a single memory node by id or by project+name.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Memory node UUID | |
| name | No | Memory node name slug | |
| project_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true. The description merely restates 'Read' without adding further behavioral details (e.g., error handling, auth requirements, or limitations). No contradiction, but no added transparency 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 sentence, front-loaded with purpose and key usage. Zero waste, every word 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?
For a simple read tool with readOnlyHint annotation, the description covers the essential lookup modes. While it omits return format and not-found behavior, the tool is straightforward and the description is sufficiently 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?
The description clarifies the idiomatic usage patterns: either 'id' alone or 'name' + 'project_id' together. This adds meaningful context beyond the schema, which marks parameters as optional without explaining the combinatorial constraint.
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 precisely states 'Read a single memory node by id or by project+name.' This clearly identifies the verb and resource, and distinguishes it from sibling tools like memory_search (which likely returns multiple results) and memory_write (which mutates).
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 like context_get or memory_search. The description implies usage for known identifiers but does not specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across all memory nodes. Use to find anything known about a topic.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Search terms | |
| project_id | No | Limit to a specific project. Omit to search all. | |
| include_inactive | No | Include stale, superseded, archived, and expired records |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds minimal behavioral context beyond stating it performs full-text search. It does not disclose result format or pagination behavior.
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. The first sentence front-loads the core functionality, making it immediately actionable.
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 search tool with no output schema, the description omits what the output looks like (e.g., matching records with relevance scores). It adequately covers the input but misses output 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 coverage is 75%, so the schema already describes most parameters. The description does not add further meaning to the parameters beyond what the schema provides, meeting the baseline.
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 performs full-text search across all memory nodes, with explicit usage guidance. This differentiates from siblings like memory_read (specific key lookup) and memory_write (write operation).
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 suggests using it to find anything known about a topic, but does not specify when not to use it or contrast with alternatives like context_get or memory_read. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or replace a named memory node (project-scoped, or global if no project_id).
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | markdown body | |
| name | Yes | kebab-case slug | |
| tags | No | ||
| type | No | project | |
| status | No | ||
| surface | No | claude-code | |
| agent_id | No | ||
| confidence | No | ||
| importance | No | ||
| project_id | No | omit for global | |
| source_ref | No | ||
| valid_from | No | ||
| description | Yes | one-line summary | |
| source_type | No | ||
| valid_until | No | ||
| supersedes_id | No | id this record replaces | |
| origin_session | No | ||
| last_verified_at | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must cover behavioral traits. It only states 'Create or replace', but does not explain what 'replace' entails (e.g., full overwrite or merge), side effects, auth requirements, or rate limits. This is insufficient for a mutation tool with many optional fields.
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 front-loads the verb and resource. It is concise, but could benefit from a brief explanation of replacement behavior or required fields. Still, no extraneous content.
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 18 parameters, no output schema, and no annotations, the description is far too minimal. It fails to explain the return value, how replacement works, or how to use the many optional parameters like tags, type, status, etc., making it incomplete for an AI agent.
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 only 28%, so the description should add meaning for the many undocumented parameters. However, the description only references project_id (scope) and does not explain any other parameter (e.g., tags, type, status, confidence, etc.), 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 verb 'Create or replace' and the resource 'named memory node', along with scope differentiation (project-scoped vs global based on project_id). This distinguishes it from sibling read tools like memory_read and memory_search.
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 is provided on when to use this tool versus alternatives. There is no mention of when to use memory_write instead of task_create or other write tools, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record a session summary at the end of significant agent work. On outcome "partial"/"blocked" (or when next_steps are given) the hub automatically writes a handoff memory so the next agent resumes without retelling; outcome "completed" retires that auto-handoff.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | ||
| client | No | ||
| outcome | No | completed | |
| summary | Yes | what was accomplished and decided | |
| surface | No | claude-code | |
| agent_id | No | ||
| provider | No | ||
| next_steps | No | concrete next actions for whichever agent continues this work | |
| project_id | No | ||
| started_at | Yes | ISO datetime session started | |
| commits_made | No | ||
| files_touched | No | ||
| client_session_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description reveals key behaviors: automatic handoff memory creation for 'partial'/'blocked' outcomes, retirement for 'completed'. However, it does not mention side effects like overwriting handoff state, destructive actions, or auth requirements.
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 concise sentences with no wasted words. Information is front-loaded with the core action, followed by conditional behavior details.
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 side effects (handoff memory) but lacks error cases, rate limits, or guidance on parameter usage for the 11 undocumented fields. Given 13 parameters and no output schema, 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?
Schema coverage is low (23%), and the description only semantically clarifies 'outcome' and 'next_steps' in the context of handoff behavior. Most parameters (model, client, surface, etc.) remain unexplained, failing to compensate for the schema 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 verb 'Record' and the resource 'session summary at the end of significant agent work'. It distinguishes from sibling tools like memory_write by emphasizing session logging and automatic handoff behavior.
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 specifies when to use ('at the end of significant agent work') and explains behavior based on outcome values. It does not explicitly exclude situations or name sibling tools, but context signals show it's distinct from general memory tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Atomically claim a pending task after validating assignment, capabilities, and dependencies.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| agent_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states atomicity and validation but fails to disclose side effects (e.g., task state change, failure behavior, permissions required). The behavioral picture is incomplete.
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, front-loaded sentence that efficiently conveys the core action. However, it could be structured better (e.g., separate parameter details) given the lack of schema descriptions.
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 no output schema and a complex operation involving validation and state changes, the description omits crucial context: return values, error conditions, and post-claim state. Sibling tools exist but are not contrasted.
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 adds no meaning for the two parameters ('id', 'agent_id'). It does not explain what they represent (e.g., task ID, claimant). This is a major 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 uses a specific verb 'claim' and resource 'pending task', clearly distinguishing it from sibling tools like task_create or task_list. It also adds conditions (validating assignment, capabilities, dependencies), making the purpose unambiguous.
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 claiming a pending task but does not explicitly state when to use it vs alternatives (e.g., when not to use, prerequisites). Sibling tool names are provided but no comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a handoff task for another agent or client.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | short imperative title | |
| priority | No | 0-100, higher = more urgent | |
| created_by | No | claude-code | |
| project_id | No | ||
| assigned_to | No | ||
| description | Yes | what to do and why | |
| context_json | No | structured handoff data: paths, URLs, selectors | |
| dependency_ids | No | tasks that must finish first | |
| created_by_agent | No | ||
| assigned_agent_id | No | ||
| required_capabilities | No | capabilities the claiming agent must have |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, idempotency, authorization requirements, or what happens upon creation. The description is minimal and fails to inform the agent of critical behavioral aspects.
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, front-loaded sentence that efficiently conveys the tool's purpose. Every word is necessary, and there is no redundancy or 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?
Given the tool has 11 parameters, no output schema, and no annotations, the description is severely lacking. It does not explain the creation process, what constitutes a handoff, how tasks are claimed, or any constraints. The agent would be left with significant uncertainty.
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 description adds no extra meaning beyond what the input schema already provides. With schema description coverage at 55%, the description does not compensate for the 5 parameters lacking descriptions in the schema (e.g., created_by, project_id, assigned_to, created_by_agent, assigned_agent_id).
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 'Create' and the resource 'handoff task', and specifies the target audience 'for another agent or client'. This distinguishes it from sibling tools like task_claim, task_list, and task_update, which perform different actions on tasks.
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. It lacks explicit context for appropriate use, such as scenarios requiring task handoff, and does not mention when not to use it or mention any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tasks by status, project, assignee, or blocker.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| status | No | ||
| blocked | No | ||
| created_by | No | ||
| project_id | No | ||
| assigned_to | No | ||
| claimed_by_agent | No | ||
| created_by_agent | No | ||
| assigned_agent_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, but description adds no behavioral context (e.g., pagination, ordering, response format). Does not contradict 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 sentence of 8 words, highly concise. Front-loaded with filtering capabilities but could benefit from structuring or additional context.
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?
Complexity is moderate with 9 optional parameters and no output schema. Description fails to mention response format, ordering, pagination, or the default behavior when no filters applied.
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 must compensate. It explains four parameters (status, project, assignee, blocker) but omits limit, created_by, and agent-related fields. Partial compensation for low coverage.
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 (List) and resource (tasks) and mentions filtering dimensions (status, project, assignee, blocker). Differentiates from sibling tools focusing on memory or mutation.
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 like memory_search or task_search. Does not mention it is read-only or that it returns unfiltered tasks if no parameters provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update task status, progress, blocker, or notes.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| status | No | ||
| blocker | No | null clears it | |
| progress | No | ||
| description | No | ||
| context_json | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only says 'update' but doesn't disclose if it is destructive, idempotent, or has side effects like status change triggers. No error conditions or authorization requirements mentioned.
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?
Very concise single sentence, front-loaded with key fields. Could be improved by listing fields inline, but no extra 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?
With 6 parameters, no output schema, and no annotations, the description misses return values, error handling, required id, and completely omits context_json. Inadequate for fully understanding the 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 17% (only blocker has a description). The description maps 'status, progress, blocker, or notes' to parameters, but 'notes' is actually 'description'. It omits 'context_json' entirely, so adds some but incomplete meaning.
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 'Update task status, progress, blocker, or notes', specifying the action and resources. It distinguishes from siblings like task_create (create), task_list (list), task_claim (claim), etc.
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, no prerequisites mentioned (e.g., task must exist), and no exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restore compact project state for a new agent session in one token-budgeted call.
| Name | Required | Description | Default |
|---|---|---|---|
| task | No | ||
| agent_id | No | ||
| client_id | No | ||
| max_tokens | No | ||
| project_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation indicates readOnlyHint=true, covering safety. The description adds the 'token-budgeted' trait, but 'restore' could be misinterpreted as a mutation. No additional behavioral context (e.g., what state is loaded, impact on session) is disclosed beyond the annotation.
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, focused sentence with no extraneous words. It is front-loaded with the core purpose, though it could benefit from a clearer structure or bullet points.
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 five parameters, no output schema, and 0% schema description coverage, the description is insufficient. It omits all parameter semantics, return values, and edge case behavior, making the tool hard to use correctly.
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 mention any of the five parameters. The agent receives no guidance on the meaning or usage of parameters like 'task', 'agent_id', 'client_id', 'max_tokens', or 'project_id'.
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 ('restore'), the resource ('compact project state'), and the context ('new agent session', 'token-budgeted'). However, it does not differentiate from sibling tools like context_get or memory_read, which might also restore state.
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 is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or typical contexts.
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.
v1.0.0context_getmemory_readmemory_searchmemory_writesession_logtask_claimtask_createtask_listtask_updateworkspace_resumeEach tool has a clearly distinct purpose: context building, memory operations, session logging, task management, and workspace resumption. No overlapping functionality.
All tools follow a consistent verb_noun snake_case pattern (e.g., `memory_read`, `task_create`), making naming predictable and intuitive.
10 tools is well-scoped for the server's domain of agent orchestration and memory management, covering core operations without bloat.
Covers CRUD for memory (read, search, write) and tasks (create, list, update, claim) plus session logging and context. Minor gap: no explicit task deletion or memory deletion, but these are not critical for the intended workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Durable agent-to-agent handoffs and shared scratchpad for multi-agent workflows.
Shared long-term memory for AI agents: save and recall context as a searchable knowledge graph.
Shared project context for AI agents and teams: docs, tasks, and messages that stay current.
Persistent cross-session memory shared by Codex, Claude Code, ChatGPT, and other AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/SerjMihashin/waymark'
If you have feedback or need assistance with the MCP directory API, please join our Discord server