Connection check
verified live · 27h ago
meridian
Persistent memory, task coordination, and HITL queue for AI coding sessions.
Tools
180
GitHub stars
—
Installs / wk
—
Licence
—
Transport
sse, stdio
Last checked
27h ago
Tools & capabilities
180 toolsRead from the running server on 27h ago.
accept_handoff
goal_tokenlive_itemsproject_idproject_namepresented_bodyrequired_tools
+5
[SUPPORT] Read-only: (1bd5e810) Canonical receiver-side acceptance check for a handoff envelope — composes token verification, capability/tool availability, tool-manifest drift, an… [SUPPORT] Read-only: (1bd5e810) Canonical receiver-side acceptance check for a handoff envelope — composes token verification, capability/tool availability, tool-manifest drift, and board-revision divergence into ONE structured verdict, so MCP/HTTP/stdio all produce identical results for identical input (same underlying meridian.handoff.accept_handoff_envelope every transport calls). Every input is optional and independently gated — supply whatever you have; an omitted check is skipped, never failed. Returns {accepted: bool, result: 'ok'|'STALE_HANDOFF'|'FOREIGN_PROJECT_CONFIG'|'BOARD_DIVERGENCE'|'TOOL_MANIFEST_DRIFT'|'BODY_HASH_MISMATCH'|'CAPABILITY_UNAVAILABLE', reasons: [str], token_check, identity_check, capability_check, tool_manifest_check, board_check, is_trusted_channel: false, delivery_source: str}. Checks run in this order, short-circuiting on first failure: (1) token — token/presented_body via the same verify_handoff_token check; a body_mismatch reason maps to BODY_HASH_MISMATCH, every other invalid reason (not_found/wrong_project/already_consumed/expired) maps to STALE_HANDOFF — the raw token_check.reason sub-field always preserves which one, since AGENTS.md treats not_found/wrong_project as real spoofing signals and already_consumed/expired as usually just a sibling session having already acted. (2) identity binding (22f2604d) — presented_body's own <project_start_config> tag vs THIS call's project_id/expected_repo_path, via meridian.handoff.check_project_start_config_identity; runs whenever step (1) did not already reject the envelope on its own basis — i.e. token verification passed or no token was presented — so a body whose embedded identity disagrees with project_id is FOREIGN_PROJECT_CONFIG even when the token itself verified ok. This catches a genuine token paired with a foreign project's start-config, which step (1)'s wrong_project check alone cannot (that only catches a token minted for a DIFFERENT project_id, not a body whose own tag disagrees with a token that legitimately matches project_id). It does NOT re-run after step (1) already failed (STALE_HANDOFF/BODY_HASH_MISMATCH) — that failure is independently sufficient to reject the envelope. (3) capability — required_tools vs available_tools: any required name missing from available_tools is CAPABILITY_UNAVAILABLE. (4) tool-manifest drift — expected_required_tools_hash vs a hash computed live from live_items' own tool_requirements fields (see meridian.handoff.compute_required_tools_hash): mismatch is TOOL_MANIFEST_DRIFT. (5) board revision — expected_board_revision (acf6f51a's manifest <handoff_manifest board_revision=...>) vs a hash computed live from live_items via meridian.handoff.compute_board_revision: mismatch is BOARD_DIVERGENCE. live_items is YOUR OWN get_sprint_items(...) result — this tool never queries the board itself, so you control exactly which project/version/status filter "live" means; pass the same filter used when the compared handoff/manifest was generated. is_trusted_channel is always false here (calling this tool at all means verifying something other than the trusted pending_goal/load_handoff channel — see those tools' own docs). Scope note: this is a validation/report tool, not a hard gate — it is not wired into claim_sprint_item in this pass. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
activate_profile_layer
actorscope_id*
[SUPPORT] 0bec79a7 (PROFILE-5) — Advance a hosted_default layer's lifecycle to 'active' — the single 'publish' operation for the hosted_default floor (fae6e882 pinned decision coll… [SUPPORT] 0bec79a7 (PROFILE-5) — Advance a hosted_default layer's lifecycle to 'active' — the single 'publish' operation for the hosted_default floor (fae6e882 pinned decision collapsed 'publish' and 'activate' into this one tool: a hosted_default layer becomes authoritative the moment it reaches 'active', so there is no separate publish step to expose). Only a draft -> active or deprecated -> active transition is valid; any other current state (e.g. retired, which is terminal) rejects with {error}. Idempotent: calling on an already-active scope is a no-op success (same revision, no new audit row). See reset_profile_layer for the non-audited 'clear the row entirely' path, or save_profile_layer followed by this tool for the audited draft-then-publish flow. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
add_custom_hook
name*event*enabledmatcherblockingscript_sh*
+3
[MAINTENANCE] 273287cb — define a user-creatable Claude Code hook (PreToolUse | PostToolUse | Stop), generalizing past sprint_guard.sh/.ps1 (the only hook Meridian auto-writes toda… [MAINTENANCE] 273287cb — define a user-creatable Claude Code hook (PreToolUse | PostToolUse | Stop), generalizing past sprint_guard.sh/.ps1 (the only hook Meridian auto-writes today). Written into the repo's .claude/hooks/<slug>.sh / .ps1 on the next generate_handoff — the same auto-inject mechanism sprint_guard already uses. script_sh (POSIX shell body) is required; script_ps1 (PowerShell body) is optional — omit it to only ever write the .sh file. matcher is a Claude Code tool-name regex (e.g. "Edit|Write"), ignored for Stop hooks. blocking (default true) controls determinism vs. suggestion power: true writes the script byte-for-byte so its own exit code drives REAL Claude Code exit-code-blocking semantics (exit 2 blocks a PreToolUse call / a Stop / feeds PostToolUse output back to the model); false wraps it so an exit 2 is downgraded to 1 before it's written — the hook still runs and its output still surfaces, but it can never hard-block ('strong suggestion power' without determinism). name must not be 'sprint_guard' (reserved for Meridian's own hook) or collide with an existing hook's derived slug on this project — both raise a clear {error}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
add_insight
bodytagstitle*horizonproject_idproject_name
[SUPPORT] Record a durable STRATEGIC INSIGHT — accumulated understanding that generates future decisions. A first-class knowledge type SEPARATE from decisions (choices with a lifec… [SUPPORT] Record a durable STRATEGIC INSIGHT — accumulated understanding that generates future decisions. A first-class knowledge type SEPARATE from decisions (choices with a lifecycle) and notes (reference). horizon sets its shelf-life: 'permanent' insights ALWAYS surface in get_planning_brief; 'year'/'quarter' are time-boxed. Returns the stored insight. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
add_note
body*kindtagstitle*sourcesymbol
+5
[SUPPORT] Add a per-project wiki note (setup, gotcha, howto, env, ...). Free-form title/body; comma-separated tags optional. Optional kind (wiki=gotcha/rule/howto, insight=strategi… [SUPPORT] Add a per-project wiki note (setup, gotcha, howto, env, ...). Free-form title/body; comma-separated tags optional. Optional kind (wiki=gotcha/rule/howto, insight=strategic/product analysis, reference=external/one-off docs, code=warning/context anchored to a file, document=ingested report/spec/thesis) controls how the dashboard renders it. For a code anchor pass kind='code' plus file_path (and optional symbol): the note is then surfaced automatically when a session calls claim_file/get_file_claims for that path, so the executor sees the warning before editing. Pass source (a URL or file path) to record where the note came from — set automatically by ingest_document. Tag a note 'roadmap' AND pass a committable category (TECHNICAL/ARCHITECTURAL/PRODUCT) to also append it to ROADMAP.md's roadmap-notes anchor. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
add_proposal_gate
affected*category*evidence*question*created_byexpires_at
+4
[SUPPORT] Raise a typed, lane-blocking HITL gate for a materially ambiguous decision — legal/IP, product scope, destructive operations, production deployment, human acceptance of a… [SUPPORT] Raise a typed, lane-blocking HITL gate for a materially ambiguous decision — legal/IP, product scope, destructive operations, production deployment, human acceptance of a contradiction, or other materially ambiguous decisions (category must be one of: legal_ip, product_scope, destructive_ops, production_deploy, contradiction_acceptance, other_ambiguous). Always starts state='blocked' (fail-safe) with no decision yet — routine read-only decomposition and bounded fallback work never needs a gate. affected is a non-empty list of sprint_item_id strings and/or generic pointer objects ({source_type, targets:[...]}) naming exactly what this gate blocks. Resolve with resolve_proposal_gate once a human decides. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
add_sprint_item
waveforcegroupnotestitle*track
+16
ALWAYS call get_sprint_items first to check for existing pending items before adding. Append a todo item to the project's sprint checklist. Use when starting work on a new version… ALWAYS call get_sprint_items first to check for existing pending items before adding. Append a todo item to the project's sprint checklist. Use when starting work on a new version so the next session sees what's in flight. Optional: group items under a named objective with 'group'; attribute to a person with 'human_id'. Use 'depends_on' to block until another item finishes. Blocks near-duplicate titles (>=60% word overlap with an open pending/in_progress item) and returns the conflict; also warns (drift_warning) when the title looks already-shipped — 3+ keyword overlap with a migrations.py/_migrate_X or a recent commit; pass force=true to add anyway. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
add_sprint_item_pointer
labeltargets*project_idsource_type*project_namesprint_item_id*
[SUPPORT] 2976e168 — attach a GENERIC POINTER to a sprint item: a portable, composable reference to a thing-in-a-source, grounded in LSP Location + W3C Web Annotation Selector comp… [SUPPORT] 2976e168 — attach a GENERIC POINTER to a sprint item: a portable, composable reference to a thing-in-a-source, grounded in LSP Location + W3C Web Annotation Selector composition. targets is an ARRAY of {uri, selector, subSelector?} objects (native multi-file, the LSP WorkspaceEdit pattern); the whole composite shape is stored as JSON, not per-domain columns. Every selector is an object with an explicit "type" PLUS that type's own field(s): • range — {"type":"range", "start_line":int, "end_line":int, "start_char"?:int, "end_char"?:int} (an LSP Range); the pointer IS the location. • symbol — {"type":"symbol", "qualified_name":"pkg.mod.func"} resolved against the cached code graph to a file+line. • node_id — {"type":"node_id", "id":"<element-id>"} of a doc_store element (an ingested-document structure node). NOTE: the field is "id", NOT "value". • zotero_key — {"type":"zotero_key", "key":"<zotero-key>"} of a Zotero library item. • text_quote — {"type":"text_quote", "exact":str, "prefix"?:str, "suffix"?:str, "archived_url"?:str, "archived_at"?:str, "canonical_url"?:str, "retrieval_hash"?:str} (W3C TextQuoteSelector; source_type "web" — a URL — OR a local .docx path, resolving via a docx paragraph-text match instead of an HTTP GET). Resolving re-fetches live and flags content drift (the cited passage silently changed/vanished). • finding_id — {"type":"finding_id", "id":"<finding-note-id>"} (source_type "experiment") addresses a save_finding artifact. • directory — {"type":"directory", "root":str, "include"?:[str,...], "exclude"?:[str,...], "manifest_id"?:str, "snapshot_id"?:str} (62640241) — a directory ROOT + glob include/exclude selector + optional snapshot/manifest identity. Resolving it (local paths only by default) walks the tree and returns a deterministic manifest + manifest_hash. • git — {"type":"git", "repository":str, "ref"?:str, "commit"?:str, "path"?:str} (62640241) — a Git repository identity; at least one of "ref"/"commit" is required. A line range within "path" is expressed via subSelector (a nested range), NOT a new field. Resolving it (local clones only by default) checks reachability against the repo's current HEAD via `git rev-parse`. • remote_fs — {"type":"remote_fs", "host_id":str, "filesystem_slot":str, "path":str, "lease_id"?:str, "session_id"?:str, "snapshot_id"?:str} (62640241) — an opaque tunnel-connector host + filesystem slot + remote path, optionally bound to the lease/session that captured it. No core-local default resolver exists (requires an injected, tunnel-backed resolver) — reported explicitly unresolved without one, never silently dropped. • artifact — {"type":"artifact", "manifest_uri":str, "fingerprint"?:str, "run_id"?:str, "item_id"?:str, "provenance_id"?:str} (62640241) — a build/output artifact's manifest URI plus an optional fingerprint and a link to the producing run/sprint-item/provenance record. Resolving it (local files only by default) hashes the manifest file to report its current fingerprint. An optional selector.subSelector nests finer granularity (W3C hasSubSelector) — e.g. {"type":"symbol", "qualified_name":"a.b.f", "subSelector": {"type":"range", "start_line":3, "end_line":4}} = 'these lines, within this function'. A subSelector is itself a FULL selector and MUST carry its OWN explicit "type" (it does not inherit the parent's). source_type names the domain (code | docs | citation | web | experiment | …). Each target may also carry target_kind: "existing" | "planned_new" (300a063d) — set "existing" ONLY when the file/symbol already exists (this is checked against the real filesystem and REJECTED if the path isn't there); set "planned_new" for a file this sprint item will CREATE, which is explicitly exempt from that check. Omitting target_kind keeps the pre-existing, unchecked behavior (defaults to "existing" in the stored shape but is never filesystem-verified) — set it explicitly to get real verification. 62640241 — a target may ALSO carry an optional freshness proof: {"content_hash"?:str, "source_revision"?:str, "resolver_version"?:str, "captured_at"?:str, "state"?: "current"|"stale"|"unknown"|"unavailable"|"ambiguous"}. Purely additive/opt-in; resolve_sprint_item_pointers recomputes a LIVE freshness_state for directory/git/remote_fs/artifact/text_quote targets by comparing this declared proof against what resolution finds right now. Malformed pointers are rejected with a clear error: a bad/missing selector.type, a missing required selector field (e.g. node_id without "id", git without ref or commit, a subSelector with no "type", an invalid target_kind or freshness.state, or target_kind="existing" at a path that doesn't exist). Returns the stored pointer. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
add_sprint_note
body*title*note_kindsession_id*
[SUPPORT] Add an ephemeral note to the current session's scratch pad. Use for constraints, blockers, working assumptions valid only this session. Notes are auto-deleted when the se… [SUPPORT] Add an ephemeral note to the current session's scratch pad. Use for constraints, blockers, working assumptions valid only this session. Notes are auto-deleted when the session closes. Pass note_kind='thinking' for a thinking_sync (HOOKS_DEBUG_STATE) note: a structured snapshot of the reasoning state (what was tried, what failed, current confirmed state) that the dashboard renders with a distinct icon. Intended for Claude's client-side thinking_sync post-tool-call hook, which extracts the extended-thinking scratchpad and persists it here so debugging state survives across turns and into the next session brief. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
add_subtask
ownertitle*parent_id*project_idproject_name
[SUPPORT] Add a child sprint item under an existing parent item. Inherits the parent's version. Status starts as pending. Rejects if the parent is already done, failed, or skipped.… [SUPPORT] Add a child sprint item under an existing parent item. Inherits the parent's version. Status starts as pending. Rejects if the parent is already done, failed, or skipped. Pass owner='human' or owner='ai' to build a mixed-ownership task chain: owned subtasks added in sequence become a strict chain (each depends on the previous owned sibling), and completing one auto-advances ownership — an AI→human step files a HITL handoff, a human→AI step un-blocks the next AI subtask. The parent stays in_progress until all subtasks are terminal. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
add_workspace_note
body*tagstitle*
[MAINTENANCE] Add a workspace-level wiki note that applies across ALL projects in this workspace (onboarding, cross-cutting conventions, shared infra). Unlike add_note, it is not t… [MAINTENANCE] Add a workspace-level wiki note that applies across ALL projects in this workspace (onboarding, cross-cutting conventions, shared infra). Unlike add_note, it is not tied to a project and is injected at the top of every project's context block + handoff. Comma-separated tags optional. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
add_workspace_proposal
body*tagstitle*
Capture a workspace-level flash of insight into the 'drawer of inspiration' — cross-project ideas that don't belong to any one project yet. Unlike sprint items these are NOT execut… Capture a workspace-level flash of insight into the 'drawer of inspiration' — cross-project ideas that don't belong to any one project yet. Unlike sprint items these are NOT executor-claimable; they require a human to review and promote them. Proposals start at status='raw' and progress through an enforced lifecycle: raw → investigating → promoted|rejected. Use advance_proposal_status to move through the lifecycle; use promote_proposal to convert one into a real sprint item. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
add_workspace_sprint_item
grouptitle*human_id
[MAINTENANCE] Add an item to the workspace-level personal backlog — a cross-project board NOT tied to any single project (track thesis + Meridian + personal goals in one view). Use… [MAINTENANCE] Add an item to the workspace-level personal backlog — a cross-project board NOT tied to any single project (track thesis + Meridian + personal goals in one view). Use the per-project add_sprint_item for project work instead. 'group' is the cross-project bucket the item lives under (e.g. 'thesis', 'meridian', 'personal'); 'human_id' assigns it to a person. New items start as 'todo'. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
advance_proposal_status
status*proposal_id*
[SUPPORT] Transition a workspace proposal through its lifecycle. Enforced transitions: raw → investigating|rejected; investigating → promoted|rejected|raw; rejected → raw. 'promote… [SUPPORT] Transition a workspace proposal through its lifecycle. Enforced transitions: raw → investigating|rejected; investigating → promoted|rejected|raw; rejected → raw. 'promoted' is a terminal status reachable only via promote_proposal (which also creates the sprint item). Returns the updated proposal. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
analyze_model_efficiency
read-only
sizefilestitlefile_countdescriptiontouches_resources
[MAINTENANCE] 0fba4cb6 — MECHANICAL (zero-token) model-tier suggestion for a task or sprint item. Deterministic, rule/heuristic classifier: NO model call, NO DB, NO network — it mi… [MAINTENANCE] 0fba4cb6 — MECHANICAL (zero-token) model-tier suggestion for a task or sprint item. Deterministic, rule/heuristic classifier: NO model call, NO DB, NO network — it mirrors how the ultracode orchestration script spends zero model tokens on routing. Pass a task descriptor (any of title, description, file_count, files, touches_resources, size) and it returns a suggested tier: {tier: 'haiku'|'sonnet'|'opus', score, signals:[{signal, detail, weight}...], rationale, mode:'mechanical'}. Cheap-leaning signals (title keywords like 'typo'/'docstring'/'lint', 1 file, size 'xs'/'s') pull toward 'haiku'; expensive-leaning signals ('refactor'/'migration'/'auth', many files, touched resources, size 'l'/'xl') pull toward 'opus'. Use it to route a task to the cheapest sufficient model before spawning an executor. FOLLOW-UP (out of scope this pass): a second LLM-backed 'semantic' mode that reads the full item for a nuanced second opinion.
analyze_sprint
versionproject_idproject_name
[MAINTENANCE] PLANNING: Read-only synthesis of the current sprint into one structured brief — parallelizability (conflict-free groups + max fan-out), dependency chains (depends_on… [MAINTENANCE] PLANNING: Read-only synthesis of the current sprint into one structured brief — parallelizability (conflict-free groups + max fan-out), dependency chains (depends_on walked to the root), resource/file conflicts (items sharing touches_resources), and stalls (stall_count>0). Returns {summary, recommended_strategy, parallelism, dependency_chains, longest_chain, file_conflicts, stalls, blocked, running}. Call in planning sessions instead of stitching together get_parallelizable_groups + manual dependency/conflict analysis. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
annotate_outputs
note*path*run_paramsoutputs_dir*
[SUPPORT] 9e02e448 — capture a human annotation for a path inside an outputs tree WITHOUT touching the filesystem. Upserts a row into the annotations layer of the local DuckDB outp… [SUPPORT] 9e02e448 — capture a human annotation for a path inside an outputs tree WITHOUT touching the filesystem. Upserts a row into the annotations layer of the local DuckDB outputs index for outputs_dir. Two tiers, same mechanism: Tier 1 = pass outputs_dir as path to annotate the whole tree ('what this experiment tree is about'); Tier 2 = pass any sub-path (file or directory) to annotate a specific run, file, or subdirectory ('PCA on, BFS off, overwritten 5x'). run_params is an optional free-form dict of parameters logged alongside the note (e.g. {"lr": 0.001, "batch_size": 32}). Annotations are automatically surfaced in search_outputs results — any hit's path (or its nearest ancestor directory) that has an annotation will have it included in the hit's 'annotations' field without a second tool call. A MERIDIAN_NOTES.md file placed anywhere in the tree is also auto-ingested into the same table on every rebuild, keyed to its containing directory. Returns the stored annotation as a dict. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
answer_hitl
answer*request_id*answered_by
[SUPPORT] Answer a pending HITL request programmatically. Marks it answered so the waiting session can resume. Use list_hitl_requests to find request IDs. Persistent-state disclosu… [SUPPORT] Answer a pending HITL request programmatically. Marks it answered so the waiting session can resume. Use list_hitl_requests to find request IDs. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
archive_decision
can modify data
decision_id*
[SUPPORT] Archive a pinned decision by id. Soft-deletes to preserve the audit trail. Use when something was filed by mistake or is a duplicate. For retiring a valid but superseded… [SUPPORT] Archive a pinned decision by id. Soft-deletes to preserve the audit trail. Use when something was filed by mistake or is a duplicate. For retiring a valid but superseded decision, prefer update_decision(status=superseded). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
assign_sprint_waves
versionproject_idproject_name
[MAINTENANCE] 58a45b92 — PERSIST the parallel grouping: writes the conflict-free batches get_parallelizable_groups computes onto each eligible item's stored `wave` field (group i -… [MAINTENANCE] 58a45b92 — PERSIST the parallel grouping: writes the conflict-free batches get_parallelizable_groups computes onto each eligible item's stored `wave` field (group i -> 'wave-{i+1}'), so parallelism becomes deterministic and inspectable (get_sprint_items surfaces `wave`) instead of recomputed every call. Only currently-eligible items (pending/todo, dependency-satisfied, unclaimed, non-manual-blocker) are labelled; blocked/in-flight/done items are left untouched (re-run once they clear). Idempotent — recomputes from the live board each call. Hand-override any item afterwards with update_sprint_item(wave=...). Returns {version, wave_count, assigned, waves: {'wave-1': [ids...], ...}, blocked_count, undeclared_count}. 605ca2c4 — if active executor sessions are detected, the response also includes active_session_warning: re-labeling wave numbers while a session is mid-flight can desync it from a /goal string that already references specific wave labels. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
batch_mutate
mode*entries*project_idsession_idmax_entriesproject_name
+1
[SUPPORT] 133bfff6 — run a batch of TRANSACTIONAL mutation entries in ONE call, mixing entry kinds selected per-entry via 'kind': 'sprint_item_pointer' (attach a pointer — same sha… [SUPPORT] 133bfff6 — run a batch of TRANSACTIONAL mutation entries in ONE call, mixing entry kinds selected per-entry via 'kind': 'sprint_item_pointer' (attach a pointer — same shape as add_sprint_item_pointer: sprint_item_id, source_type, targets, optional label), 'sprint_item_update' (patch an EXISTING sprint item — same shape as update_sprint_item: item_id + at least one patchable field; sprint-item CREATION is not supported here, use execute_batch(operation='sprint_items', ...) or add_sprint_item for that), and (PROFILE-7) 'profile_layer' (upsert one scope_type+scope_id profile layer — same shape as set_profile_layer: scope_type, scope_id, optional fields/reset_fields/provenance/expected_revision; a stale expected_revision surfaces error_code='CONFLICT' with expected_revision/actual_revision in the outcome payload). Reuses the exact same validated apply/compensate logic execute_batch and the single-item tools already use — no separate/duplicated mutation path. mode is REQUIRED: 'all_or_nothing' validates every entry BEFORE mutating anything — any validation failure writes NOTHING (status 'rejected'); a mutation failure partway through rolls back every entry this call already wrote via a compensating delete/revert (status 'failed', per-entry status 'rolled_back'). 'best_effort' processes each entry independently (status 'ok' | 'partial' | 'failed'). idempotency_key is REQUIRED (pass null or "" to explicitly opt out) — a retried call with the identical (project_id, idempotency_key) tuple returns the FIRST call's stored result verbatim (idempotent_replay:true) instead of re-executing. PROJECT ISOLATION: an entry MAY carry its own 'project_id' field, but it MUST match this call's own project_id or the entry is rejected outright — a mutation entry can never target a different project. Returns {status, mode, project_id, idempotency_key, idempotent_replay, created_count, error_count, results:[{index, correlation_key, status, id, outcome, error_code, error_message, retryable}], request_id, committed_count, failures:[...failed results...], rollback_status: 'none'|'rolled_back'|'rejected'} — results is ALWAYS in input order. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
batch_read
read-only
requests*project_idmax_requestsproject_name
[SUPPORT] 133bfff6 — run a batch of DOMAIN-AWARE, CONCURRENT read requests in ONE call. Each request names an 'adapter' + 'operation' + 'args'; independent requests (no depends_on)… [SUPPORT] 133bfff6 — run a batch of DOMAIN-AWARE, CONCURRENT read requests in ONE call. Each request names an 'adapter' + 'operation' + 'args'; independent requests (no depends_on) execute concurrently via asyncio.gather — this is pure in-process dispatch, no subagents/worktrees involved. A request with 'depends_on' (a list of other requests' 'request_id's in this SAME batch) waits only for its own declared prerequisites, not the whole batch; if a prerequisite fails, the dependent resolves immediately with error_code='DEPENDENCY_FAILED' and is never executed. Two requests with the identical adapter+operation+normalized-args+depends_on-set COALESCE to one execution — duplicates come back with cache_hit=true and coalesced_with=<the request_id that actually ran>; pass a non-default cache_policy to opt a specific request out of coalescing. Adapters currently registered: 'sprint_board' with operations 'get_sprint_items' (args: status, show_blocked, include_human, version, include_manual_blocker, include_deferred — same meaning as the get_sprint_items tool) and 'get_sprint_item_pointers' (args: sprint_item_id — 404s if that item belongs to a different project); and 'profile' (PROFILE-7) with operations 'get_profile_layer' (args: scope_type, scope_id), 'list_profile_layers' (args: optional scope_type filter), 'get_effective_profile' (args: optional session_id, user_scope_id, workspace_scope_id — returns the merged, generation-keyed effective profile across all 5 layers), and 'get_profile_layer_revisions' (args: scope_id, optional limit). Returns {results: [{request_id, status, adapter, operation, result, error_code, error_message, elapsed_ms, cache_hit, coalesced_with}], elapsed_ms} — results is ALWAYS in input order. error_code is one of VALIDATION_ERROR, ADAPTER_NOT_FOUND, OPERATION_NOT_FOUND, DEPENDENCY_NOT_FOUND, DEPENDENCY_CYCLE, DEPENDENCY_FAILED, NOT_FOUND, TIMEOUT, INTERNAL_ERROR. This tool is READ-ONLY — for mutations use batch_mutate or execute_batch.
capture_research_finding
url*summary*project_idproject_namerelated_decision_id
[SUPPORT] Inline capture for web/paper research during planning: save a finding from a URL as an addressable note with the source link, optionally linked to a decision. A research-… [SUPPORT] Inline capture for web/paper research during planning: save a finding from a URL as an addressable note with the source link, optionally linked to a decision. A research-shaped wrapper over save_finding — arXiv URLs are tagged source_type=arxiv automatically, everything else as web. Turns web-search results into durable Meridian artifacts instead of evaporating. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
checkpoint
versionproject_idsession_id*project_name
[SUPPORT] Save progress mid-session. Runs auto_capture (buckets done tasks into a note), generates a delta handoff, and returns a compact summary with what was done, what's pending… [SUPPORT] Save progress mid-session. Runs auto_capture (buckets done tasks into a note), generates a delta handoff, and returns a compact summary with what was done, what's pending, and the suggested next /goal string (now the same canonical, token-embedded continuation block generate_handoff renders — verify it with verify_handoff_token exactly like any other /goal block). Call before context fills up or before ending a session. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
claim_docx_region
file_path*element_id*session_id*
[MAINTENANCE] f7ee1ba7 — Model B scoped-region claiming for .docx files. Claim a specific paragraph/element by its durable `element_id` (the w14:paraId surfaced by get_document_str… [MAINTENANCE] f7ee1ba7 — Model B scoped-region claiming for .docx files. Claim a specific paragraph/element by its durable `element_id` (the w14:paraId surfaced by get_document_structure / update_paragraph) so another session cannot overwrite it concurrently. Two sessions can hold NON-OVERLAPPING element claims on the SAME file — the real precision benefit vs. a whole-file lock. An edit to a claimed element_id by another session is REJECTED structurally (not just advisory) at the update_paragraph level. A whole-file lock by another session blocks this claim. Returns {claimed: true, file_path, session_id, element_id} on success or {claimed: false, reason, message, conflicts} on conflict. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
claim_file
modesymbolcontentitem_idfile_path*session_id*
[SUPPORT] Claim edit rights on a file for this session. Whole-file by default (auto-expires after 2 hours). For symbol-level claims — so two sessions can edit the same file if they… [SUPPORT] Claim edit rights on a file for this session. Whole-file by default (auto-expires after 2 hours). For symbol-level claims — so two sessions can edit the same file if they own different classes/functions — also pass `symbol` (e.g. 'AuthRouter' or 'AuthRouter.login') AND `content` (the file's full source). Meridian parses the source (stdlib ast for Python, tree-sitter for JS/TS/C/C++/Go/Rust/Java/C#), and hard-blocks if another live session already owns an overlapping line range — the block lists which symbols are still safe to claim. Unparseable content falls back to a whole-file lock. The response includes a `code_notes` list of code-anchored project notes (kind='code') for this file/symbol — read them before editing. Pass `item_id` (the sprint item you're claiming this file/symbol for) whenever you know it — it disambiguates the touches_resources amendment side-effect (c027922d) when your session holds more than one sprint item in_progress at once. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
claim_sprint_item
actoritem_id*project_idsession_idproject_nameresource_contents
+2
Claim a pending sprint item: sets status to in_progress and records claimed_at + actor. Read-only: false. Rejects if the item is already in_progress, done, failed, skipped, its tou… Claim a pending sprint item: sets status to in_progress and records claimed_at + actor. Read-only: false. Rejects if the item is already in_progress, done, failed, skipped, its touches_files overlap active file claims from another live session, or (18c488b6) a touches_resources file:/symbol: entry is locked by another live session — this last check ACQUIRES the resource lock (via claim_file/claim_symbol) as part of claiming, is a hard block regardless of worktree isolation, and rolls back cleanly if the claim itself doesn't land. 54c488b6/54d2c2af: every symbol:/file: resource this acquires also gets a durable lock-granularity receipt (achieved symbol vs. coarse-fallback grain, and why), auditable after the fact independent of this call's response payload. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
clear_capability_profile
scope_id*scope_type*
[SUPPORT] 02038afe — Delete a scope's ENTIRE capability profile row (both its capabilities and its disabled_capability_ids) so it reverts to purely inheriting from less specific la… [SUPPORT] 02038afe — Delete a scope's ENTIRE capability profile row (both its capabilities and its disabled_capability_ids) so it reverts to purely inheriting from less specific layers. Distinct from disabling individual capability ids via set_capability_profile's disabled_capability_ids — this clears the whole layer. Idempotent: clearing an already-empty or never-set scope is a no-op, not an error. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
clone_profile_layer
actorsource_scope_id*target_scope_id*source_scope_type*target_scope_type*
[SUPPORT] 0bec79a7 (PROFILE-5) — Copy one layer's fields/reset_fields/provenance onto another scope, going through the exact same validation/hashing path as save_profile_layer (not… [SUPPORT] 0bec79a7 (PROFILE-5) — Copy one layer's fields/reset_fields/provenance onto another scope, going through the exact same validation/hashing path as save_profile_layer (not a raw copy) — the target scope's allowed_layers may differ from the source's, so a field the source layer legally carries can still be rejected at the target. Rejects with {error} when the source layer does not exist (revision=0 — cloning nothing is a caller error, not a silent no-op). Cloning INTO a hosted_default target never carries over the source's lifecycle_state — a fresh clone always lands in 'draft', exactly like any other first-ever write on a hosted_default scope; use activate_profile_layer afterward to publish it. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
commit_proposal_promotion
actordepth*pointersproject_idsession_idproposal_id*
+8
[SUPPORT] Commit a proposal's promotion through 'depth' (ce4883f3), cumulative over every shallower depth. Requires 'preview_hash' from a just-called preview_proposal_promotion wit… [SUPPORT] Commit a proposal's promotion through 'depth' (ce4883f3), cumulative over every shallower depth. Requires 'preview_hash' from a just-called preview_proposal_promotion with the SAME arguments — a mismatch (proposal or target project's board changed since) is rejected rather than silently committed against stale information, and nothing is written. Committing an already-satisfied depth is an idempotent no-op success (matches the preview's already_satisfied=true case). A genuine lost race against a concurrent caller (caught by the underlying race-safe functions) is reported honestly as a failure with a 'deviation_auto_resolved' audit trail — never silently retried or swallowed. When the promoted sprint item's resources or the proposal's own text match one of 3 narrow deviation heuristics (production_deployment / tenant_security_boundary / destructive_behavior), this files a durable HITL via request_hitl and returns hitl_pending=true WITHOUT completing remaining steps — pass a non-empty 'override_reason' to acknowledge and proceed anyway (audited). 'investigation_findings' and 'pointers' are recorded via append_proposal_update at the matching depth; 'pointers' entries are validated via meridian.pointers.validate_pointer (each needs source_type + a non-empty targets array of {uri, selector, target_kind?}). depth='executable_handoff' calls generate_handoff(selected_item_ids=[the new/reused sprint item id]) — scoped to exactly that item's dependency closure, with project/version/session identity. Returns {proposal_id, project_id, depth, already_satisfied, committed, deviation, hitl_pending, hitl_request_id}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
complete_sprint_item
actornotesitem_id*task_idproject_idsession_id
+9
Mark a sprint item done. Pass task_id to link the task that shipped it. Pass session_id to get a board_change field (items injected mid-run) and an active-worktree merge reminder i… Mark a sprint item done. Pass task_id to link the task that shipped it. Pass session_id to get a board_change field (items injected mid-run) and an active-worktree merge reminder in the response. If the item is flagged required_notes, you MUST pass notes= (evidence: what shipped / how verified) or a task_id, or completion is refused (EVIDENCE_REQUIRED). If the item is flagged require_verification (e2e1b682), completion is refused (VERIFICATION_REQUIRED) unless an independent PASS is on file: pass verifier_session_id (a DIFFERENT session id from actor — a fresh, no-memory subsession that inspected the change with read-only tools) and verification_verdict='pass' to file and check the verdict in this same call. fdaa5b55 — if the item has a linked GitHub issue, the response carries a github_issue_action field: issues Meridian itself created (github_issue_source='meridian_auto') are commented on and auto-closed; any other issue (manual/legacy) only gets a proposed-closure comment plus a non-blocking HITL for human review — never auto-closed. 8693b6a8 — claim-ownership gate: if the item is claimed by a DIFFERENT actor than the one completing it, completion is refused (CLAIM_MISMATCH) UNLESS that claim is stale (claimed 2h+ ago, or the claiming session is dead/closed) — the exact stale-cleanup pattern of closing items left behind by a dead session keeps working automatically. For a live, non-stale foreign claim, pass force_foreign_claim=true to explicitly acknowledge and complete anyway. 5fe3502e — pass strict_evidence=true (or flag the item require_strict_evidence=true via update_sprint_item) for STRICT, fail-closed evidence verification: completion is refused (STRICT_EVIDENCE_BLOCKED, with typed evidence_errors codes — EVIDENCE_ABSENT/EVIDENCE_INVALID/EVIDENCE_STALE/WRONG_WORKTREE/UNCLAIMED_EDIT) unless evidence is present, verifiable, fresh, from the right worktree, and every modified file was claimed. Default (no strict_evidence, no require_strict_evidence) behavior is exactly the pre-existing advisory-only evidence checks — nothing changes unless you opt in. a8c0f3b7 — CODE-INTEL PROSPECTING RECEIPT gate: opt in at the PROJECT level via set_capability_manifest(capabilities=[{id:'code_intel_prospecting', ...}]) — no per-call flag needed, and a no-op for projects that never declared it. When declared, completion of an item that has touches_resources and no prospect_bypass is refused (CODE_INTEL_RECEIPT_MISSING) unless a durable receipt shows a real search_graph/find_symbol/prospect_symbol call happened since the item was claimed (see meridian.code_intel_receipt) — or refused (CODE_INTEL_UNAVAILABLE) when the capability is availability_policy='required' and code-intel itself is unavailable. Pass override_code_intel_receipt=true with a non-empty override_reason to acknowledge and complete anyway (audited). 'optional'/'degraded_ok' policies never block — they degrade with a code_intel_receipt_warning on the returned item instead. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
complete_wave_gate
actorversionproject_idsession_idwave_label*project_name
+1
[SUPPORT] d2430713 — EXECUTOR GATE: call this AFTER you have actually run a wave's gate action list (push, deploy, wait, run_verification) to unblock the next wave's sprint items.… [SUPPORT] d2430713 — EXECUTOR GATE: call this AFTER you have actually run a wave's gate action list (push, deploy, wait, run_verification) to unblock the next wave's sprint items. You MUST pass the REAL structured result from run_verification as verification_payload — the server validates it (status=='ok', exit_code==0). A self-report ('I think it passed') or a fabricated payload is rejected with a clear error. On success, writes a wave_gate_results row and returns {gate_completed, wave_label, next_wave_label, next_wave_item_count, next_wave_item_ids, gate_id}. Each wave gate may only be completed once (duplicate calls return an error). Security note: this is a deploy-adjacent gate — only actual run_verification output satisfies it. ed8e4524 — SCOPED TO SPRINT VERSION: pass version (or session_id to auto-resolve the calling session's scope) so two different sprint versions that happen to share the SAME wave_label (e.g. both have a 'wave-2') never satisfy or unblock each other's gate — omit both to keep the exact prior project-wide behavior for a single-version project. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
complete_workspace_sprint_item
item_id*
[MAINTENANCE] Mark a workspace personal-backlog item done (stamps completed_at). Returns the updated item. Persistent-state disclosure: on hosted Meridian, supplied text and projec… [MAINTENANCE] Mark a workspace personal-backlog item done (stamps completed_at). Returns the updated item. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
configure_wave_gate
actoractions*versionwave_end*project_idsession_id
+2
[SUPPORT] 74a8f420 — PLANNING: configure (or on-the-fly reconfigure) a deterministic action pipeline attached to a wave or wave-range, ENFORCED STRUCTURALLY — not just advisory /go… [SUPPORT] 74a8f420 — PLANNING: configure (or on-the-fly reconfigure) a deterministic action pipeline attached to a wave or wave-range, ENFORCED STRUCTURALLY — not just advisory /goal prose. Once set, claim_sprint_item refuses (WAVE_GATE_PENDING) to claim any item whose wave sorts beyond wave_end until complete_wave_gate records real run_verification evidence for that boundary. actions is an ordered, non-empty list of {"type": ...} dicts — type must be one of push_dev | push_main | deploy | wait | run_verification (push_dev/push_main/deploy are run by the executor via trigger_workflow; run_verification maps onto the run_verification tool whose output complete_wave_gate requires as evidence; wait is a plain pause step; extra keys per action, e.g. {"type": "wait", "seconds": 30}, are preserved verbatim). wave_start (defaults to wave_end) documents a multi-wave range covered by one gate checkpoint. Re-configuring an un-passed wave_end is an upsert — the pipeline can be revised right up until an executor completes it; once passed the config is immutable (returns {"error": ...}). Returns {configured, gate_config_id, project_id, wave_start, wave_end, actions} on success. ed8e4524 — SCOPED TO SPRINT VERSION: pass version (or session_id to auto-resolve the calling session's scope) so two different sprint versions that happen to share the SAME wave_end label never reconfigure or immutably block each other's gate — omit both to keep the exact prior project-wide behavior for a single-version project. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
create_project
name*execution_modeparent_project_id
[MAINTENANCE] Create a new Meridian project. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decis… [MAINTENANCE] Create a new Meridian project. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
delete_custom_hook
can modify data
hook_id*project_idproject_name
[MAINTENANCE] 273287cb — delete a user-defined hook by id (the id returned by add_custom_hook / get_custom_hooks). Idempotent: deleting an already-gone hook returns {deleted:false}… [MAINTENANCE] 273287cb — delete a user-defined hook by id (the id returned by add_custom_hook / get_custom_hooks). Idempotent: deleting an already-gone hook returns {deleted:false} rather than erroring, matching delete_sprint_item_pointer's convention. Does NOT remove any already-written .claude/hooks/<slug>.* files — those are simply no longer refreshed on the next generate_handoff. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
delete_note
can modify data
note_id*
[MAINTENANCE] Hard-delete a project note by id. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned de… [MAINTENANCE] Hard-delete a project note by id. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
delete_sprint_item_pointer
can modify data
pointer_id*
[MAINTENANCE] 2976e168 — delete ONE generic pointer from a sprint item by its pointer id (the id returned by add_sprint_item_pointer / get_sprint_item_pointers). A stored pointer i… [MAINTENANCE] 2976e168 — delete ONE generic pointer from a sprint item by its pointer id (the id returned by add_sprint_item_pointer / get_sprint_item_pointers). A stored pointer is immutable, so 'editing' one is delete-then-re-add. Idempotent: returns {pointer_id, deleted:false} when no pointer had that id, rather than erroring. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
dismiss_hitl
can modify data
request_id*
[SUPPORT] Dismiss a HITL request (won't-answer / no longer relevant). Stays in audit trail. Use list_hitl_requests to find request IDs. Persistent-state disclosure: on hosted Merid… [SUPPORT] Dismiss a HITL request (won't-answer / no longer relevant). Stays in audit trail. Use list_hitl_requests to find request IDs. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
execute_batch
mode*entries*operation*project_idsession_idmax_entries
+2
[SUPPORT] 627187b8 — run a HOMOGENEOUS batch of management writes (all entries the SAME operation) with real atomic-or-independent semantics. Every entry in ``entries`` is validate… [SUPPORT] 627187b8 — run a HOMOGENEOUS batch of management writes (all entries the SAME operation) with real atomic-or-independent semantics. Every entry in ``entries`` is validated and reported individually — no guessing whether a partial write happened. operation selects the entry shape: • sprint_items — create new sprint items. Each entry needs a non-empty 'title' plus any add_sprint_item kwarg (version, group, human_id, depends_on, priority, touches_resources, ...). Every entry's own 'action' (if present) must be 'create'. • item_updates — patch existing sprint items. Each entry needs a non-empty 'item_id' plus at least one patch_sprint_item field to change (title, status, notes, priority, ...). Every entry's own 'action' (if present) must be 'update'. • pointers — attach generic pointers (see add_sprint_item_pointer). Each entry needs 'sprint_item_id', 'source_type', 'targets' (+ optional 'label'). • notes — file sprint notes (see add_sprint_note). Each entry needs 'title' and 'body' (+ optional 'session_id' — falls back to this call's own top-level session_id when omitted — and 'note_kind'). Any entry MAY carry a 'correlation_key' (any non-empty string) echoed back on its result for reconciliation; every result also carries its 0-based input 'index' regardless. mode is REQUIRED and controls failure semantics: 'all_or_nothing' validates every entry BEFORE mutating anything — if any entry fails validation, NOTHING is written (status 'rejected'); if a mutation fails partway through, every entry this call already wrote is rolled back via a compensating delete/revert (status 'failed'). 'best_effort' processes each entry independently — one entry's failure never blocks the others (status 'ok' | 'partial' | 'failed' depending on how many succeeded). idempotency_key is REQUIRED (pass null or "" to explicitly opt out of idempotency protection for this call) — a retried call with the identical (project_id, operation, idempotency_key) tuple returns the FIRST call's stored result verbatim (idempotent_replay:true) instead of re-executing, making retries safe even for all_or_nothing batches that already wrote and rolled back once. Returns {status, mode, entry_kind, operation, project_id, idempotency_key, idempotent_replay, created_count, error_count, results:[{index, correlation_key, status, id, outcome, error_code, error_message, retryable}]} — results is ALWAYS in input order regardless of processing order. Each result status is 'ok' (mutated), 'error' (validation or mutation failure — see error_code/error_message/retryable), 'rolled_back' (succeeded, then undone by a later all_or_nothing failure), or 'not_attempted' (never reached because an earlier entry aborted the batch). max_entries caps this call (default 100); exceeding it is rejected before anything is attempted. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
export_ai_log
read-only
limitevent_typeproject_idsession_idproject_namecorrelation_id
+1
[MAINTENANCE] c0168425 — Read-only: project-scoped, receipted export of ai_log_events (meridian.db.ai_log — the append-only ExecutionEvent log). Nothing captures events into this t… [MAINTENANCE] c0168425 — Read-only: project-scoped, receipted export of ai_log_events (meridian.db.ai_log — the append-only ExecutionEvent log). Nothing captures events into this table automatically yet (see meridian.ai_log's module docstring); this exports whatever has been recorded via append_event so far. Filter with session_id/event_type/correlation_id/parent_event_id exactly like list_events. limit defaults to 5000 and is capped at 5000 — the response's truncated field is true when more matching rows exist than were returned. Returns {project_id, exported_at, filters, event_count, truncated, events, export_hash} — export_hash is a sha256 over the exported events so a caller can independently verify nothing was altered in transit.
export_ai_log_artifacts
read-only
project_idproject_namecontent_hashes
[MAINTENANCE] c0168425 — Read-only: project-scoped, receipted export of stored ai_log artifacts (meridian.artifact_store — the local-first, content-addressed blob store an Executio… [MAINTENANCE] c0168425 — Read-only: project-scoped, receipted export of stored ai_log artifacts (meridian.artifact_store — the local-first, content-addressed blob store an ExecutionEvent payload can point to via artifact_ref instead of inlining large content). Pass content_hashes to export an explicit subset (sha256:... values) — every requested hash must exist for this project, or the call errors rather than silently returning a shorter list; omit it to export every artifact currently stored for the project. Returns {project_id, exported_at, artifact_count, total_size, artifacts, export_hash} — each artifact entry includes its metadata plus base64-encoded content. export_hash covers the metadata only (not the base64 payloads) so it stays cheap to verify.
fan_out_sprint_items
modeitems*strictproject_idproject_nameidempotency_key
[SUPPORT] Bulk-insert sprint items from a single orchestrator call — decompose a goal into parallel work items without N sequential add_sprint_item calls. Pass a list of {title, de… [SUPPORT] Bulk-insert sprint items from a single orchestrator call — decompose a goal into parallel work items without N sequential add_sprint_item calls. Pass a list of {title, description?, group?, version?} dicts; returns the list of new item_ids in insertion order. By DEFAULT (strict omitted/false) no duplicate guard is applied (the caller is assumed to have deduped) and titles that resolve to an empty string are silently skipped — unchanged, original behavior, kept for compatibility. 468ab67d — pass strict=true to opt into the SAME shared engine execute_batch uses (meridian.db.batch_management, add_sprint_item-backed): the 60%-word-overlap duplicate guard applies (per-item force:true still overrides it), idempotency_key makes a retried call with the same key replay the first call's result instead of re-inserting, and mode picks all_or_nothing (validate-then-insert with compensating rollback on failure, default) or best_effort (each item processed independently). In strict mode the response is the execute_batch response shape ({status, mode, entry_kind, project_id, idempotency_key, idempotent_replay, created_count, error_count, results:[{index, correlation_key, status, id, outcome, error_code, error_message, retryable}]}) PLUS the usual item_ids/count keys — a different, richer shape than the legacy bare item_ids/count, by design (a new opt-in contract, not a silent change to the old one). Each item may carry its own correlation_key (echoed back on its strict-mode result) and force (per-item duplicate-guard override, strict mode only). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
finalize_wave_run
actorevidencewave_run_id*expected_revision_hash
[SUPPORT] 2a654cb0 — IDEMPOTENT FINALIZATION: close a wave run opened by start_wave_run. Safe to retry: if the run is already merged this returns the ORIGINAL result with already_f… [SUPPORT] 2a654cb0 — IDEMPOTENT FINALIZATION: close a wave run opened by start_wave_run. Safe to retry: if the run is already merged this returns the ORIGINAL result with already_finalized=true, writes no row and appends no event (event_count is identical across the retry — that is the observable proof). Fails CLOSED in three cases: (1) a failure_mode='stop' child has failed — returns {finalized: false, blocked_by: [...]} naming the items; (2) expected_revision_hash does not match the board the run was planned against — you are holding a stale manifest, re-read the board first; (3) evidence is not a genuine run_verification result (status='ok', exit_code=0) — the SAME evidence contract complete_wave_gate enforces; a self-report is rejected. Returns {finalized, already_finalized, wave_run_id, status, finalized_at, finalizer_evidence, children_summary, event_count}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
find_outputs_by_source
read-only
limitoutputs_dir*source_path*
[SUPPORT] 2ae25966 — READ-ONLY reverse provenance lookup over a run's OUTPUTS tree: the mirror image of resolve_figure_output's forward direction (figure -> source). Given a script… [SUPPORT] 2ae25966 — READ-ONLY reverse provenance lookup over a run's OUTPUTS tree: the mirror image of resolve_figure_output's forward direction (figure -> source). Given a script or data file's source_path, scans the same local DuckDB outputs index search_outputs/annotate_outputs use for every indexed output whose recorded generating_script traces back to it — an exact (case/slash-insensitive) string match OR a basename match, so 'analysis/run.py' also matches an output recorded with generating_script='run.py'. This is the direction plain exact-path resolution can never answer, because that always starts from the output side: 'what did this script/data file produce?' — useful for auditing a stale Outputs_*_BACKUP folder mess by walking a source file's outputs forward, newest first, and comparing against what a document actually cites. Returns {outputs_dir, source_path, outputs:[{path, generating_script, is_archival, canonical_path, sha256, kind, size, mtime, csv_columns, json_keys}], total} sorted newest-first by mtime; total is the full match count before limit truncation. outputs is empty (not an error) when nothing in the tree cites this source, or when outputs_dir doesn't exist.
find_similar_equation
read-only
doc*latex*limitproject_idproject_name
[MAINTENANCE] 06df6ab3 — fuzzy-match a LaTeX string against every equation already indexed (via index_equation) for one stored document, best match first. Each result carries the s… [MAINTENANCE] 06df6ab3 — fuzzy-match a LaTeX string against every equation already indexed (via index_equation) for one stored document, best match first. Each result carries the stored equation row PLUS a difflib similarity score (0..1) against its latex_normalized. Useful before index_equation to check whether an equation is already present under a slightly different LaTeX spelling. Returns {document_id, matches:[...]} — an empty list (never an error) when the document has no stored equations, or doc doesn't resolve to a stored document.
find_similar_figure
read-only
doc*limitproject_idoutputs_dirproject_namedescription_or_path*
[MAINTENANCE] c623e648 — fuzzy-match a free-text description OR a file path against every figure already indexed (index_figure) for one stored document, best match first. Each resu… [MAINTENANCE] c623e648 — fuzzy-match a free-text description OR a file path against every figure already indexed (index_figure) for one stored document, best match first. Each result carries the stored figure row PLUS a difflib similarity score (0..1) — the better of the match against its normalized_caption and against its file_path. Useful before index_figure to check whether a figure is already present under a slightly different caption or path. Returns {document_id, matches:[...]} — an empty list (never an error) when the document has no indexed figures, or doc doesn't resolve to a stored document. d2a3537a — pass outputs_dir to RESOLVE THROUGH to the outputs index: every matched figure with a file_path that names an already-indexed run output gains a linked_output field (the output's path, generating_script, canonical/archival flag, fingerprint), so 'does this plot already exist as a run output?' and 'where is it referenced in my thesis?' are one lookup (linked_output is null when the figure names no indexed output).
find_similar_table
read-only
doc*limitproject_iddescription*project_name
[MAINTENANCE] 2622182d — fuzzy-match a free-text description against every table already indexed (index_table) for one stored document, best match first. Each result carries the st… [MAINTENANCE] 2622182d — fuzzy-match a free-text description against every table already indexed (index_table) for one stored document, best match first. Each result carries the stored table row PLUS a difflib similarity score (0..1) against its normalized_caption. Useful before index_table to check whether a table is already present under a slightly different caption. Returns {document_id, matches:[...]} — an empty list (never an error) when the document has no indexed tables, or doc doesn't resolve to a stored document.
find_symbol_usages
read-only
doc*project_idproject_namesymbol_or_equation_id*
[MAINTENANCE] 9605edb0 — READ-ONLY cross-reference tracking: given a document and EITHER a doc_equations row id OR a symbol / normalized-LaTeX string, resolve it to ONE target norm… [MAINTENANCE] 9605edb0 — READ-ONLY cross-reference tracking: given a document and EITHER a doc_equations row id OR a symbol / normalized-LaTeX string, resolve it to ONE target normalized-LaTeX (an equation id uses that row's stored latex_normalized as-is; a raw string is normalized with the SAME normalize_latex that produced every stored latex_normalized) and return every place that target reappears in the document — matching equations (exact normalized-latex equality) AND paragraphs whose text textually contains the symbol. Each hit carries element_id, document_id, ordinal, matched_text, context (equation|paragraph) and an is_definition/is_reuse flag: the EARLIEST occurrence by ordinal is the definition, later ones are reuse — so a later mention can be checked to point back to the definition instead of assuming the reader remembers it. Hits are ordered by ordinal (definition first). Returns {document_id, target, resolved_from, hits:[...]} — an empty hits list (never an error) when nothing matches, or doc doesn't resolve to a stored document.
generate_handoff
read-only
modeversionroot_dircheckpointproject_idsession_id
+8
EXECUTOR SESSIONS: MANDATORY - call at end of every session before disconnect. Never write markdown manually. Read-only: Generate a context handoff. mode='full' writes the complete… EXECUTOR SESSIONS: MANDATORY - call at end of every session before disconnect. Never write markdown manually. Read-only: Generate a context handoff. mode='full' writes the complete L0/L1/L2 handoff; mode='delta' returns a compact session update (completed + pending + /goal); mode='starter' returns a <=20-line block for paste-after-/compact or cold start - project_id, start_session command, last 5 completed titles, top 3 pending IDs, /goal; mode='planner' returns strategic context for a claude.ai planning chat; mode='goal' (682005f4) returns ONLY the bare /goal block itself - no readiness header, no workspace decisions/notes, no L0/L1/L2 context - with each pending item's resolved code pointer(s), if any, rendered inline in <sprint_items>. FORWARD THE RETURNED content FIELD VERBATIM to the user (a5e8aa74) - the server delivers content as the EXACT raw handoff text, with NO Markdown code fence, header, or blockquote added around it (earlier versions wrapped it in a 4-backtick fence under 5234877f; that wrapping was removed because it broke copy-paste fidelity for the /goal trust protocol - see format_handoff_mcp_content in meridian/handoff.py). Output the field value as-is, as the sole plain-text bubble - do NOT add your own fence, header, blockquote, or any other wrapping on the calling side either. Do NOT just narrate that the handoff succeeded; paste the actual text. Also returns capability_contract (98aaccf4) on every mode: a machine-readable {requested, effective, availability, manifest_hash, executable, executable_reasons, generated_at} object describing the project's declared capabilities and whether an executor can run right now — null if contract-building failed. Every executor-facing /goal payload also includes an explicit <executor_item_ids> manifest containing every claimable item ID in deterministic order; receivers must use that manifest rather than parsing presentation prose or a truncated starter preview. Also returns scope (b8f89491) on every mode: {requested_version, effective_version, session_id} — which sprint-version bucket the handoff actually resolved to (explicit version arg wins over the session's own stored sprint_version; both null means genuinely unscoped, every version). Every mode's /goal text (full/delta/starter/goal, embedded in content or returned bare) also carries a structured <execution_policy execution_mode=... max_planning_turns=... required_first_action=... no_confirmation=... permitted_parallel_wave=... claim_before_edit=...> tag (75ac1c8e) right after <executor_directive> — the SAME canonical policy start_session's execution_policy field returns, so a receiver can identify the required first action from the tag attributes without interpreting prose. Also returns handoff_evidence_status (8a883f60) on every mode: an explicit {code_pointer_enrichment, resolved_pointer_annotation, freshness_requery, wave_gate_exclusion, graph_search_availability} object — each a {status: verified|skipped|failed|degraded, reason, fallback} entry for that best-effort step, so a silently-degraded handoff is never indistinguishable from a fully-verified one. Pass strict_evidence=true to fail CLOSED instead: if any capability comes back failed/degraded, nothing is rendered or persisted and the call returns {error: HANDOFF_EVIDENCE_BLOCKED, evidence_status, evidence_errors, message} — default (strict_evidence omitted/false) behavior is completely unchanged. Also returns continuation_status (ecc8b280) for full/delta modes: a {continuation_required, terminal_ready, execution_mode, actionable_count, actionable_pending_count, actionable_in_progress_count, actionable_item_ids, blocked_count, blocked_item_ids, reason} object reporting whether actionable pending/in_progress work remains on the live, version-scoped board with no recorded blocker_kind, while execution_mode=autonomous — the machine-readable signal that an autonomous session may NOT yet treat itself as finished. Pass checkpoint=true when THIS call is a mid-run progress report, not a final session-ending handoff — a checkpoint is never blocked by the gate below. Pass strict_continuation=true to fail CLOSED instead of just reporting: if continuation_required is true and checkpoint is not set, nothing is rendered or persisted and the call returns {error: HANDOFF_CONTINUATION_BLOCKED, continuation_status, message} — resolve/claim the remaining item(s), record a genuine blocker_kind on them, or call again with checkpoint=true. Default (strict_continuation omitted/false) behavior never blocks — continuation_status is still always returned so a caller can act on it voluntarily. Also supports selected_item_ids (cffb9323) — an explicit INCLUDE-ONLY item scope for safe parallel-follow-up handoffs. force_include_ids only ever WIDENS the pending list (re-adds specific deferred ids); selected_item_ids NARROWS it: when given, generate_handoff resolves a dependency-closed scope (the requested ids plus any transitively-required depends_on ancestor still todo/pending) and applies it identically across every executable mode (full/delta/starter/goal), so an isolated two-item follow-up handoff never emits the rest of the eligible version backlog or overlaps an active wave/batch a sibling session already owns. The rendered /goal carries a <selected_item_scope requested=... closure=... closure_hash=...> tag stating the exact selected ids and the wave plan — embedded in the body BEFORE the provenance token is minted, so the selection is bound into the SAME body-hash/token-integrity mechanism (efaa918a) as the rest of the /goal block. Fails CLOSED, not silently widened: a missing/foreign/wrong-version/already-in_progress/otherwise-non-pending requested id raises a structured refusal (error=HANDOFF_SELECTION_BLOCKED, selection_rejected) — nothing is rendered or persisted for that call. (7a373f41) A selection that validates cleanly but collapses to zero executable items once the manual/backburner/unprospected/wave-gate exclusion filters run instead refuses with error=HANDOFF_SCOPE_NON_EXECUTABLE, requested_ids, and an excluded_requested reason list — this same contract is identical across every connector surface (hosted HTTP MCP, stdio, and the REST /handoff route). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
get_agent_instructions
read-only
project_idproject_name
[MAINTENANCE] Read-only: Return the custom agent_instructions for a project. These are injected automatically by start_session so every session picks them up. Use this when you nee… [MAINTENANCE] Read-only: Return the custom agent_instructions for a project. These are injected automatically by start_session so every session picks them up. Use this when you need to read or display the current instructions.
get_blog_posts
read-only
status
[MAINTENANCE] Read-only: List workspace-scoped blog posts, newest first. Optional 'status' filter (draft|published|archived). Each post includes a 'url' (/blog/<slug>). [MAINTENANCE] Read-only: List workspace-scoped blog posts, newest first. Optional 'status' filter (draft|published|archived). Each post includes a 'url' (/blog/<slug>).
get_capability_manifest
project_idproject_name
[SUPPORT] 649e095f — Read-only: return a project's structured capability manifest (id/purpose/required_tools/fallback_chain/provenance/availability_policy/verification_command per… [SUPPORT] 649e095f — Read-only: return a project's structured capability manifest (id/purpose/required_tools/fallback_chain/provenance/availability_policy/verification_command per capability), plus its schema version and a stable content hash for change detection. A project that has never set one gets an empty manifest back, never an error — old projects continue unaffected. Foundation-only: this is the raw declared manifest, not yet resolved against live tool/tunnel availability or profile inheritance. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
get_citation_edges
read-only
sourceproject_iddocument_idproject_name
[MAINTENANCE] fefb596a — read the CITATION GRAPH of a project's ingested documents. Returns every in-text citation marker (a kind='citation' element parsed from an ingested .tex/.d… [MAINTENANCE] fefb596a — read the CITATION GRAPH of a project's ingested documents. Returns every in-text citation marker (a kind='citation' element parsed from an ingested .tex/.docx) together with its resolved edges: • bibentry edges — the intra-document link from a \cite{key} marker to a matching \bibitem/bibliography entry in the SAME document (materialised automatically on ingest). • zotero_item edges — the cross-document link from a marker to a canonical Zotero library item, keyed on DOI (materialised by the opt-in resolve_citations pass); target_document_id is set when the cited paper is itself ingested in this project. Each marker carries {element_id, document_id, ordinal, ref, text, edges:[{edge_kind, target_kind, target_ref, target_element_id, target_document_id, resolved_at}]}. Scope to one document with source (a stored source path/URL) or document_id; omit both for the whole project. Returns an empty markers list (never an error) when no document structure has been persisted yet.
get_connection_log
read-only
limitsince
[MAINTENANCE] Read-only: Return the recent /mcp connection-event log for this tenant (newest first, up to 200 entries). Every HTTP /mcp request Meridian receives is recorded: times… [MAINTENANCE] Read-only: Return the recent /mcp connection-event log for this tenant (newest first, up to 200 entries). Every HTTP /mcp request Meridian receives is recorded: timestamp, MCP method (initialize/tools/list/tools/call/...), auth_result (success/oauth/no_token/invalid_token/expired), tools_returned (tool count for tools/list responses), client_user_agent, and HTTP response_status. Use this to diagnose client-side outages (zero tools returned, auth failures, unexpected User-Agents) in real time or after the fact without needing raw Fly.io log access.
get_context_block
read-only
modeproject_idproject_name
[SUPPORT] Read-only: Return a compact project context block (north star, sprint, pending sprint items, recent tasks, recent decisions, active sessions) wrapped in a <meridian_conte… [SUPPORT] Read-only: Return a compact project context block (north star, sprint, pending sprint items, recent tasks, recent decisions, active sessions) wrapped in a <meridian_context project_id="..." mode="..."> XML envelope for structured parsing by AI clients (v2.5+). The 'text' field in the response contains the XML-wrapped content. mode='full' (default) for Code Handoff into a fresh Claude Code session; mode='chat' for a shorter paste into a new claude.ai conversation. The HTTP route /projects/{id}/context-block returns the same content as unwrapped plain text.
get_custom_hooks
read-only
eventproject_idenabled_onlyproject_name
[MAINTENANCE] 273287cb — list a project's user-defined hooks (newest first). Optional event filter and enabled_only flag. Each entry includes the derived slug (the filename stem us… [MAINTENANCE] 273287cb — list a project's user-defined hooks (newest first). Optional event filter and enabled_only flag. Each entry includes the derived slug (the filename stem used when written to .claude/hooks/) alongside the stored fields.
get_document_structure
file_path*
[SUPPORT] 13462df2 — return the heading outline of a Word .docx WITHOUT ingesting it as a note. Meridian parses the .docx server-side (stdlib only, no python-docx, no persistent in… [SUPPORT] 13462df2 — return the heading outline of a Word .docx WITHOUT ingesting it as a note. Meridian parses the .docx server-side (stdlib only, no python-docx, no persistent index) and returns paragraph_count, heading_count, and an ordered list of headings (level, text, para_id) — a fast structural map of a thesis chapter / spec before deciding what to read or ingest. Pass file_path to a server-accessible .docx. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
get_docx_region_claims
file_path*
[MAINTENANCE] f7ee1ba7 — Read-only: list active scoped docx-region claims on a file (who owns which element_ids). Use before update_paragraph to see whether the target element is c… [MAINTENANCE] f7ee1ba7 — Read-only: list active scoped docx-region claims on a file (who owns which element_ids). Use before update_paragraph to see whether the target element is claimed. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
get_effective_capability_profile
project_idproject_nameuser_scope_idsprint_item_idworkspace_scope_id
[SUPPORT] 02038afe — Read-only: resolve and return the MERGED capability profile for a project (optionally narrowed to one sprint item) across every applicable layer — workspace ->… [SUPPORT] 02038afe — Read-only: resolve and return the MERGED capability profile for a project (optionally narrowed to one sprint item) across every applicable layer — workspace -> user -> project -> sprint_version -> item, least to most specific. A capability id declared at more than one layer resolves to the most specific layer's declaration; the response's capability_sources maps each effective capability id to the layer that won. overrides lists every capability id declared by more than one layer (each entry flagged conflict=true when the two declarations disagree on required_tools or availability_policy — the fields that change what an executor can actually rely on). disabled lists every disable that actually retracted an inherited capability. Pass sprint_item_id to also resolve that item's sprint_version and item layers; omit it to get just workspace/user/project. Never resolves against live tool/tunnel availability — this is the declared, merged profile only. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
get_effective_profile
read-only
project_idsession_idproject_nameuser_scope_idworkspace_scope_idhosted_default_scope_id
[SUPPORT] 0bec79a7 (PROFILE-5) — Read-only: resolve and return the MERGED profile for a project across every applicable layer — hosted_default -> workspace -> user -> project -> se… [SUPPORT] 0bec79a7 (PROFILE-5) — Read-only: resolve and return the MERGED profile for a project across every applicable layer — hosted_default -> workspace -> user -> project -> session, least to most specific (see meridian.db.profile_layers.get_effective_profile). The 'project' layer is synthetic: its 7 legacy ProjectSettings/executor_config fields come from the existing get_project_settings authority (zero duplication), and its 3 new fields (tool_priority_map, capability_manifest_ref, claim_verification_mode) come from the real profile_layers row. A hosted_default layer only applies when its lifecycle_state is 'active' or 'deprecated' — 'draft' and 'retired' never contribute fields but still mark the result degraded/not-executable via the returned executable/degraded/*_reasons fields. Pass session_id/user_scope_id to also fold in those layers; workspace_scope_id/hosted_default_scope_id default to 'singleton'/'global'. Returns {error} for an unknown project_id.
get_file_claims
read-only
symbolfile_path*project_idproject_name
[SUPPORT] Read-only: show active claims on a file — the whole-file lock (with the holder's session name, if any) plus any symbol-level claims. Use to check who owns a file before e… [SUPPORT] Read-only: show active claims on a file — the whole-file lock (with the holder's session name, if any) plus any symbol-level claims. Use to check who owns a file before editing it. Pass project_id (and optional symbol) to also get a `code_notes` list of code-anchored notes (kind='code') for that path.
get_findings
keylimitproject_idsession_idproject_name
[MAINTENANCE] Read-only (c35370cc): read stored session_findings for a project (newest first), optionally scoped by key and/or session_id. The read side of store_finding. Persisten… [MAINTENANCE] Read-only (c35370cc): read stored session_findings for a project (newest first), optionally scoped by key and/or session_id. The read side of store_finding. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
get_flag_drift
read-only
docroot_dirflag_nameelement_idproject_idproject_name
[MAINTENANCE] 8ca89e8f — read side of link_flag_to_section: for every recorded flag link (optionally scoped to one doc / element_id / flag_name — pass flag_name alone with no doc f… [MAINTENANCE] 8ca89e8f — read side of link_flag_to_section: for every recorded flag link (optionally scoped to one doc / element_id / flag_name — pass flag_name alone with no doc for the REVERSE query 'flag X changed, which sections does it touch'), re-scan the CURRENT codebase (same AST scan as get_flag_registry) and diff each link's recorded default against what the flag defaults to NOW. Only the most recently recorded link per (element, flag) pair is diffed — a re-verified section's older links are history, not live claims. Each result carries status: 'removed' (the flag, or this exact call site, no longer exists — the strongest staleness signal), 'drifted' (the flag still exists but its default changed since this section was computed — the section is possibly stale, needs re-verification), or 'ok' (no evidence of drift found). Returns {project_id, root_dir, links:[{...link fields, current_default, current_call_sites, status}], summary:{ok, drifted, removed}}. No recorded links returns an empty list, never an error — this is advisory, not a hard gate.
get_flag_registry
read-only
root_dir
[SUPPORT] 45802b67 — scan a source tree for `os.environ.get(...)` / `os.getenv(...)` call sites (AST-based, not regex) and return a flat inventory of every config flag the codebase… [SUPPORT] 45802b67 — scan a source tree for `os.environ.get(...)` / `os.getenv(...)` call sites (AST-based, not regex) and return a flat inventory of every config flag the codebase reads: {flag_name, file, line, default}. Only call sites where the flag name is a STRING LITERAL first argument are included — dynamic names (a variable, f-string, etc.) are skipped gracefully rather than erroring. The default is best-effort literal-eval'd from the second positional arg (or a `default=` keyword); a non-literal default evaluates to null. Useful for auditing config drift — 'what env flags exist, where are they read, what do they default to' — without grepping by hand. Returns {repo_root, flags:[...], count, unique_flag_names:[...], unique_count}. A missing/empty tree returns an empty flags list, never an error.
get_goal
read-only
project_idproject_name
[SUPPORT] Read-only: Fine-grained — return just the goal fields (north_star, sprint, version_goal) in isolation. Use start_session or get_session_brief for full context including t… [SUPPORT] Read-only: Fine-grained — return just the goal fields (north_star, sprint, version_goal) in isolation. Use start_session or get_session_brief for full context including tasks and decisions. Use get_goal when you only need the raw goal fields.
get_graph_diff
read-only
session_a*session_b*
[MAINTENANCE] Read-only: compare the latest code-graph snapshots of two sessions — returns delta in node_count, hotspot_count, and file_churn. Use snapshot_graph_metrics first to r… [MAINTENANCE] Read-only: compare the latest code-graph snapshots of two sessions — returns delta in node_count, hotspot_count, and file_churn. Use snapshot_graph_metrics first to record each session's current state.
get_hitl_request
read-only
request_id*
[SUPPORT] Read-only: Poll a HITL request for the human's answer. Returns the row including status ('pending'|'answered'|'dismissed') and answer text. [SUPPORT] Read-only: Poll a HITL request for the human's answer. Returns the row including status ('pending'|'answered'|'dismissed') and answer text.
get_insights
read-only
horizonproject_idproject_name
[SUPPORT] Read-only: List a project's strategic insights (newest first), optionally filtered by horizon (permanent|year|quarter). Review accumulated understanding before planning.… [SUPPORT] Read-only: List a project's strategic insights (newest first), optionally filtered by horizon (permanent|year|quarter). Review accumulated understanding before planning. permanent insights also appear automatically in get_planning_brief.
get_latex_structure
sourcefile_path
[SUPPORT] 106118cd — parse a LaTeX (.tex) source's structure WITHOUT a PDF intermediary. Meridian parses the .tex server-side with pylatexenc (pure-Python, no LaTeX install) and re… [SUPPORT] 106118cd — parse a LaTeX (.tex) source's structure WITHOUT a PDF intermediary. Meridian parses the .tex server-side with pylatexenc (pure-Python, no LaTeX install) and returns heading_count, an ordered headings outline and a nested tree of \part/\chapter/\section/\subsection/\subsubsection/\paragraph (level, kind, text, children), plus unexpanded_inputs (\input/\include filenames, not expanded) and a bibliography list (thebibliography \bibitem entries, and \bibliography{...} + a sibling .bib when a path is given). Pass file_path to a server-accessible .tex, OR pass source with the raw LaTeX inline. Malformed LaTeX returns a partial/empty result, never an error crash. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
get_notes
read-only
tagsortlimitquerybodiescursor
+2
[SUPPORT] Read-only: List project notes (newest first), LIGHTWEIGHT by default — each item is id/slug/title/tags/kind/priority/timestamps with NO body, so the list never overflows… [SUPPORT] Read-only: List project notes (newest first), LIGHTWEIGHT by default — each item is id/slug/title/tags/kind/priority/timestamps with NO body, so the list never overflows context. This is the pull model: scan the list, then call read_note(project_id, slug) to fetch one note's full body on demand. Optional ?tag substring filter and ?query full-text search (matches title+body even though bodies aren't returned). Pass bodies=true only when you truly need every body inline. Pagination: pass limit (default 100, max 500) and/or cursor to get a {notes, has_more, next_cursor} envelope, then re-call with cursor=next_cursor for the next page; omit both for the full list.
get_parallelizable_groups
versionproject_idproject_name
[MAINTENANCE] Read-only: Return clusters of pending sprint items that are safe to run simultaneously. Filters pending/todo items (optionally by version) whose depends_on is satisfi… [MAINTENANCE] Read-only: Return clusters of pending sprint items that are safe to run simultaneously. Filters pending/todo items (optionally by version) whose depends_on is satisfied, then greedily partitions them into groups where no two items in a group share a touches_resources identifier. The orchestrator fans out each group as a parallel subagent batch and runs the groups in sequence. Returns {version, groups: [[item,...],...], group_count, eligible_count, undeclared_count, blocked: [...]}. Items still waiting on an unfinished dependency are listed under 'blocked', not in any group. Makes parallel sprints system-enforced rather than LLM-guessed. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
get_pinned_decisions
read-only
project_idproject_nameinclude_superseded
[SUPPORT] Read-only: List pinned decisions, highest priority first (urgent → normal → low, then newest-first). Active only by default. Each row includes its priority and a parsed e… [SUPPORT] Read-only: List pinned decisions, highest priority first (urgent → normal → low, then newest-first). Active only by default. Each row includes its priority and a parsed edit_log array of prior bodies ({body, ts}) recorded on every in-place body edit.
get_planning_brief
read-only
sinceexpandproject_idproject_name
PLANNING SESSIONS: CALL THIS FIRST before anything else. Read-only: Return a compact planning context — sprint, north star, pending items, in-progress items, recent tasks, active s… PLANNING SESSIONS: CALL THIS FIRST before anything else. Read-only: Return a compact planning context — sprint, north star, pending items, in-progress items, recent tasks, active sessions, recent decisions, unvalidated assumptions, the last session's output (last_session), and a new-handoff signal. No session registration needed. Designed for planning chat sessions that need to see project state without side effects. Pass `since` (a prior call's generated_at) to flag only handoffs filed since you last checked. pending_items/in_progress default-collapse any parent_id/item_group cluster (2+ items) into one summary row — pass expand=true for the full ungrouped list.
get_plugin_details
read-only
name*
[MAINTENANCE] Read-only: Full schema for one named plugin (all tool definitions, description overrides, and stored skill guide if available). Use list_plugins first to see which pl… [MAINTENANCE] Read-only: Full schema for one named plugin (all tool definitions, description overrides, and stored skill guide if available). Use list_plugins first to see which plugins are active, then call get_plugin_details(name) to load the schema for a specific plugin on demand.
get_profile_layer
read-only
scope_id*scope_type*
[SUPPORT] 0bec79a7 (PROFILE-5) — Read-only: return the raw, single-layer profile for one (scope_type, scope_id) — one row of the hosted_default -> workspace -> user -> project -> s… [SUPPORT] 0bec79a7 (PROFILE-5) — Read-only: return the raw, single-layer profile for one (scope_type, scope_id) — one row of the hosted_default -> workspace -> user -> project -> session contract, with no merging against any other layer. A scope with no persisted row gets an empty profile back (revision=0, fields={}), never an error — mirrors get_capability_manifest's 'never a read error' contract. Use get_effective_profile instead when you want the MERGED, multi-layer view for a project.
get_profile_layer_revisions
read-only
limitscope_id*
[SUPPORT] 0bec79a7 (PROFILE-5) — Read-only: the hosted_default revision/audit history for one scope_id, newest first — the rollback/audit trail the profile contract requires for th… [SUPPORT] 0bec79a7 (PROFILE-5) — Read-only: the hosted_default revision/audit history for one scope_id, newest first — the rollback/audit trail the profile contract requires for the one layer that is 'immutable once published'. Only hosted_default writes are ledgered; a non-hosted_default scope_id always returns []. Each entry carries revision, content_hash, lifecycle_state, fields, reset_fields, actor, and created_at.
get_project_by_name
read-only
name*
[MAINTENANCE] Read-only: Find a project by name — look up, search, or resolve a project's project_id from its name (case-insensitive substring match). Use when the user names a pro… [MAINTENANCE] Read-only: Find a project by name — look up, search, or resolve a project's project_id from its name (case-insensitive substring match). Use when the user names a project but you need its id. Returns the first hit with id, name, and sprint.
get_proposal_gates
read-only
statecategoryproject_idproject_namesprint_item_id
[SUPPORT] Read-only: list proposal HITL gates for a project, optionally filtered by category and/or (raw, stored) state. Pass sprint_item_id to instead list only the gates currentl… [SUPPORT] Read-only: list proposal HITL gates for a project, optionally filtered by category and/or (raw, stored) state. Pass sprint_item_id to instead list only the gates currently blocking/quarantining that one item (an effective-state-aware view — an expired auto_on_expiry gate is included even if its stored state says 'allowed').
get_server_log_checkpoint
read-only
seek_to
[MAINTENANCE] b241a437 -- Read-only: Return the positional/checkpoint index for the server_logs ring-buffer. The checkpoint is a lightweight 'table of contents' mapping minute-leve… [MAINTENANCE] b241a437 -- Read-only: Return the positional/checkpoint index for the server_logs ring-buffer. The checkpoint is a lightweight 'table of contents' mapping minute-level timestamp buckets to the first/last row id and row count in that bucket. Use this for fast navigation through large log windows: find the bucket just before your target timestamp, then use its min_recorded_at as the since= argument to get_server_logs to skip all older rows without scanning. Complementary to search_server_logs (BM25 text search): this is positional navigation (WHERE in the log?) not semantic ranking (WHAT text?). The optional seek_to= argument returns the best since= hint directly. The index is rebuilt from the in-memory snapshot on every get_server_logs / search_server_logs call, so it is always current. Returns {total_rows, bucket_granularity_label, min_recorded_at, max_recorded_at, bucket_count, buckets:[{bucket, count, min_recorded_at, max_recorded_at, first_id, last_id}], seek_hint (when seek_to= given)}.
get_server_logs
read-only
limitsinceseek_tolevel_filtermodule_filter
[MAINTENANCE] Read-only: Return recent application-level WARNING/ERROR/EXCEPTION log records (newest first, up to 500 entries). Captures any logging.warning() / logging.error() / u… [MAINTENANCE] Read-only: Return recent application-level WARNING/ERROR/EXCEPTION log records (newest first, up to 500 entries). Captures any logging.warning() / logging.error() / unhandled-exception records emitted anywhere in the Meridian process — not just /mcp request metadata. Use this to diagnose server-side errors (OAuth flow failures, tools/list timeouts, deploy health issues, DB connection errors) without needing raw Fly.io log access. Complements get_connection_log (which covers per-request /mcp metadata only). Returns {count, since, level_filter, module_filter, entries}.
get_session_activity
read-only
limitsession_id*
[MAINTENANCE] Read-only: Return the raw MCP-tool-call heartbeat feed for the given executor session — a ring-buffer of the last tool calls (newest first, up to 50 entries). Populat… [MAINTENANCE] Read-only: Return the raw MCP-tool-call heartbeat feed for the given executor session — a ring-buffer of the last tool calls (newest first, up to 50 entries). Populated automatically by the MCP dispatcher on every executor tool call, no log_task() needed. Use this to check whether an executor is still running when task_count is 0.
get_session_brief
read-only
roleproject_idsession_idproject_name
[SUPPORT] Read-only: Call this FIRST for project summaries or to see what a session did — returns session, tasks, decisions, and recent commits in one call. Replaces the start_sess… [SUPPORT] Read-only: Call this FIRST for project summaries or to see what a session did — returns session, tasks, decisions, and recent commits in one call. Replaces the start_session + get_context_block two-call pattern for worker/automation sessions. Returns sprint focus, pending sprint items, recent tasks, any blocking failures, and pending HITL requests in a compact XML envelope (<500 tokens).
get_session_log
read-only
session_id*activity_limit
[MAINTENANCE] Read-only: Return the full task log for the given session. Returns every log_task description logged during the session (transcript/task_count) PLUS a recent_activity… [MAINTENANCE] Read-only: Return the full task log for the given session. Returns every log_task description logged during the session (transcript/task_count) PLUS a recent_activity ring-buffer of the last tool calls the executor made — even before log_task() was called. Use recent_activity to check signs of life in a running executor. Useful for post-session review, handoff, or remote planner polling.
get_sprint_item_pointers
read-only
project_idproject_namesprint_item_id*
[SUPPORT] 2976e168 — list the GENERIC POINTERS attached to a sprint item (oldest first). Each pointer is {id, source_type, targets:[{uri, selector, subSelector?}], label, created_a… [SUPPORT] 2976e168 — list the GENERIC POINTERS attached to a sprint item (oldest first). Each pointer is {id, source_type, targets:[{uri, selector, subSelector?}], label, created_at} — the stored shape with its JSON targets deserialized. Read-only; does NOT resolve the targets (use resolve_sprint_item_pointers for that).
get_sprint_items
read-only
expandstatusproject_idproject_name
Read-only: List sprint items for a project. Optional status filter (todo|pending|in_progress|provisional_complete|done|failed|skipped|pushed|indeterminate). Cold sessions read this… Read-only: List sprint items for a project. Optional status filter (todo|pending|in_progress|provisional_complete|done|failed|skipped|pushed|indeterminate). Cold sessions read this to know what's still owed. By default, items sharing a ``parent_id`` (subtasks) or ``item_group`` collapse into one summary row per cluster ({collapsed, cluster_kind, item_group_or_parent, count, done, description, ids}) instead of listing every item — pass expand=true for the full ungrouped list.
get_sprint_notes
read-only
note_kindsession_id*
[SUPPORT] Read-only: Get all ephemeral scratch-pad notes for the current session. Shown at the top of session briefs so every cold start sees active constraints. Pass note_kind='th… [SUPPORT] Read-only: Get all ephemeral scratch-pad notes for the current session. Shown at the top of session briefs so every cold start sees active constraints. Pass note_kind='thinking' to fetch only thinking_sync scratchpad notes, or 'note' for only normal notes; omit for all.
get_sprint_progress
read-only
versionitem_groupproject_idsession_idproject_name
[SUPPORT] Read-only: Return a SUMMARY of sprint items by status (pending/in_progress/done/failed) optionally filtered by version or item_group. Returns total, done, in_progress, pe… [SUPPORT] Read-only: Return a SUMMARY of sprint items by status (pending/in_progress/done/failed) optionally filtered by version or item_group. Returns total, done, in_progress, pending, failed, percent_complete, and by_status (counts only — no per-item list; call get_sprint_items(status="pending") for the live item list). Useful to see how far through the sprint we are without listing all items. Pass session_id to also get a board_change field reporting items added since that session started (live-queue signal — call this between sprint items to pick up mid-run injections).
get_symbol_claims
read-only
file_path*
[MAINTENANCE] Read-only: list symbol-level claims on a file (who owns which class/function/method line ranges). [MAINTENANCE] Read-only: list symbol-level claims on a file (who owns which class/function/method line ranges).
get_symbol_hotspots
read-only
daysfile_pathmin_sessions
[MAINTENANCE] Read-only: symbols claimed by 3+ distinct sessions within 14 days — a refactor/ownership smell. Optionally scope to one file. [MAINTENANCE] Read-only: symbols claimed by 3+ distinct sessions within 14 days — a refactor/ownership smell. Optionally scope to one file.
get_tasks
read-only
limitproject_idproject_name
[SUPPORT] Read-only: Get recent tasks across all sessions. [SUPPORT] Read-only: Get recent tasks across all sessions.
get_tunnel_diagnostics
read-only
hostname
[MAINTENANCE] f1e0df55 — Read-only: ONE layered diagnostic snapshot of your tunnel/connectors, separating what's SAVED in the dashboard from what's ACTUALLY running so a saved-but-… [MAINTENANCE] f1e0df55 — Read-only: ONE layered diagnostic snapshot of your tunnel/connectors, separating what's SAVED in the dashboard from what's ACTUALLY running so a saved-but-not-yet-applied setting is never reported as active. Per slot (fs/code/extract/ppt/word/dc/docs/zotero/outputs/debug): dashboard_configured (persisted), process_active (live server-side socket), external_child_state (last client-reported lifecycle state), last_error, and exact remediation text — plus one of five distinct states: healthy, stale, degraded, quarantined, or restart_required (persisted config and observed runtime disagree). Also reports the server-side tool routing cache size, a config generation + manifest_hash fingerprint for drift detection, and whether a tools/list re-discovery is pending. Includes a run_id + timestamp for correlating with support requests. Tokens/credentials are redacted. Requires an authenticated hosted tenant (tunnel mode) — self-hosted callers with no tenant get an empty, unauthenticated-shaped snapshot.
get_workspace_decisions
read-only
include_superseded
[MAINTENANCE] Read-only: List workspace-level pinned decisions (active only by default, newest first). [MAINTENANCE] Read-only: List workspace-level pinned decisions (active only by default, newest first).
get_workspace_notes
read-only
tag
[MAINTENANCE] Read-only: List workspace-level notes (newest first). Optional ?tag substring filter. [MAINTENANCE] Read-only: List workspace-level notes (newest first). Optional ?tag substring filter.
get_workspace_proposals
taglimitoffsetstatus
[SUPPORT] Read-only: List a bounded page of workspace proposals (human-authored flashes of insight), newest first. When status is omitted, defaults to 'live' proposals only (raw +… [SUPPORT] Read-only: List a bounded page of workspace proposals (human-authored flashes of insight), newest first. When status is omitted, defaults to 'live' proposals only (raw + investigating) — terminal proposals (promoted/rejected) are excluded so the default view reflects what's actually still open. Pass status='all' to fetch every status, or an explicit status (including promoted/rejected) to filter to just that one. Optional tag substring filter. Pagination defaults to 20 rows (maximum 100); pass offset to fetch the next page. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
get_workspace_settings
read-only
[MAINTENANCE] Read-only: Read workspace-global default settings (applies across ALL projects in this workspace): hitl_auto_answer_default and sprint_name_default. Returns the singl… [MAINTENANCE] Read-only: Read workspace-global default settings (applies across ALL projects in this workspace): hitl_auto_answer_default and sprint_name_default. Returns the singleton settings row.
get_workspace_sprint_items
groupstatus
[MAINTENANCE] Read-only: List workspace personal-backlog items (grouped by 'group', then position). Optional 'status' (todo/pending/in_progress/done/skipped/failed) and 'group' fil… [MAINTENANCE] Read-only: List workspace personal-backlog items (grouped by 'group', then position). Optional 'status' (todo/pending/in_progress/done/skipped/failed) and 'group' filters. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
github_search
read-only
typelimitquery*sort_by
[SUPPORT] Search GitHub — a REAL external lookup (keyless), sibling to paper_search/social_search for external prior-art / competitive-repo research. Distinct from search_code, whi… [SUPPORT] Search GitHub — a REAL external lookup (keyless), sibling to paper_search/social_search for external prior-art / competitive-repo research. Distinct from search_code, which only searches the CALLING project's own connected repo. Two keyless endpoints via the 'type' param: 'code' (default; GitHub Code Search — actual usage of a symbol/pattern/API across public repos) and 'repo' (GitHub Repository Search — competitor/prior-art repositories by topic/description/stars). Returns {query, count, results:[{title, authors, summary, published, url, ...}]} — code rows carry path/repo/sha/score, repo rows carry repo/stars/forks/language/score.
idle_until_all_done
session_ids*
[MAINTENANCE] PARALLEL COORDINATION (d3a3a01d): non-blocking barrier check across sibling sessions. Returns {all_done, pending, statuses}; a session is done when closed/archived/mi… [MAINTENANCE] PARALLEL COORDINATION (d3a3a01d): non-blocking barrier check across sibling sessions. Returns {all_done, pending, statuses}; a session is done when closed/archived/missing. The server can't block, so poll until all_done is true — the A2A 'wait for X, Y, Z to finish' primitive. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
idle_until_session_done
read-only
timeout_secondswatching_session_id*
[MAINTENANCE] Read-only: Poll every 30 seconds until another session is closed or archived. Use this when you need to wait before editing a locked file. 6f9503a9 — BOUNDED: the wai… [MAINTENANCE] Read-only: Poll every 30 seconds until another session is closed or archived. Use this when you need to wait before editing a locked file. 6f9503a9 — BOUNDED: the wait times out after timeout_seconds (default 1800s / 30 min) and returns {done:false, timed_out:true, status} so a stuck subagent in a parallel fan-out fails that one item fast instead of hanging the whole batch. Pass timeout_seconds=0 or a large value to tune; there is no unbounded wait.
index_equation
doc*project_idproject_nameomml_or_latex*semantic_label
[MAINTENANCE] 06df6ab3 — index ONE Word equation (OMML) against a document already stored in the doc-structure store — populated by ingest_document (which registers a docx/latex do… [MAINTENANCE] 06df6ab3 — index ONE Word equation (OMML) against a document already stored in the doc-structure store — populated by ingest_document (which registers a docx/latex document's structure here in addition to storing the flat note text). Pass the SAME source/path you ingested under as `doc`. omml_or_latex is auto-detected: a string starting with '<' is treated as raw OMML XML (stored as-is); anything else is treated as LaTeX source (real OMML is generated best-effort — pure-Python latex2mathml piped through a hand-written MathML->OOXML mapper; returns null omml on an unsupported construct, never an error). Before inserting, the normalized LaTeX is fuzzy-matched against every equation already stored for this document — a near-duplicate is NOT silently dropped (the equation is still inserted) but IS surfaced via near_duplicates:[{equation_id, matched_id, matched_latex, score}] so you can spot accidental re-derivations. Returns {equation, near_duplicates}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
index_figure
doc*captionfile_pathproject_idproject_namesemantic_label
[MAINTENANCE] c623e648 — index ONE figure into the SEMANTIC figure index against a document already stored in the doc-structure store — populated by ingest_document (which register… [MAINTENANCE] c623e648 — index ONE figure into the SEMANTIC figure index against a document already stored in the doc-structure store — populated by ingest_document (which registers a docx/latex document's structure here in addition to storing the flat note text). Pass the SAME source/path you ingested under as `doc`. This is the figure parallel of index_equation and is COMPLEMENTARY to the structural kind='figure' section-tree placement (it adds caption dedup + similarity, it does not replace placement). Provide file_path and/or caption. Before inserting, the normalized caption is fuzzy-matched against every figure already indexed for this document — a near-duplicate is NOT silently dropped (the figure is still inserted) but IS surfaced via near_duplicates:[{figure_id, matched_id, matched_caption, score}] so you can spot an accidental re-index. The referenced file_path is checked on disk: a missing file is FLAGGED (file_exists on the row + a missing_files entry), never a hard failure. Returns {figure, near_duplicates, missing_files}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
index_table
doc*captionproject_idtable_indexproject_namesemantic_label
+1
[MAINTENANCE] 2622182d — index ONE table into the SEMANTIC table index against a document already stored in the doc-structure store — populated by ingest_document (which registers… [MAINTENANCE] 2622182d — index ONE table into the SEMANTIC table index against a document already stored in the doc-structure store — populated by ingest_document (which registers a docx/latex document's structure here in addition to storing the flat note text). Pass the SAME source/path you ingested under as `doc`. This is the table parallel of index_figure and is COMPLEMENTARY to the structural kind='table' section-tree placement (it adds caption dedup + similarity, it does not replace placement). Provide caption and/or table_index. Before inserting, the normalized caption is fuzzy-matched against every table already indexed for this document — a near-duplicate is NOT silently dropped (the table is still inserted) but IS surfaced via near_duplicates:[{table_id, matched_id, matched_caption, score}] so you can spot an accidental re-index. When paired_figure_id is omitted, the nearest figure in the same structural section is surfaced as suggested_figure_id (advisory, never auto-applied). Returns {table, near_duplicates}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
ingest_document
tagstitlesourcecontentfile_pathproject_id
+1
[SUPPORT] Turn a Word/PDF/text document into a queryable kind='document' note with a source link — a report, thesis chapter, or spec doc becomes searchable project memory. Pass fil… [SUPPORT] Turn a Word/PDF/text document into a queryable kind='document' note with a source link — a report, thesis chapter, or spec doc becomes searchable project memory. Pass file_path OR content (one is required): • file_path → Meridian extracts the text SERVER-SIDE, STDLIB ONLY: .txt/.md/.markdown and source files are read directly; .docx is unzipped and its paragraphs extracted (no python-docx). No new dependencies. • content → use this for .pdf and anything Meridian can't parse server-side: extract the text with YOUR OWN tools first, then pass it here. (Passing file_path for a .pdf returns an error telling you to do this.) title defaults to the file's basename; source defaults to file_path. The stored body is capped (truncated with a '…[truncated]' marker if very long; the kept prefix stays searchable). Meridian never summarizes — pass a summary as content if you want one stored instead of the raw text. Returns the created note (id, slug, title, source). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
ingest_document_structure
titleblocks*source*doc_typeproject_idproject_name
[MAINTENANCE] db42acce — persist pre-parsed structural data (headings/figures/tables) into the doc-structure store, keyed on the SAME source as ingest_document(content=...) so find… [MAINTENANCE] db42acce — persist pre-parsed structural data (headings/figures/tables) into the doc-structure store, keyed on the SAME source as ingest_document(content=...) so find_similar_figure / index_figure / index_table / index_equation see the correct document_id. Use this when the .docx lives on the caller's local machine (not on the Meridian server): call the tunnel-side ingest_local_document_structure tool (from the meridian-docs extension) which parses the file locally and forwards the blocks JSON here. The source must exactly match the source that ingest_document stored the flat note under (default: the local file path). Returns {document_id, source, doc_type, element_count}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
insert_equation
doc*para_id*positionproject_idproject_nameequation_id_or_omml*
[MAINTENANCE] 51a595e7 — write an OMML equation DIRECTLY into a stored document's source .docx (real OOXML write-back), collapsing the manual resolve->open->parse->splice->rewrite-… [MAINTENANCE] 51a595e7 — write an OMML equation DIRECTLY into a stored document's source .docx (real OOXML write-back), collapsing the manual resolve->open->parse->splice->rewrite->reindex flow into one call. The document must already be stored in the doc-structure store via ingest_document (which registers a docx/latex document's structure here) AND have a filesystem `source` path to write back to. Locate the target paragraph by `para_id` — the paragraph's w14:paraId (or the synthesized 'p{index}' id that get_document_structure / find_similar_equation surface as element_id). equation_id_or_omml is resolved in order: the id of an equation already indexed for THIS document (its stored OMML is reused); else a string starting with '<' is raw OMML XML; else a LaTeX source (converted best-effort via latex2mathml -> MathML -> OOXML). position controls placement: 'append' (default) drops the <m:oMath> inline at the end of the paragraph; 'before'/'after' add it as its own display-equation paragraph adjacent to the target. After the write the document's equation index is resynced from the modified file (no separate re-verify step). Returns {document_id, source, para_id, position, omml, resync} on success, or {error} for a bad para_id / unresolvable equation / missing file (the file is never mutated when resolution fails). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
link_figure_caption
doc*figure_id*project_idproject_namecaption_element_id*
[MAINTENANCE] 0ff8b982 — DURABLY link an already-indexed figure (doc_figures row) to its caption paragraph (a doc_elements id), by stable structural id rather than paragraph proxim… [MAINTENANCE] 0ff8b982 — DURABLY link an already-indexed figure (doc_figures row) to its caption paragraph (a doc_elements id), by stable structural id rather than paragraph proximity. Use this to confirm an advisory suggested_caption_element_id returned by index_figure, or to backfill a durable link on a figure that was indexed before caption linkage was supported. Provide figure_id (the doc_figures.id of the figure to link) and caption_element_id (the doc_elements.id of the caption paragraph — a kind='figure' SEQ-field element from the section-tree store). This is the confirmation primitive for the 'Figure 3b used twice' ambiguity scenario: when index_figure surfaces suggested_caption_candidates (multiple captions in the same section), inspect them and call this tool with the correct one to confirm the durable link. Returns the updated figure row on success, or {error} when figure_id doesn't resolve to a known figure. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
link_flag_to_section
doc*value*defaultflag_name*element_id*project_id
+3
[MAINTENANCE] 8ca89e8f — DURABLY link a docx section/paragraph/figure/table (any doc_elements id — the same id space index_figure/index_table/link_figure_caption already anchor to)… [MAINTENANCE] 8ca89e8f — DURABLY link a docx section/paragraph/figure/table (any doc_elements id — the same id space index_figure/index_table/link_figure_caption already anchor to) to the config-flag state that produced its underlying numbers. This is the check that catches 'results computed with the wrong flag state, then cited as current' — e.g. a flag that silently skipped a whole code path regardless of another flag, or a stale count cited after a fix superseded it. Typical flow: call get_flag_registry to find the flag's current file/line/default, compute the section, then call this tool with value=the value actually used and default=the default get_flag_registry reported (so get_flag_drift has something to compare the codebase's CURRENT default against later). Insert-only: re-linking the same (element_id, flag_name) pair after a re-verification adds a new history row rather than overwriting the old one. Returns {project_id, document_id, link}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
link_manual_github_issue
item_id*project_idsession_idissue_number*project_name
[SUPPORT] 5dfe34b2 — attempt to link a manually-filed GitHub issue (one Meridian did NOT create) to a sprint item, extending fdaa5b55's automated comment/propose flow to it. No-ops… [SUPPORT] 5dfe34b2 — attempt to link a manually-filed GitHub issue (one Meridian did NOT create) to a sprint item, extending fdaa5b55's automated comment/propose flow to it. No-ops safely (action='skipped') unless manual_issue_screening_enabled is on. When enabled: reads the issue's raw content, logs it (hashed, append-only) before any processing, runs a wave-relative velocity/anomaly check (non-blocking escalation only), then screens title/body/comments for hardcoded injection shapes — flagged content is never auto-linked (a human-review HITL is filed instead); only screening-clean content gets linked (github_issue_source='manual'). Linking NEVER by itself closes the issue — fdaa5b55's existing propose+HITL flow still applies at sprint-item completion time. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
link_table_caption
doc*table_id*project_idproject_namecaption_element_id*
[MAINTENANCE] 42d398a5 — DURABLY link an already-indexed table (doc_tables row) to its caption paragraph (a doc_elements id), by stable structural id rather than paragraph proximit… [MAINTENANCE] 42d398a5 — DURABLY link an already-indexed table (doc_tables row) to its caption paragraph (a doc_elements id), by stable structural id rather than paragraph proximity. The table analogue of link_figure_caption. Use this to confirm an advisory suggested_caption_element_id returned by index_table, or to backfill a durable link on a table that was indexed before caption linkage was supported. Provide table_id (the doc_tables.id of the table to link) and caption_element_id (the doc_elements.id of the caption paragraph — a kind='table' SEQ-field element from the section-tree store). This is the confirmation primitive for the ambiguous-multi-candidate scenario: when index_table surfaces multiple caption candidates in the same section, inspect them and call this tool with the correct one to confirm the durable link. Returns the updated table row on success, or {error} when table_id doesn't resolve to a known table. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
list_hitl_requests
read-only
limitstatusproject_idproject_name
[SUPPORT] Read-only: List HITL requests without needing UUIDs. OMIT project_id to list pending HITLs across ALL your projects (matches the dashboard) — planning sessions should cal… [SUPPORT] Read-only: List HITL requests without needing UUIDs. OMIT project_id to list pending HITLs across ALL your projects (matches the dashboard) — planning sessions should call it this way so HITLs filed under another project aren't missed (a common cause of false 'no pending HITLs' confidence). Pass project_id to scope to one project. Returns pending queue plus answered/dismissed from the last 24 h by default so planning sessions can see what was recently decided without a separate call. Pass status='pending' for only the active queue, or status='answered'/'dismissed'/'all' for specific history.
list_plugins
read-only
[MAINTENANCE] Read-only: Lightweight index of active tunnel plugins — name, description, enabled state, and tool_count. Does NOT return full tool schemas (use get_plugin_details fo… [MAINTENANCE] Read-only: Lightweight index of active tunnel plugins — name, description, enabled state, and tool_count. Does NOT return full tool schemas (use get_plugin_details for that). Dramatically reduces context bloat vs. dumping all plugin schemas at startup (~500 tokens vs 50k+). Returns an 'active_plugins' list plus any stored skill notes.
list_profile_layers
read-only
scope_type
[SUPPORT] 0bec79a7 (PROFILE-5) — Read-only: enumerate every persisted profile_layers row across the 5-layer hosted_default -> workspace -> user -> project -> session contract (see… [SUPPORT] 0bec79a7 (PROFILE-5) — Read-only: enumerate every persisted profile_layers row across the 5-layer hosted_default -> workspace -> user -> project -> session contract (see meridian.profile_contract / meridian.db.profile_layers for the full design), optionally narrowed to one scope_type. Each entry is shaped exactly like get_profile_layer's return value: scope_type, scope_id, schema_version, revision, fields, reset_fields, lifecycle_state (hosted_default only), content_hash, provenance, updated_at. Ordered by (scope_type, scope_id) for deterministic output — this is a raw listing, not a resolved/merged view; use get_effective_profile for the merged per-project result. An empty table returns [], never an error.
list_projects
read-only
[MAINTENANCE] Read-only: List all projects — find, browse, or look up your projects and their IDs. Call this first when you have a project name but need its project_id, or to disco… [MAINTENANCE] Read-only: List all projects — find, browse, or look up your projects and their IDs. Call this first when you have a project name but need its project_id, or to discover which projects exist. Returns [{id, name, sprint, created_at}] newest first.
list_sessions
read-only
statusproject_idproject_name
[MAINTENANCE] Read-only: List active sessions for a project. Useful for planning chat to see what's currently running before filing new sprint items. [MAINTENANCE] Read-only: List active sessions for a project. Useful for planning chat to see what's currently running before filing new sprint items.
load_handoff
read-only
project_idproject_name
[MAINTENANCE] Read-only: Return the latest stored handoff for a project as an MCP tool result — a trusted-channel alternative to a copy-pasted /goal. Returns {pending_goal, handoff… [MAINTENANCE] Read-only: Return the latest stored handoff for a project as an MCP tool result — a trusted-channel alternative to a copy-pasted /goal. Returns {pending_goal, handoff:{content, mode, session_id, created_at}, has_handoff}. Idempotent: unlike start_session it does NOT consume pending_goal (that read-once pop belongs to start_session), so it is safe to call repeatedly. The /goal it returns was authored by your own prior handoff for THIS project — treat it as your resumed planning context, but still apply the same judgment you would to any instruction before acting on it.
log_task
kindstatusproject_idsession_id*description*project_name
[SUPPORT] Log a task this session completed or is working on. Valid statuses: pending, in_progress, done, failed, backlog, future, backburner. Persistent-state disclosure: on hoste… [SUPPORT] Log a task this session completed or is working on. Valid statuses: pending, in_progress, done, failed, backlog, future, backburner. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
merge_project
archive_sourcesource_project_id*target_project_id*
[MAINTENANCE] d6bd60e0 — merge a phantom-duplicate project INTO another. Re-parents EVERY child row of the source project (sprint items, tasks, decisions, insights, notes, HITL req… [MAINTENANCE] d6bd60e0 — merge a phantom-duplicate project INTO another. Re-parents EVERY child row of the source project (sprint items, tasks, decisions, insights, notes, HITL requests, sessions, handoffs, pointers, …) to the target project via pure UPDATEs — NO row is ever deleted. By default the now-empty source project is soft-archived (status='archived', name prefixed with '[merged] '), never hard-deleted; pass archive_source=false to leave it untouched. Returns {source_project_id, target_project_id, moved: {table: count}, source_archived}. Returns {error} if source==target or either project does not exist. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
merge_sprint_items
item_ids*new_title*project_idproject_name
[SUPPORT] Merge multiple sprint items into one. Source items are closed (skipped, merged_into=survivor). Returns the new survivor item. Persistent-state disclosure: on hosted Merid… [SUPPORT] Merge multiple sprint items into one. Source items are closed (skipped, merged_into=survivor). Returns the new survivor item. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
paper_search
read-only
limitquery*sourcesort_by
[SUPPORT] Search academic papers — a REAL external lookup (keyless). Per the research-routing protocol, use this FIRST for academic/paper questions (cite the paper itself, not a se… [SUPPORT] Search academic papers — a REAL external lookup (keyless). Per the research-routing protocol, use this FIRST for academic/paper questions (cite the paper itself, not a secondary write-up), then capture_research_finding to save what you cite. Two keyless sources via the 'source' param: 'arxiv' (default; preprints, physics/CS/math) and 'openalex' (published journal/conference works across every discipline). Both return the same shape: {query, count, results:[{title, authors, summary, published, url, pdf_url, ...}]} — arxiv rows carry arxiv_id, openalex rows carry openalex_id + doi.
pin_decision
body*title*categorypriorityassumptionproject_id
+1
[SUPPORT] Create a pinned decision (editable constitution row). Use for the current authoritative truth that supersedes earlier statements. category is free-text; suggested values:… [SUPPORT] Create a pinned decision (editable constitution row). Use for the current authoritative truth that supersedes earlier statements. category is free-text; suggested values: STRATEGIC, COMPETITIVE, TECHNICAL, TACTICAL, BUSINESS, PRODUCT, ARCHITECTURAL. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
pin_workspace_decision
body*title*category
[MAINTENANCE] Pin a workspace-level decision that applies across ALL projects (shared architecture, org-wide standards). Injected at the top of every project's context block + hand… [MAINTENANCE] Pin a workspace-level decision that applies across ALL projects (shared architecture, org-wide standards). Injected at the top of every project's context block + handoff. category is free-text (STRATEGIC, TECHNICAL, ARCHITECTURAL, PRODUCT, ...). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
preview_proposal_promotion
read-only
depth*project_idproposal_id*project_namesprint_item_titletouches_resources
+2
[SUPPORT] Read-only (ce4883f3): preview what commit_proposal_promotion would do for a proposal at a given depth, WITHOUT writing anything. Depths are cumulative, shallow to deep: '… [SUPPORT] Read-only (ce4883f3): preview what commit_proposal_promotion would do for a proposal at a given depth, WITHOUT writing anything. Depths are cumulative, shallow to deep: 'proposal' (intake/scope only) -> 'investigation' (+ raw->investigating transition) -> 'pointers' (+ pointer recording) -> 'sprint_items' (+ promote_workspace_proposal) -> 'executable_handoff' (+ a handoff scoped to the new sprint item). Returns {proposal_id, project_id, depth, already_satisfied, contract_status, would_create, wave_preview, preview_hash, computed_at}. 'already_satisfied'=true when the proposal's current status already reaches this depth (e.g. already 'promoted' and depth='sprint_items') — no-op, nothing further to preview. Otherwise 'contract_status' reports each of the 8 proposal-to-execution contract parts as present/would_create/optional_at_commit/not_applicable; 'would_create' shows the synthetic sprint-item preview (title/version/touches_resources) once depth>='sprint_items'; 'wave_preview' shows which existing parallel-safe group the item would join or conflict with (via get_parallelizable_groups, unmodified). Pass the returned 'preview_hash' to commit_proposal_promotion — a stale hash (proposal or board changed since) is rejected rather than silently committed.
promote_proposal
project_idproposal_id*project_namesprint_item_titlesprint_item_version
Promote a workspace proposal into a real sprint item, creating the link between them. The proposal must be in 'raw' or 'investigating' state. Creates a sprint item under the given… Promote a workspace proposal into a real sprint item, creating the link between them. The proposal must be in 'raw' or 'investigating' state. Creates a sprint item under the given project and sets the proposal's status to 'promoted' with promoted_to_sprint_item_id pointing to the new item. Returns {proposal, sprint_item_id, sprint_item_title, project_id}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
prospect_symbol
read-only
kindlimitsymbol*root_dirproject_idsession_id
+2
[SUPPORT] 2ce5bc76 — ROBUST symbol prospecting with a three-rung fallback chain: tries codebase__search_graph FIRST (fast, graph-indexed); when it returns zero results OR the calle… [SUPPORT] 2ce5bc76 — ROBUST symbol prospecting with a three-rung fallback chain: tries codebase__search_graph FIRST (fast, graph-indexed); when it returns zero results OR the caller flags a mismatch (stale_graph=true), automatically retries via Serena extractor__find_symbol / extractor__find_declaration (AST-accurate, never stale); falls back to a BM25 keyword grep over search_code_semantic as a last resort so the caller NEVER has to notice a miss and switch tools by hand. Each rung is labelled in the result ({rung: 'graph'|'serena'|'semantic', hits:[...], fallback_reason: str?}) so the caller knows which level succeeded. All three legs are best-effort: a missing tunnel, inactive slot, or missing root_dir degrades to the next rung, never a bare error with no diagnostic. d5e60791 — every rung's outcome is recorded under result.rungs.{graph,serena,semantic}: status ('not_attempted'|'skipped'|'attempted'|'succeeded'|'empty'|'error'), attempted_tool/selected_tool, and (on skip/error) a reason/error + error_kind ('dependency_error' vs 'runtime_error') — a missing dependency (e.g. an uninstalled local package) or any other runtime failure in a rung is NEVER silently collapsed into rung='none' with no trace; fallback_reason is always populated when every rung misses. 4b8f083f — when root_dir is a git checkout, the graph rung is ALSO auto-skipped (same as an explicit stale_graph=true, with fallback_reason 'graph_skipped_commit_drift_detected') whenever a cheap local `git rev-list --count` finds real commits since the last index_repository run for this project — no waiting for a _graph_staleness warning from the server, which only fires when a SIBLING process re-indexes, never when nobody re-indexes at all. Pass root_dir to get this protection. Use this instead of calling codebase__search_graph directly whenever you are prospecting for a symbol, function, or class location — it is structurally immune to the class of silent graph-index miss that previously returned wrong line numbers or empty results for real symbols.
purge_ai_log
can modify data
cutoff*project_idproject_name
[MAINTENANCE] c0168425 — Project-scoped, cutoff-based retention sweep spanning BOTH ai_log_events (meridian.db.ai_log.purge_events_before) and their stored artifacts (meridian.arti… [MAINTENANCE] c0168425 — Project-scoped, cutoff-based retention sweep spanning BOTH ai_log_events (meridian.db.ai_log.purge_events_before) and their stored artifacts (meridian.artifact_store.purge_artifacts_before) in one call, with a single receipt. Deletes every event/artifact strictly older than cutoff (an ISO-8601 UTC datetime, e.g. '2025-01-01T00:00:00Z') for the given project. Irreversible — this is a hard bulk delete, not a soft archive (call export_ai_log / export_ai_log_artifacts first if the data needs to survive the sweep). Returns {project_id, cutoff, events_deleted, artifacts_deleted, purged_at}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
read_note
read-only
slug*project_idproject_name
[SUPPORT] Read-only: Fetch one project note's full body by its per-project slug (the ``slug`` field from get_notes). The pull half of the list→read model — get_notes returns slugs… [SUPPORT] Read-only: Fetch one project note's full body by its per-project slug (the ``slug`` field from get_notes). The pull half of the list→read model — get_notes returns slugs without bodies, read_note pulls a single body when you need it.
receive_messages
limitmark_readsession_id*
[MAINTENANCE] PARALLEL COORDINATION (d3a3a01d): fetch unread messages addressed to a session (oldest first) and mark them read by default. The receive side of send_message. Persist… [MAINTENANCE] PARALLEL COORDINATION (d3a3a01d): fetch unread messages addressed to a session (oldest first) and mark them read by default. The receive side of send_message. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
reconcile_sprint_drift
read-only
project_idproject_name
[MAINTENANCE] Read-only: Cross-reference pending sprint items against recent git commits and return items that may already be done. Uses keyword matching — confidence 'high' means… [MAINTENANCE] Read-only: Cross-reference pending sprint items against recent git commits and return items that may already be done. Uses keyword matching — confidence 'high' means 3+ keywords overlap (safe to mark done), 'medium' means 1-2 (verify first). Also surfaces 'notes_blocker_drift': pending items whose notes describe a deferral or blocker (keywords: FLAGGED, DEFERRED, BLOCKED, 'not implementable', etc.) but whose structured fields (blocker_kind, deferred_until) are both unset — these items will keep surfacing as ordinary claimable work until you call update_sprint_item with blocker_kind='manual' or deferred_until=<ISO timestamp>. Call during planning sessions to identify board drift before filing new items.
record_handoff_correction
modestatusversionoutput_dirproject_idregenerate
+12
[MAINTENANCE] 3af86d28 — record a corrective handoff when a blocked executor session reaches a wall after receiving a handoff (its evidence/scope no longer holds, a pointer stopped… [MAINTENANCE] 3af86d28 — record a corrective handoff when a blocked executor session reaches a wall after receiving a handoff (its evidence/scope no longer holds, a pointer stopped resolving, a required capability went away, etc.). Links to the immutable source_handoff_id (never mutated), classifies the blocker, and carries structured investigation evidence, added/removed/superseded pointers, and changed resources. Records status='draft' by default (or pass status explicitly). Pass idempotency_key to make retries safe — a repeat call with the same key returns the existing correction unchanged rather than duplicating it. Pass regenerate=true to ALSO, in this same call: re-resolve every added pointer live (repair), mark the source handoff invalidated/non-executable (its body is left untouched, for audit), and produce a new deterministic handoff revision (new body hash + provenance token) via the normal generate_handoff renderer. Idempotent: a correction that already produced a revision returns that same result again instead of regenerating a second time. A receiving executor should load the result via load_handoff (its 'correction' field) or a direct get_sprint — not by reconstructing the correction from log_task/note text. No DOCX or canonical project mutation is implied by recording a correction. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
refresh_context
project_idproject_name
[SUPPORT] Single-call post-compaction recovery for planning chats. Returns a COMPACT snapshot — current sprint + progress, next pending items, the active session id, recent handoff… [SUPPORT] Single-call post-compaction recovery for planning chats. Returns a COMPACT snapshot — current sprint + progress, next pending items, the active session id, recent handoffs, high-priority (urgent) decisions, unvalidated assumptions, and key note slugs — small enough not to overflow context. Call this the moment a chat feels disoriented (e.g. right after a /compact) to re-orient in one round-trip. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
refresh_tool_manifest
read-only
[MAINTENANCE] Read-only: return the authoritative, compact manifest of ALL built-in Meridian MCP tools (name + one-line summary). Call this when you suspect your client's tool sche… [MAINTENANCE] Read-only: return the authoritative, compact manifest of ALL built-in Meridian MCP tools (name + one-line summary). Call this when you suspect your client's tool schema went stale ('I nuked the schema', a tool you expected is suddenly 'not found', or right after a /compact) — it is a plain tool CALL, so it works even on clients that ignore the notifications/tools/list_changed signal (e.g. Claude Desktop). Names returned here are canonical: a name present here but absent from your tool list is a stale-schema artifact, not a removed tool. If you're tunnel-connected, this also forces a synchronous re-aggregation of your tunnel's plugin tools (filesystem/code-intel/office/etc.) — the returned `tunnel` object carries a manifest_hash + slot_health + config_generation snapshot so you can tell a recovered/newly-configured slot is now visible without a reconnect.
register_session
clienthuman_idproject_idproject_namesession_name*
[MAINTENANCE] Low-level: register this session without loading goal context. Use start_session instead for executor/human sessions — it registers AND returns goal + tasks in one ca… [MAINTENANCE] Low-level: register this session without loading goal context. Use start_session instead for executor/human sessions — it registers AND returns goal + tasks in one call. Use register_session when you only need a session ID and will fetch context separately. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
release_docx_region_claims
file_pathelement_idsession_id*
[MAINTENANCE] f7ee1ba7 — Release scoped docx-region claims held by a session. Without element_id releases all claims on the file; with element_id releases only that one element. Wi… [MAINTENANCE] f7ee1ba7 — Release scoped docx-region claims held by a session. Without element_id releases all claims on the file; with element_id releases only that one element. Without file_path releases ALL region claims held by the session across all files. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
release_file
file_path*session_id*
[SUPPORT] Release a file lock (and any symbol claims this session holds on it). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- inclu… [SUPPORT] Release a file lock (and any symbol claims this session holds on it). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
rename_project
new_name*project_idproject_name
[MAINTENANCE] 7acb8563 — rename a project. Returns the updated project, or {error} if it does not exist. Persistent-state disclosure: on hosted Meridian, supplied text and project/… [MAINTENANCE] 7acb8563 — rename a project. Returns the updated project, or {error} if it does not exist. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
reopen_proposal_gate
actor*reason*gate_id*project_idproject_name
[SUPPORT] Invalidate a still-standing proposal gate decision (e.g. new evidence surfaced) so resolve_proposal_gate can be called again. Resets the lane to 'blocked' (fail-safe), sn… [SUPPORT] Invalidate a still-standing proposal gate decision (e.g. new evidence surfaced) so resolve_proposal_gate can be called again. Resets the lane to 'blocked' (fail-safe), snapshots the prior decision into previous_decision / previous_actor / previous_decided_at, and increments reopen_count. Refuses with {error} if the gate was never decided. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
request_hitl
kindcontextoptionsurgencyquestion*project_id
+5
Surface a question to the human-in-the-loop queue. ALWAYS use this to ask the human a question — never just ask in chat, which is invisible to the dashboard and to an unattended/au… Surface a question to the human-in-the-loop queue. ALWAYS use this to ask the human a question — never just ask in chat, which is invisible to the dashboard and to an unattended/autonomous run. IMPORTANT: when the project's HITL auto-answer mode is on (1=safe, 2=aggressive) and the question is not destructive / not require_human, this tool RESOLVES IMMEDIATELY and returns the chosen answer inline in the response (it does NOT block) — so calling it is cheap and is the right move even when you expect a quick yes/no. The active mode is reported in the start_session orientation as hitl_auto_answer_mode. urgency='blocking' means this session pauses until answered (poll get_hitl_request). urgency='normal'/'high' lands in the dashboard but doesn't block. assigned_to routes to a specific human_id (null = broadcast). kind='correction' files a non-blocking mid-run correction: never auto-answered, never blocks — an unattended executor picks it up at the next sprint-item boundary, applies it, and continues. Pass `options` (answer choices, rendered as buttons) and `recommended` (an option string or 0-based index) to flag the safe default — the dashboard highlights it and Enter submits it, and an auto-answer picks it. Set require_human=true for genuinely irreversible/destructive actions (token rotation, data migrations, rollbacks) so auto-answer can never approve it — only an explicit human reply unblocks it. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
request_manual_issue_screening_toggle
enable*contextproject_idsession_idproject_name
[SUPPORT] 5dfe34b2 — request enabling/disabling the OFF-by-default opt-in extension that lets the automated GitHub-issue comment/propose flow (never auto-close) also act on issues… [SUPPORT] 5dfe34b2 — request enabling/disabling the OFF-by-default opt-in extension that lets the automated GitHub-issue comment/propose flow (never auto-close) also act on issues Meridian did not itself create, gated behind hardcoded content screening. enable=true ALWAYS files a require_human=true HITL (kind/require_human are hardcoded — this tool cannot be used to self-escalate; only a genuine human answering in the dashboard/API can enable it). enable=false disables immediately with no HITL (fail-safe direction) and is audit-logged either way. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
reset_plugin_override
slot*hostname
[MAINTENANCE] Clear a tenant's stored command/config override for one plugin slot, resetting it back to the built-in default. Fixes the gap where stale_override detection (surfaced… [MAINTENANCE] Clear a tenant's stored command/config override for one plugin slot, resetting it back to the built-in default. Fixes the gap where stale_override detection (surfaced by list_plugins/get_plugin_details) could flag a stale per-tenant override but nothing could programmatically clear it — only dashboard editing worked. Self-hosted only for now: in hosted mode, returns an explicit error rather than risk writing to the wrong database (tunnel_plugins lives on the control-plane tenants table, which this tool call's db handle cannot reach there) — use the dashboard's Tunnel Plugins settings page for hosted tenants. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
reset_profile_layer
scope_id*scope_type*
[SUPPORT] 0bec79a7 (PROFILE-5) — Delete a scope's ENTIRE profile-layer row so it reverts to purely inheriting from less-specific layers — mirrors clear_capability_profile's semanti… [SUPPORT] 0bec79a7 (PROFILE-5) — Delete a scope's ENTIRE profile-layer row so it reverts to purely inheriting from less-specific layers — mirrors clear_capability_profile's semantics for the profile-layers contract. Idempotent: resetting an already-empty or never-set scope is a no-op, not an error. For hosted_default this clears the row (back to no-row / implicit draft) but is NOT an audited lifecycle transition — prefer activate_profile_layer's lifecycle machinery when you need an audited retire/reactivate path instead of an unaudited wipe. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
resolve_citations
max_itemsproject_idproject_name
[MAINTENANCE] fefb596a — resolve this project's in-text citation markers to canonical Zotero items via Zotero's LOCAL API and materialise the cross-document 'cites' -> zotero_item… [MAINTENANCE] fefb596a — resolve this project's in-text citation markers to canonical Zotero items via Zotero's LOCAL API and materialise the cross-document 'cites' -> zotero_item edges (keyed on DOI). An OPT-IN, network-making pass — deliberately separate from ingest, which stays offline. For each kind='citation' marker without a zotero_item edge, the marker's ref is resolved: a DOI (doi:.. / a bare 10.x/y / a doi.org URL) matches the library item with that DOI; a zotero:<key> ref is a direct item lookup; a bare BibTeX citekey is a best-effort text search (fuzzy without Better BibTeX). When the resolved DOI matches a paper ALSO ingested in this project, the edge's target_document_id is linked too. IDEMPOTENT — re-runs only fill gaps, never duplicate. If Zotero is closed or its local API is disabled, markers simply stay unresolved (no error). Returns {resolved, unresolved, cross_doc_linked} counts. Requires Zotero running locally with the local API enabled (endpoint configurable via MERIDIAN_ZOTERO_API_URL). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
resolve_proposal_gate
actor*state*gate_id*decision*expires_atproject_id
+2
[SUPPORT] Record a human decision on a proposal gate: the lane's new state (blocked | quarantined | allowed), the free-text decision, and the actor who decided (decided_at is auto-… [SUPPORT] Record a human decision on a proposal gate: the lane's new state (blocked | quarantined | allowed), the free-text decision, and the actor who decided (decided_at is auto-stamped). Refuses with {error} if the gate was already decided and has not yet expired — call reopen_proposal_gate first. An expired prior decision is treated as lapsed and a fresh decision is accepted directly. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
resolve_sprint_item_pointers
read-only
root_dirproject_idproject_namesprint_item_id*
[SUPPORT] 2976e168 — resolve EVERY generic pointer on a sprint item to its concrete location, dispatching by selector.type. A range target returns its location as-is; symbol resolv… [SUPPORT] 2976e168 — resolve EVERY generic pointer on a sprint item to its concrete location, dispatching by selector.type. A range target returns its location as-is; symbol resolves the qualified_name against the SAME live three-rung chain prospect_symbol uses (graph → Serena → semantic, 653579c5) when this session has an active code tunnel, falling back to the cached code-graph snapshot when it doesn't; node_id looks the element up in the doc-structure store; zotero_key resolves via Zotero's local API; text_quote re-fetches the URL (or docx paragraph text) and flags content drift; finding_id looks up a save_finding artifact note. 62640241 — directory walks the local root and returns a manifest + manifest_hash; git shells out to `git rev-parse` against a local clone to check ref/commit reachability against HEAD; artifact hashes a local manifest file for its current fingerprint; remote_fs has no core-local default (requires a tunnel-backed resolver — reported explicitly unresolved without one). Every one of these five ALSO gets a recomputed freshness_state (current/stale/unknown/unavailable/ambiguous) on its resolved target, comparing the target's declared freshness proof (if any) against what resolution finds right now. A subSelector narrows the outer resolution ('these lines, within this function'). Every dispatch is best-effort: an unresolvable target yields {resolved:false, reason} instead of an error, and the pass NEVER fails. Returns {pointers:[{id, source_type, label, targets:[<resolved-target>]}]}. Requires no network for range/symbol/node_id/directory/git(local)/artifact(local); zotero_key needs Zotero running locally and text_quote needs live web access (else those targets are just unresolved).
resume_wave
goal_tokenwave_run_id*presented_body
[SUPPORT] efaa918a — STALE-MANIFEST GATING: check whether a wave run opened by start_wave_run is still safe to resume against the LIVE board before you act on its pinned manifest.… [SUPPORT] efaa918a — STALE-MANIFEST GATING: check whether a wave run opened by start_wave_run is still safe to resume against the LIVE board before you act on its pinned manifest. Re-queries the board across ALL non-done statuses (pending, todo, in_progress, provisional_complete, indeterminate, failed, skipped, pushed) via build_board_snapshot — NEVER status='pending' alone, which is the exact b763d2ba bug class (a sibling-claimed in_progress item looks like it vanished). Fails CLOSED with SPECIFIC, actionable reasons the moment the live board differs from the pinned manifest in ANY of: revision_hash mismatch (added/removed items, status/dependency/resource/pointer changes — reusing diff_board_snapshots's added/removed/changed_items shape verbatim as resume_delta), an item's wave membership changed, or an item was newly marked blocker_kind='superseded' (its premise was replaced). Optionally also verifies a handoff token: pass goal_token (+ presented_body to additionally check body-hash binding, efaa918a — closes the 2ee0000c gap where a genuine token could be re-attached to an edited body and still verify). Token outcomes keep the four existing distinct meanings from verify_handoff_token (not_found/wrong_project are real spoofing signals; already_consumed/expired usually mean a sibling already acted) PLUS the new body_mismatch (a real spoofing signal — genuine token, edited body). Read-only w.r.t. the wave run itself (does not advance wave_run status — call advance_wave_run_status separately once resumable). Returns {resumable, wave_run_id, status, resume_delta, pinned_revision_hash, live_revision_hash, token_check} on success, or {error, resumable: false, reasons, resume_delta, token_check} naming exactly what is stale. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
run_verification
project_idproject_name
[SUPPORT] 0e973e52 — run the project's stored test_cmd on YOUR local machine via the tunnel and return a REAL, structured result — not self-reported. Fields: {exit_code, passed, fa… [SUPPORT] 0e973e52 — run the project's stored test_cmd on YOUR local machine via the tunnel and return a REAL, structured result — not self-reported. Fields: {exit_code, passed, failed, stdout_tail, stderr_tail, status, timed_out}. Returns {status: 'not_configured'} (never an error) when no test_cmd is set; call set_executor_config(test_cmd='pixi run test') first. Requires an active `meridian --tunnel`; the hosted server has no access to your machine (same architectural class as ingest_document / search_code_semantic / search_outputs — decision 0dedff91). Per-project: only runs when test_cmd is configured for that project. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
save_blog_post
idbodyslugtitle*status
[MAINTENANCE] Create or update a workspace-scoped blog post (draft|published|archived lifecycle). Posts belong to the whole workspace, not a single project, and are served publicly… [MAINTENANCE] Create or update a workspace-scoped blog post (draft|published|archived lifecycle). Posts belong to the whole workspace, not a single project, and are served publicly at /blog/<slug> once status='published'. Pass 'id' to update an existing post; omit it to create a new draft. 'slug' is optional (auto-derived from the title, de-duplicated). Returns the saved post with a computed 'url'. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
save_finding
summary*project_idsource_urldecision_idsource_typeproject_name
[SUPPORT] Phase-agnostic capture primitive: turn a finding into a durable, addressable note with provenance — works with ANY source (Claude's built-in web search, the arXiv MCP, Se… [SUPPORT] Phase-agnostic capture primitive: turn a finding into a durable, addressable note with provenance — works with ANY source (Claude's built-in web search, the arXiv MCP, Serena, a teammate). Decoupled from search so capture survives regardless of how you found it. The summary's first line becomes the note title; the note is tagged 'finding' + the source_type. Optionally links to a pinned decision. Returns the note. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
save_profile_layer
actorfieldsscope_id*provenancescope_type*reset_fields
+2
[SUPPORT] 0bec79a7 (PROFILE-5) — Validate and persist ONE layer of the hosted_default -> workspace -> user -> project -> session profile contract (see meridian.profile_contract.FIE… [SUPPORT] 0bec79a7 (PROFILE-5) — Validate and persist ONE layer of the hosted_default -> workspace -> user -> project -> session profile contract (see meridian.profile_contract.FIELD_REGISTRY for the full field list and per-field allowed_layers/merge_strategy/narrow_only rules). REPLACES this scope's stored fields/reset_fields wholesale (not a merge) — to add one field to an existing layer, pass the full desired field set, not a delta. Rejects deterministically with {error} on an unknown field, a field not allowed at this scope_type, a secret-shaped value, a machine-local absolute path (outside the field's path_allowed_from_layer), an unsafe/destructive shell command (executor_config.test_cmd/deploy_cmd), or a malformed capability_manifest_ref. expected_revision enables optimistic concurrency: omit it for last-write-wins, or pass the revision you last read from get_profile_layer to fail with a structured {error, code: 'STALE_REVISION', current_revision} instead of silently clobbering a concurrent write. override_reason is accepted for forward symmetry with the narrow_only-widen override knob used at resolve time (get_effective_profile) but this tool itself never blocks a write on it — narrow_only/safe_direction enforcement happens at MERGE time, not write time, since a layer may legitimately declare any value for a field it owns. An idempotent no-op resave (identical fields/reset_fields) returns the current row unchanged with no revision bump. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
search_all
read-only
limitquery*expandproject_idproject_name
[SUPPORT] Read-only: Universal search across all project content: tasks, notes, pinned decisions, and sprint items. Uses LIKE matching (SQLite) or ILIKE (Postgres). Returns grouped… [SUPPORT] Read-only: Universal search across all project content: tasks, notes, pinned decisions, and sprint items. Uses LIKE matching (SQLite) or ILIKE (Postgres). Returns grouped results: {tasks, notes, decisions, sprint_items, total}. sprint_items default-collapse any parent_id/item_group cluster (2+ items) into one summary row — pass expand=true for the full ungrouped list.
search_code_semantic
read-only
kindlimitquery*reindexroot_dir*
[SUPPORT] 93fce816 — Cursor-style LOCAL semantic code search over a source tree, entirely in a DuckDB sidecar (no cloud round-trip). Parses Python (stdlib ast) and TypeScript/JavaS… [SUPPORT] 93fce816 — Cursor-style LOCAL semantic code search over a source tree, entirely in a DuckDB sidecar (no cloud round-trip). Parses Python (stdlib ast) and TypeScript/JavaScript (tree-sitter) into SEMANTIC CHUNKS at function/class/method boundaries PLUS the un-named logical blocks that a named-symbols-only graph search can't reach (module-level dict/list literals, bare calls, __main__ guards, imports) — so a term that only appears in a bare top-level call is still findable. Incremental by a content MERKLE TREE: the root hash is compared first and only divergent subtrees are walked, so only the files that actually changed since the last pass are re-chunked (repeat calls on an unchanged tree are near-free). Search is HYBRID — DuckDB native FTS (Okapi BM25) for keyword match, fused via Reciprocal Rank Fusion with an OPTIONAL local-embedding vector leg (DuckDB VSS / HNSW cosine over a Model2Vec static model) when MERIDIAN_CODE_INDEX_VECTORS is enabled; with vectors off (the default) it is a complete pure-BM25 code search. Returns {root_dir, query, total_indexed, vectors_enabled, vectors_active, hits:[{chunk_id, path, language, kind, name, line_start, line_end, content, score, bm25, bm25_rank, vector_rank}]}. A missing dir / empty tree returns an empty hits list, never an error.
search_outputs
read-only
limitquery*max_secondsoutputs_dir*include_archival
[SUPPORT] a0e9133e — READ-ONLY full-text search over a run's OUTPUTS tree (numeric/tabular/array artifacts), backed by DuckDB native FTS (Okapi BM25). Walks outputs_dir recursively… [SUPPORT] a0e9133e — READ-ONLY full-text search over a run's OUTPUTS tree (numeric/tabular/array artifacts), backed by DuckDB native FTS (Okapi BM25). Walks outputs_dir recursively and builds a persistent index: each .csv/.json contributes its extracted TEXT content plus a cheap fingerprint (CSV column names / JSON top-level keys / an inferred generating_script); each .npy contributes METADATA ONLY (never array content); images/other binaries contribute filesystem metadata + name only. The multi-word query is scored with BM25 and ranked hits are returned. Canonical-vs-archival is handled TWO-STAGE and is NEVER destructive: a filename heuristic (_old / _old_N / leading underscore) flags a CANDIDATE, and a SHA-256 content hash CONFIRMS — an archival copy byte-identical to its canonical twin is DEPRIORITIZED in ranking (is_archival=true, canonical_path set), while a same-name-pattern file whose content DIFFERS is surfaced as its own distinct hit (never collapsed). Nothing is ever deleted or hidden from disk. Pass include_archival=false to drop archival hits entirely. Returns {outputs_dir, query, total_indexed, hits:[{path, score, bm25, is_archival, canonical_path, kind, generating_script, csv_columns, json_keys, size, mtime, annotations:[{path, note, run_params, created_at, updated_at, source}]}]}. annotations is auto-included for each hit (any annotation keyed to the hit path OR a nearest ancestor directory) — no second tool call needed. A missing dir / empty tree returns an empty hits list, never an error. 3535b9ad — pass max_seconds to raise/lower the indexing budget (the "indexing slider"): a large or cold tree may not fully converge within the default budget on the first call — the result's partial=true field signals more indexing remains; call again to continue (each call resumes where the last left off, never restarts).
search_server_logs
read-only
levellimitquery*since
[MAINTENANCE] 222d54f8 — BM25 full-text search over the server_logs ring-buffer. Complements get_server_logs (which filters by level/module/since) with keyword-ranked retrieval — u… [MAINTENANCE] 222d54f8 — BM25 full-text search over the server_logs ring-buffer. Complements get_server_logs (which filters by level/module/since) with keyword-ranked retrieval — useful when you know WHAT went wrong but not exactly WHEN (e.g. search 'OAuth token refresh' or 'psycopg connection pool' across the last 2000 log records). Uses DuckDB native FTS (Okapi BM25) with Porter stemming over a concatenated body of level + logger + message + exc_text. Incremental: re-syncs only new/evicted rows on each call; repeat queries over an unchanged log window are near-free. Ring-buffer eviction is handled consistently — rows pruned from server_logs are removed from the FTS index on the next call. Returns {query, total_in_index, count, hits:[{id, level, logger, message, exc_text, recorded_at, score, bm25}]}. Empty/no-match query returns {hits:[]}.
search_synthesis
read-only
limitquery*project_idproject_name
[SUPPORT] Read-only: Natural-language search that returns a short, CITED answer (which notes/items it drew from) synthesized over the same retrieval as search_all — not just a list… [SUPPORT] Read-only: Natural-language search that returns a short, CITED answer (which notes/items it drew from) synthesized over the same retrieval as search_all — not just a list of matches. Uses a cheap Haiku call when ANTHROPIC_API_KEY is set, with a deterministic fallback to the raw results (synthesized=false) otherwise. Returns {query, answer, cited, synthesized, results}.
search_tasks
read-only
limitquery*project_idproject_name
[SUPPORT] Read-only: Search tasks by keyword or natural-language query. Uses trigram similarity on Postgres, LIKE on SQLite. Returns top matches with similarity score. [SUPPORT] Read-only: Search tasks by keyword or natural-language query. Uses trigram similarity on Postgres, LIKE on SQLite. Returns top matches with similarity score.
send_message
kindpayload*project_idproject_nameto_session_id*from_session_id
[MAINTENANCE] PARALLEL COORDINATION (d3a3a01d): enqueue an actor-model message to another session (session_messages table). 'Done with X, you do Y' between parallel agents. The rec… [MAINTENANCE] PARALLEL COORDINATION (d3a3a01d): enqueue an actor-model message to another session (session_messages table). 'Done with X, you do Y' between parallel agents. The recipient reads with receive_messages. A2A-compatible. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
set_active_repo
repo_pathworktree_id
[MAINTENANCE] Update the tunnel's active Serena repo at runtime. When a planning session switches to a different codebase, call this so subsequent Serena requests (find_symbol, fin… [MAINTENANCE] Update the tunnel's active Serena repo at runtime. When a planning session switches to a different codebase, call this so subsequent Serena requests (find_symbol, find_referencing_symbols, etc.) route to the new repo without restarting the tunnel. Has no effect when no tunnel is connected. 32ba4125 — pass worktree_id instead of repo_path to activate a REGISTERED git worktree (one created via create_worktree / POST /projects/{id}/worktrees) as a validated code-intel context: the repo_path is resolved server-side from that worktree's own record, so an unregistered/arbitrary path can never be activated this way, and the response's `worktree` field carries fingerprint metadata (worktree_id, project_id, branch, path, registered_at). Passing repo_path directly is unchanged and still works for any path (main-repo/non-worktree use). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
set_agent_instructions
project_idinstructions*project_name
[MAINTENANCE] Set or update the custom agent_instructions for a project. Instructions are injected into every start_session response so AI sessions see them automatically — no need… [MAINTENANCE] Set or update the custom agent_instructions for a project. Instructions are injected into every start_session response so AI sessions see them automatically — no need to repeat in every session. Pass null or empty string to clear. Use for persistent rules like coding conventions, deploy steps, or codebase notes. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
set_capability_manifest
project_idcapabilities*project_name
[SUPPORT] 649e095f — Persist a project's structured capability manifest: a list of capability declarations, each with id, purpose, required_tools (non-empty list of tool/server nam… [SUPPORT] 649e095f — Persist a project's structured capability manifest: a list of capability declarations, each with id, purpose, required_tools (non-empty list of tool/server names), optional fallback_chain, optional provenance (string or object), availability_policy ('required'|'optional'|'degraded_ok', default 'required'), and an optional verification_command. REPLACES the existing manifest wholesale (not a merge). Rejects deterministically with {error} on any unknown/missing field, duplicate capability id, secret-shaped value, or machine-local absolute path — manifests are shared, multi-machine project state, never a place for secrets or one executor's local filesystem layout. Normalizes to a stable, sorted-by-id order so the same capability set always hashes identically regardless of input order. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
set_capability_profile
scope_id*provenancescope_type*capabilitiesdisabled_capability_ids
[SUPPORT] 02038afe — Persist ONE layer of the capability-inheritance chain: workspace -> user -> project -> sprint_version -> item (least to most specific). scope_type selects the… [SUPPORT] 02038afe — Persist ONE layer of the capability-inheritance chain: workspace -> user -> project -> sprint_version -> item (least to most specific). scope_type selects the layer; scope_id is that layer's key (a tenant/workspace id for 'workspace', a user/human id for 'user', the project_id for 'project', the sprint item's id for 'item', or the project_id for 'sprint_version' — the sprint version itself is resolved from whichever sprint item you query via get_effective_capability_profile). capabilities uses the exact same schema as set_capability_manifest and REPLACES this scope's capabilities wholesale (not a merge). disabled_capability_ids explicitly retracts capability ids this scope inherited from a less specific layer, without redeclaring them — that list also REPLACES whatever was previously disabled at this scope. provenance is an optional object recording non-secret context (e.g. config source label, a config/tool-list hash, observed_at, client/server identity, fallback policy) — never raw secrets or machine-local absolute paths, rejected the same way set_capability_manifest rejects them. Use clear_capability_profile to remove a scope's row entirely instead of replacing it with an empty one. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
set_executor_config
branchenv_filetest_cmdtest_minmax_turnsrepo_path
+10
[MAINTENANCE] Store per-project executor defaults (repo_path, env_file, test_cmd, test_min, deploy_cmd, shell_type, branch). Merges onto the existing config — other keys (hostnames… [MAINTENANCE] Store per-project executor defaults (repo_path, env_file, test_cmd, test_min, deploy_cmd, shell_type, branch). Merges onto the existing config — other keys (hostnames, filesystem_roots, …) are preserved. Pass repo_paths as an array of {cwd, hostname} known locations; they are merged into the existing repo_paths (deduped) rather than overwriting, so manual + hook-registered entries coexist. Executor sessions auto-load these when start_session(role='executor') is used. Credentials rule is always injected separately: read secrets from env_file only, never remote shell. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
set_goal
content*project_idproject_name
[MAINTENANCE] Set or update the goal state. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisi… [MAINTENANCE] Set or update the goal state. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
set_north_star
north_star*project_idproject_name
[MAINTENANCE] Update only the north star — the long-lived product vision that rarely changes. Distinct from the version goal (set_goal). Any team member can call this. Persistent-s… [MAINTENANCE] Update only the north star — the long-lived product vision that rarely changes. Distinct from the version goal (set_goal). Any team member can call this. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
set_parent_project
project_idproject_nameparent_project_idparent_project_name
[MAINTENANCE] 7acb8563 — set, change, or clear a project's parent AFTER creation (create_project only accepted parent_project_id at creation time). Use this to retroactively nest a… [MAINTENANCE] 7acb8563 — set, change, or clear a project's parent AFTER creation (create_project only accepted parent_project_id at creation time). Use this to retroactively nest a project under another, or to detach it. Enforces the one-level-deep invariant (3b6ff466): the parent must exist and be top-level, a project can't be its own parent, and a project that already has subprojects can't become one. Omit parent (or pass empty) to DETACH — make it top-level. Returns the updated project; {error} on an invariant violation. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
set_sprint
forcesprint*project_idproject_name
[MAINTENANCE] Update only the sprint — the short-term focus that changes each session or week. Any team member can call this; no ownership check. If pending items from the current… [MAINTENANCE] Update only the sprint — the short-term focus that changes each session or week. Any team member can call this; no ownership check. If pending items from the current sprint were never started, returns a WARNING block listing them. Pass force=true to override and overwrite anyway. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
snapshot_graph_metrics
project_idsession_id*project_name
[MAINTENANCE] Record a code-graph snapshot for a session (node count, edge count, hotspot count, file churn). Call at session start and end to enable get_graph_diff comparisons. Pe… [MAINTENANCE] Record a code-graph snapshot for a session (node count, edge count, hotspot count, file churn). Call at session start and end to enable get_graph_diff comparisons. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
social_search
read-only
limitquery*sourcesort_by
[SUPPORT] Search public social-media / discussion content — a REAL external lookup (keyless), sibling to paper_search but for social discussion rather than academic papers. Current… [SUPPORT] Search public social-media / discussion content — a REAL external lookup (keyless), sibling to paper_search but for social discussion rather than academic papers. Currently one keyless source via the 'source' param: 'hn' (default; Hacker News via the Algolia HN Search API, story submissions only, not raw comments). Returns {query, count, results:[{title, authors, summary, published, url, discussion_url, points, num_comments, hn_id, ...}]}.
split_sprint_item
titles*item_id*project_idproject_name
[SUPPORT] Split a sprint item into multiple smaller items. The original is closed (skipped) and N new items are created with split_from referencing the original. Returns list of ne… [SUPPORT] Split a sprint item into multiple smaller items. The original is closed (skipped) and N new items are created with split_from referencing the original. Returns list of new items. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
start_session
moderoleclientcompactversionhuman_id
+3
Register a session and return orientation. Compact by default (session_id, sprint focus + status counts, 3 recent tasks, board_change count) to keep an executor's context small. Pa… Register a session and return orientation. Compact by default (session_id, sprint focus + status counts, 3 recent tasks, board_change count) to keep an executor's context small. Pass compact=false for the full block (goal XML, decisions, MERIDIAN.md instructions, workspace context, sprint items) — or fetch it later with get_session_brief. Pass version to scope the session to one sprint-version bucket (e.g. 'v0.1.x'): the orientation's sprint counts/items filter to it and the scope is remembered for the /goal template. Omit version to auto-scope to the bucket with the most pending items (empty board → unscoped). Also returns capability_contract (98aaccf4): a machine-readable {requested, effective, availability, manifest_hash, executable, executable_reasons, generated_at} object describing the project's declared capabilities and whether an executor can run right now — null if contract-building failed. Also returns execution_policy (75ac1c8e): a machine-readable {execution_mode, max_planning_turns, required_first_action, no_confirmation, permitted_parallel_wave, claim_before_edit, genuine_blocker_escalation} object — 'immediate' (default) names the exact first tool call to make and bounds planning turns before it; 'relaxed' is the explicit ask-first/planning posture. Derived from the project's execution_mode; max_planning_turns is executor_config-overridable via set_executor_config. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
start_wave_run
actorversionitem_idsproject_idwave_labelproject_name
+2
[SUPPORT] 2a654cb0 — DURABLE WAVE STATE: open a wave run before dispatching a parallel wave. Returns an immutable wave_run_id pinned to the canonical expanded board snapshot (revis… [SUPPORT] 2a654cb0 — DURABLE WAVE STATE: open a wave run before dispatching a parallel wave. Returns an immutable wave_run_id pinned to the canonical expanded board snapshot (revision_hash + monotonic revision_counter) the wave was planned against, so a session that dies mid-wave can be resumed against a manifest whose staleness is DETECTABLE instead of assumed. The snapshot is built server-side — you cannot supply one, because the point is to pin what the server saw. Pass item_ids (the sprint items in this wave) and optionally failure_modes ({item_id: 'stop'|'continue'}) to register them as children up front: a failed 'stop' child then structurally BLOCKS finalize_wave_run. degraded_tools ([{tool, reason, fallback}]) records which tools were unavailable while the wave ran, so a later reader knows the evidence quality. Returns {wave_run_id, run, children, revision_hash, revision_counter}. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
store_finding
keytitlecontent*task_idproject_idsession_id
+1
[MAINTENANCE] PARALLEL COORDINATION (c35370cc): persist a per-task intermediate result to the session_findings table so it survives session boundaries. Parallel reader agents write… [MAINTENANCE] PARALLEL COORDINATION (c35370cc): persist a per-task intermediate result to the session_findings table so it survives session boundaries. Parallel reader agents write findings; an orchestrator or writer agent reads them via get_findings. Unlike save_finding (which creates a research note), this is a lightweight key→content store for agent-to-agent handoff of intermediate work. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
update_custom_hook
nameeventenabledhook_id*matcherblocking
+4
[MAINTENANCE] b4f4627f — the previously-missing generic enable/disable/edit path for a user-defined hook (id returned by add_custom_hook / get_custom_hooks): patches name, event, m… [MAINTENANCE] b4f4627f — the previously-missing generic enable/disable/edit path for a user-defined hook (id returned by add_custom_hook / get_custom_hooks): patches name, event, matcher, script_sh, script_ps1, blocking, and/or enabled without the delete+recreate round-trip add_custom_hook/delete_custom_hook would otherwise require. At least one editable field is required. Renaming re-derives the slug (same reserved-name / uniqueness checks as add_custom_hook); the db layer raises ValueError for a bad event, the reserved 'sprint_guard' name, or a slug collision — surfaced as {error}. Returns {error} (never raises) when hook_id doesn't resolve for this project. Flipping enabled true -> false also removes any already-written .claude/hooks/<slug>.* files immediately (best-effort, when the project has a resolvable repo_path) instead of waiting for the next generate_handoff to simply stop re-writing them — reported back as removed_files when any were deleted. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
update_decision
bodytitlestatuscategorynew_bodypriority
+4
[SUPPORT] Patch a pinned decision. Pass new_title + new_body to atomically supersede (creates a new active row, marks old as superseded with back-link). Otherwise patches body/titl… [SUPPORT] Patch a pinned decision. Pass new_title + new_body to atomically supersede (creates a new active row, marks old as superseded with back-link). Otherwise patches body/title/category/status/priority in place. Editing the body appends the previous body to the append-only edit_log (read it back via get_pinned_decisions). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
update_md_section
file*forceanchor*content*urgencyproject_id
+2
[MAINTENANCE] Propose a replacement for an anchored section of an agent template doc (CLAUDE.md or AGENTS.md). Does NOT write the file directly — it creates a human-in-the-loop req… [MAINTENANCE] Propose a replacement for an anchored section of an agent template doc (CLAUDE.md or AGENTS.md). Does NOT write the file directly — it creates a human-in-the-loop request carrying a diff preview. A human approves it in the dashboard, then Meridian replaces that section and stages the file for the next checkpoint commit. 'anchor' is the section name between the MERIDIAN:ANCHOR:START/END comments. (ROADMAP/DECISIONS/DEVLOG are append-only and not replaceable.) Pass force=true from a human planning session (claude.ai) to skip the HITL and apply the replacement directly; autonomous executor sessions should omit force so the diff stays gated. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
update_paragraph
doc*runspara_id*new_textproject_idsession_id
+4
[MAINTENANCE] f978e588 — ID-addressable docx WRITE (the write counterpart of the get_element_by_id / paraId read primitive). Targets ONE paragraph in a stored .docx by its w14:para… [MAINTENANCE] f978e588 — ID-addressable docx WRITE (the write counterpart of the get_element_by_id / paraId read primitive). Targets ONE paragraph in a stored .docx by its w14:paraId (the 'p{index}' fallback Word writes for an unlabelled paragraph) — NEVER by text match — rewrites its runs, saves the .docx in place, and re-syncs the doc_elements index row so it matches the new text. The document must already be stored in the doc-structure store via ingest_document (which registers a docx/latex document's structure here). Pass the SAME source/path you ingested under as `doc`. Provide EXACTLY ONE of: `new_text` (a plain string — one unformatted run) OR `runs` (a list of runs, each a bare string or {text, bold?, italic?, underline?} — basic run formatting is applied; the paragraph's original run formatting is replaced, not merged; its paragraph style/numbering is preserved). Returns {document_id, para_id, new_text, elements_resynced, source_path}. elements_resynced is 0 for a plain body paragraph (only headings are persisted as elements) — that is expected, not a failure. Errors (never a silent no-op) when the doc/source/para_id doesn't resolve. f7ee1ba7 — pass session_id to enable scoped-region claim enforcement: if another session has claimed the target para_id (or holds a whole-file lock), the write is REJECTED with error='docx_region_conflict'. Use claim_docx_region to acquire your region before writing. 5988a5bb — mandatory post-write verification now re-reads the file from disk and confirms the target paragraph's text actually landed before this ever reports success; on a rare verification failure the write is best-effort restored from backup and an error is returned instead. Response also now includes pre_counts/post_counts (the media/style/equation/relationship structural manifest from before and after the write). Three further OPT-IN parameters (each omitted by default, byte-identical behavior when omitted): expected_content_hash — a fail-closed precondition: if the source file's current on-disk content hash doesn't match, the write is REJECTED before anything is touched (get the current hash from a prior get_document_structure/get_structure staleness check). draft_output_path + wave_run_id (both-or-neither, with session_id also required) — writes to an ISOLATED draft path instead of the canonical file, claiming the paragraph as this wave's anchor via the real docx-merge manifest so a conflicting concurrent draft on the same paragraph is rejected; response carries draft_path/wave_run_id/ is_draft instead of elements_resynced (the canonical index is not touched until a merge). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
update_sprint_item
wavegroupnotestitletrackpolicy
+19
[SUPPORT] Edit fields on an existing sprint item: title, version, notes, human_id (assignee), group, deferred_until (enforced deferral), track, or depends_on (dependency ordering).… [SUPPORT] Edit fields on an existing sprint item: title, version, notes, human_id (assignee), group, deferred_until (enforced deferral), track, or depends_on (dependency ordering). Only the fields you pass are changed; omitted fields are left untouched. Pass an empty string for human_id, group, deferred_until, track, or depends_on to clear it. Returns the updated item, or an error if the id is unknown. For TWO OR MORE independent item patches, prefer the single execute_batch(operation='item_updates', entries=[...], mode='best_effort' or 'all_or_nothing', idempotency_key='...') call instead of repeating this tool: it validates and reports each item in input order, supports per-item correlation_key values, and makes retries idempotent. Use best_effort when one invalid item must not block the rest; use all_or_nothing when the whole patch set must succeed together. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
update_workspace_settings
handoff_templatetool_priority_mapsprint_name_defaultloop_enabled_defaultexecution_mode_defaultclaim_verification_mode
+2
[MAINTENANCE] Update workspace-global default settings. Pass only the fields you want to change. hitl_auto_answer_default (bool) seeds new projects' HITL auto-answer behaviour; spr… [MAINTENANCE] Update workspace-global default settings. Pass only the fields you want to change. hitl_auto_answer_default (bool) seeds new projects' HITL auto-answer behaviour; sprint_name_default (string) is the default sprint name; handoff_template (string) overrides the default full-mode handoff with a custom template — supports {{sprint}}, {{recent_tasks}}, {{decisions}}, {{north_star}}, {{version_goal}}, {{pending_items}}, {{notes}} placeholders. execution_mode_default ('autonomous'|'interactive', '' to clear) and code_intel_enabled_default (bool) are cascade defaults seeded onto NEW projects in this workspace (existing projects are unchanged). loop_enabled_default (bool) is the workspace default for /loop auto-continue that projects inherit when their loop_enabled is 'workspace'. tool_priority_map (object) sets a durable default MCP tool per semantic task category (e.g. {"code-reading": "Serena: find_symbol"}) — generalizes the per-item required_tool pin up one level; rendered as a HARD, unconditional directive in every /goal for matching pending items that have no item-level required_tool override. Pass {} to clear it. claim_verification_mode ('off'|'advisory'|'strict', '' to clear back to 'off') controls whether a PostToolUse hook re-checks claim_sprint_item/complete_sprint_item calls against live sprint-item state before trusting the calling session's own narration: 'off' = no check; 'advisory' = logs a warning on mismatch but never blocks; 'strict' = blocks the session on mismatch. Pass an empty string to revert a field to the server default. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
update_workspace_sprint_item
grouptitlestatusitem_id*human_id
[MAINTENANCE] Edit a workspace personal-backlog item: title, status, group, or human_id (assignee). Only the fields you pass are changed. Pass an empty string for group/human_id to… [MAINTENANCE] Edit a workspace personal-backlog item: title, status, group, or human_id (assignee). Only the fields you pass are changed. Pass an empty string for group/human_id to clear it. Setting status to done/skipped/failed stamps completed_at. Returns the updated item. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
validate_assumption
symbolfinding*confirmed*file_pathsession_iddecision_id*
[SUPPORT] Confirm or invalidate the assumption a pinned decision rests on, in one call — no phase switching. Stamps the decision's assumption_status (confirmed|invalidated), saves… [SUPPORT] Confirm or invalidate the assumption a pinned decision rests on, in one call — no phase switching. Stamps the decision's assumption_status (confirmed|invalidated), saves a code-anchored note with your finding, and when confirmed=false fires a BLOCKING HITL so work depending on the decision pauses for human judgment. Use the moment you discover whether an assumption holds (a planning-session prospect moment). Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets.
verify_handoff_token
read-only
token*project_idproject_namepresented_body