Servidor MCP de Damper

• Nombre en el registrocom.usedamper/mcpverificado en el registro MCP

El nombre en el registro está bajo usedamper.com. El registro solo permite usar ese espacio de nombres a quien demuestra control del dominio por DNS o HTTP.

• Estadorespondecomprobado el 2026-10-30
• Herramientas141
• El servidor se llamadamper
• Versión del servidor0.6.0
• Versión del protocolo2025-06-18

El 2026-10-30 el servidor respondió a initialize y tools/list sin iniciar sesión. Primera respuesta en 251 ms.

• Aún no se ha juzgado si sus herramientas hacen el trabajo del producto.
• Comprobado 3 de los 7 días necesarios para juzgar su fiabilidad.

Lo dicen reglas a partir de las mediciones de arriba. La primera llamada probable la elige un modelo de la lista de herramientas; lee su descripción antes de fiarte.

• Nota INITE MCPtras una semanala nota necesita 7 comprobaciones diarias: 3 hasta ahora
• Respondiómidiendo3 de las 7 comprobaciones diarias necesarias para mostrar el porcentaje
• Mediana de la primera respuesta268 ms
• Espacio en el contexto del agente≈ 38.399 tokenslas definiciones de todas sus herramientas (141), que el agente lleva en cada turno
• Definiciones de herramientasB · 89 de 100
• Resultados tipados141 de 141 herramientasdeclaran outputSchema: el resultado llega tipado y se lee de una vez

• Parámetros sin tipo: en 1 de 141
• Parámetros sin descripción: en 96 de 141

Un programa comprueba el servidor una vez al día: initialize y tools/list, sin modelo. Los tokens son la longitud de las definiciones, a unos cuatro caracteres por token. La nota promedia seis comprobaciones del nombre, la descripción, el esquema y las anotaciones de cada herramienta; dice lo bien descritas que están, no si funcionan. La nota pondera solo lo medido: si responde (25%), si hace el trabajo del producto (25%), definiciones (20%), contexto (10%), uso (10%) y lo fácil que es conectarse (10%). Lo que no se midió queda fuera, y una instrucción oculta limita la nota a 40. El estado de los servidores MCP de los proveedores: método y números →

• list_projects

  List all projects accessible with this API key. Use this to find project IDs for other tools. **Start here** to discover which projects you can work with.

• get_agent_instructions

  Get the canonical Damper workflow instructions. Use this to set up or update CLAUDE.md in a project.

• list_tasks

  Get roadmap tasks. Returns backlog/planned/in-progress by default. Search by title, description, plan, user story, or exact label, and filter by type, quarter, etc. Use `query` before paginating when checking whether a matching task…

• get_task

  Get task details. Defaults to a compact view (plan, current progress, subtasks, PRs, unresolved decisions, completion receipt, evidence counts) — no `agentNotes` dump. Pass `detailMode: "full"` for the legacy full payload (agentNotes, all…

• list_self_assessments

  List recent structured agent self-assessments for a project. Use this miss log to find recurring missingContext/toolIssues/processGaps and improve project context.

• update_task

  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…

• create_task

  Create a new roadmap task. Use for importing from TODO files or creating work items. When the task comes from customer feedback, pass `feedbackIds` to link it in the same call: the feedback status follows the task and followers are…

• add_note

  Add a note to a task, or resolve a previously reported blocker/open_question. Use ONLY for non-obvious approach decisions and blockers — do not restate commits, checklist confirmations, or self-assessment findings here; those are already…

• add_commit

  Log a commit for a task (secondary detail — the linked pull request is the primary deliverable, see `link_pr`). **When to use:** - After a notable commit: log hash and message - When completing work: optionally pass commits to…

• link_pr

  Link the pull request that delivers this task. The PR is the primary deliverable of a task — call this as soon as the PR exists, and call it again with `state: "merged"` after merge. Upserts by URL, so repeated calls update the same PR…

• create_subtask

  Add a new subtask to a task. Useful for breaking down work into smaller steps. Optionally set startDate/dueDate (YYYY-MM-DD) so the subtask appears on the roadmap timeline.

• update_subtask

  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.

• delete_subtask

  Remove a subtask from a task. Use get_task to see subtask IDs.

• delete_task

  Permanently delete a task. Only works on tasks in backlog or planned status with no commits.

• add_task_dependency

  Add a dependency between roadmap tasks. The blocker task must be done before the blocked task can be worked on. Provide either blockerId (this task is blocked by another) or blockedId (this task blocks another).

• remove_task_dependency

  Remove a task dependency by dependency ID.

• add_api_example

  Attach a request/response example for an API endpoint you added or changed, so the reviewer can check the contract in Damper without running anything. Add one per changed endpoint (more for distinct cases, e.g. success and validation…

• add_screenshot

  Attach a screenshot of a page or screen you added or changed, so the reviewer sees the result in Damper. Capture every changed page in each relevant state (default, empty, loading, error, validation…), using the locale/theme/viewport the…

• add_diagram

  Attach a Mermaid diagram that explains the logic or structure behind a change, so the reviewer can follow it without reading the diff. OPTIONAL — add one only when it clarifies something a list of endpoints or screenshots cannot: a…

• list_review_artifacts

  List the API examples, screenshots and diagrams attached to a task, with the reviewer's verdict on each (approved / changes_requested + comment). Use it to check coverage before complete_task, and to find artifacts a reviewer asked you to…

• remove_review_artifact

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

• start_task

  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…

• review_task

  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…

• complete_task

  Mark task as ready for review (in_review). A human will verify and move it to done. Pass `skipReview: true` to mark as done immediately (use when the human explicitly asks). If the task is already in_review (put there by a previous…

• request_review

  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…

• abandon_task

  Release lock and return task to planned status. Works for in_progress and in_review tasks. **Before calling:** 1. Push any WIP commits **Summary parameter:** What was done, what remains, blockers. Helps the next agent.

• list_context_sections

  List available project context sections with brief previews.

• resolve_context

  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.

• get_context_section

  Get full content of a specific context section. Supports glob patterns for hierarchical sections. **Hierarchical paths**: For monorepos or large projects, sections can be organized hierarchically (e.g., "api/architecture"…

• update_context_section

  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…

• delete_context_section

  Delete a project context section. Use when documentation is outdated or no longer relevant.

• sync_project_context

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

• get_project_context

  Get project context index (token-efficient). Returns section list with previews. Use get_context_section to fetch full content for sections you need. **IMPORTANT:** Call this at session start. Contains architecture, conventions, and…

• get_section_blocks

  Get a block index for a context section. Returns headings with character counts. Use to selectively load only relevant parts with `get_section_block_content`.

• get_section_block_content

  Get the full content of specific blocks within a section. Use `get_section_blocks` first to see available block IDs, then fetch only the ones you need.

• prepare_work

  Build a deterministic, compact work packet with governing context, a shadow graph comparison and provenance, path-owned surfaces, checklist scope, project verification, unvalidated route-fixture representation, instruction drift, and…

• audit_context_health

  Find invalid route taxonomy, weak or uncovered fixtures, missing baselines, route overlap, stale knowledge, and fallback usage.

• get_context_graph

  Inspect the typed graph projection derived from context routes, sections, bundles, modules, and optional project-authored relationships.

• resolve_context_graph

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

• list_context_relations

  List project-authored typed relationships layered over the derived context graph.

• upsert_context_relation

  Create or update an explicit typed relationship. Existing routes, bundles, modules, and section metadata remain authoritative; use relationships for missing cross-surface or semantic links.

• delete_context_relation

  Delete a project-authored context relationship. Derived graph edges are not mutable through this tool.

• list_context_routes

  List structured path-to-context routes in priority order.

• upsert_context_route

  Create or update a validated structured context route.

• delete_context_route

  Delete a structured context route by name.

• preview_context_route_migration

  Parse Markdown routing into structured route candidates without writing them.

• validate_context_routing

  Run project route fixtures against the production context resolver.

• compare_context_resolution

  Compare structured routing output with legacy Markdown routing for repository paths.

• list_context_bundles

  List versioned context bundles and recent versions.

• upsert_context_bundle

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

• get_context_bundle

  Get a context bundle with immutable version snapshots, optionally selecting one version.

• delete_context_bundle

  Delete a context bundle and its version history.

• list_context_fixtures

  List executable context routing expectations.

• upsert_context_fixture

  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…

• report_context_feedback

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

• delete_context_fixture

  Delete an executable routing fixture by name.

• prepare_completion

  Resolve final touched paths, compare them with the prepare_work snapshot, detect version drift and scope expansion, and generate context disposition evidence. Also returns `reviewEvidence` for the final scope: which screenshots, API…

• preview_context_update

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

• patch_context_section

  Apply stable-block operations with optimistic concurrency and immutable version snapshots.

• upsert_context_block

  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.

Las primeras 60 de 141, en el orden del servidor.