Damper

Preview how a legacy flat completion checklist could be regrouped into native V2. Flags broad items, command-dump style items, and title-derived ids before writing the migrated document.

Parse Markdown routing into structured route candidates without writing them.

Preview a section replacement or stable-block patch, including semantic changes and sensitive-data warnings, without writing.

Publish a changelog with optional email and Twitter notifications.

Read a bounded page of database rows using metadata or property filters, stable cursor pagination, a resumable polling cursor, and optional property/content projection. Custom date properties support comparison filters via propertyId and sorting via sort.propertyId (empty dates last). Dates use YYYY-MM-DD strings. Use updatedAt ascending (the default) for incremental polling; other sort cursors are for pagination only. Full projected rows are included in text and structured output. For array properties, in matches any supplied member while contains requires every supplied member. Prefer this over get_page_database for polling or growing databases.

Aggregate privacy-safe feedback, self-assessment gaps, and fallback telemetry; may auto-create private tasks when project policy enables it.

Remove an API example, screenshot or diagram from a task, by id or by kind + key (e.g. a page that no longer changes).

Remove a task dependency by dependency ID.

Render the canonical structured route mapping as deterministic generated Markdown.

Reply to a feedback item as a team member. The reply will be visible to the customer. Send follow-up info to the feedback author by setting `notifyCustomer` (emails them) and optionally adding up to 3 `attachments` (PNG/JPEG/WebP/GIF screenshots, 3 MB each) that appear in the email and on the public feedback page.

Report missing, irrelevant, or incorrectly routed knowledge without storing prompts or source code.

Report an error, bug, or feature request with MCP tools or suggest improvements. Reports that contain personal data, secrets, or chat transcripts are kept private automatically.

Lightweight hand-off into review: move an in_progress task to in_review as soon as a human could review it (a working slice, an opened PR, attached screenshots or API examples, or when you are about to stop for the session). Do not leave reviewable work in in_progress. No checklist, PR, or self-assessment is required, and **no user confirmation is needed** — it is reversible and does not commit or merge. `complete_task` still needs confirmation. **Requirements:** the task must be in_progress and you must hold its lock (from start_task). **Effect:** status becomes in_review, the lock is released (so reviewers can act on it), and your session is closed. A reviewer approves or sends it back with feedback; resume with `start_task` if it comes back. **Stage:** `complete` (default) means the task is finished pending review. `partial` means a reviewable slice with more work to follow: approving it returns the task to in_progress instead of done. `complete_task` on a task waiting for a stage review requested here is rejected until the reviewer decides. **Review evidence:** the hand-off is checked against the project's review evidence policy for the change scope: `checklistScope` and `touchedPaths` passed here, unioned with what `prepare_completion` recorded; `prepare_work`'s expected paths count per the project's `plannedScope` (default: only when nothing else is known). Each kind's level comes from its base level and the project's rules; preview it with `get_completion_checklist` and your scope. Missing **required** API examples, screenshots or diagrams block it with error code `review_evidence_missing`, naming each missing kind and the change kinds/surfaces that need it. Attach them (`add_api_example`, `add_screenshot`, `add_diagram`) or, when they genuinely do not apply, pass `evidenceNotApplicable` with the reason (recorded on the timeline). A `partial` stage only warns unless the project sets `partialStageEvidence: "block"`; projects with `checkDirectDone` also c…

Resolve touched file paths to governing context sections, critical rules, risk domains, and suggested checklist scope. Uses routing/path-to-context when present and falls back to module paths plus section metadata.

Run bounded shadow-mode graph traversal for repository paths. Returns ranked context candidates and full provenance without changing authoritative route resolution.

Optional standalone self-review step. You can also pass `selfAssessment` directly to `complete_task` instead. Reflect on your session: what project knowledge was missing, what tools were confusing, what process gaps caused friction. This drives project improvements. If you have findings, propose improvements to the user after this call (e.g., `update_context_section` for missing docs, `report_issue` for tool problems).

Run a monitor now and record the result. The outcome feeds the monitor state and may open or resolve an automated incident.

Search pages and linked project knowledge by title/content.

Lock and start a task. Fails if locked by another agent unless force=true. Use force=true to take over a task from another agent (e.g., if they abandoned it). Returns project context index with relevant sections for the task. If the reviewer decided your latest review request, the response starts with a `latestReviewRound` feedback block: address it before anything else. **IMPORTANT:** After starting, use get_context_section to read relevant sections. Project context contains architecture and patterns you MUST follow. **Workflow after starting:** 1. Read relevant context sections (architecture, conventions, etc.) 2. Do work on a feature branch 3. Open a pull request for the change and link it with link_pr — the PR is the deliverable 4. request_review as soon as something is reviewable (no user confirmation needed), or when stopping for the session 5. complete_task (done) or abandon_task (stopping)

Bulk upload multiple modules at once.

Bulk upload all project context sections at once. Use after analyzing a codebase. ⚠️ SECURITY WARNING: Do NOT include sensitive information.

Bulk upload multiple templates at once.

Update a changelog entry.

Upload/update a project context section. Use after analyzing local codebase. This action shares documentation with the Damper project for future AI agents. **When to use hierarchical names**: For monorepos or large projects, use paths like `api/architecture`, `api/testing` to organize by module. For simple projects, flat names like `overview`, `conventions` are sufficient. **criticalRules**: Short, actionable rules that agents MUST follow. These are surfaced automatically in `start_task` and `get_project_context` responses. ⚠️ SECURITY WARNING: Do NOT include sensitive information.

Rename, hide, reorder, or change options/type for a database property. Property type. Relation types: `page` (linked page IDs), `roadmap` (linked roadmap task IDs), `feedback` (linked feedback IDs). Relation values are string arrays and sync PageLink backlinks.

Set database property values for a row page. Values are keyed by property ID. Date values are YYYY-MM-DD strings (for example, 2026-09-13); null clears a value.

Update a database view layout, visible columns, sort, filters, name, or position. Table and list layouts stack one list per value when config.groupByPropertyId is set; config.groupOrder is that group order. Board already groups into columns. Calendar does not stack groups.

Update feedback status or visibility.

Register or update a module in the registry.

Update page title, icon, content, content width, kind, agent visibility, or linked people. If ifUpdatedAt is omitted, the tool reads the latest page timestamp first.

Configure agent-relevant project settings, including the structured completion checklist and the review evidence policy (partial update: per kind a base level, optional trigger change kinds and `*Rules` that raise or lower the level for surfaces, change kinds or risk domains; plus partialStageEvidence, plannedScope and checkDirectDone — see the field descriptions). Preview the result with `get_completion_checklist` and a scope. Also sets `verificationCommands` (project-wide and per-surface commands prepare_work reports; Damper has no built-in defaults). This REPLACES the whole completion checklist document — use `patch_completion_checklist` to amend part of it. Prefer outcome-based proof groups, stable explicit ids, and referenced standards sections instead of command inventories.

Edit an alert recipient, for example to pause it with isEnabled false or change its target. The same type requirements as create apply.

Edit a monitor. Passing headers replaces all stored headers; pass [] to clear them. http and ssl monitors require a public url; heartbeat monitors return a heartbeatUrl for your job to ping. Probe header values are write-only and never returned (hasHeaders reports whether any are set). Creating an enabled monitor runs it once immediately.

Edit a group name, slug, description, sort order or visibility.

Edit incident details, affected component, dates or visibility without notifying anyone. To change the stage, use add_status_incident_update.

Edit maintenance details, schedule, scope or visibility. For a state change with a timeline message, use add_status_maintenance_update. Use list_status_maintenance_targets to choose groupId or checkIds (mutually exclusive). Omit both for all monitors when creating; omit both when editing to preserve scope. Set groupId and checkIds to null to target all monitors. isPublic defaults to true on creation. Public changes queue subscriber notifications for background delivery with retries. Success confirms the change and queue commit, not email delivery. Private windows still suppress monitoring alerts during the active schedule.

Update a subtask: mark it done/not done and/or set its timeline dates. Use get_task to see subtask IDs. Dates are YYYY-MM-DD; null clears a date.

Update task fields like description, implementation plan, priority, effort, quarter, start/due dates, labels, or visibility. Pass status "closed" to discard a task that will not ship. Useful for refining task details as you learn more about the work. Set startDate and dueDate when planning so the task appears on the roadmap timeline.

Create or update a code template.

Replace or append a stable context block while preserving unrelated blocks. The Markdown content must begin with a level-2 or level-3 heading whose generated slug exactly matches blockId.

Create or update a coherent context bundle. Semantic changes record immutable versions; identical retries are no-ops.

Create or update intended executable expectations for an important repository path. Derive assertions from project truth and verified code behavior, never by copying the current resolver output; only write project context when authorized, then run validate_context_routing.