layerdock-mcp

Name: layerdock-mcp
Author: LayerDock

Official

by LayerDock

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

@layerdock/mcp

Read your LayerDock website feedback — with the CSS selector, the screenshot, and the console/network trace captured at report time — directly in your coding agent. Fix the bug, reply on the thread, mark it resolved, without leaving the editor.

Setup

Create a token at https://www.layerdock.io/dashboard/integrations/mcp
Warm the cache first, once, in a terminal:
```
npx -y @layerdock/mcp --version
```
npx downloads the package on first use, and a cold download can take longer than an editor's MCP connect timeout (30s in Claude Code) — so the very first connection fails with CONNECT_TIMEOUT on a server that is working perfectly. Running it once puts it in the npx cache; every launch after that is instant. Skip this and you may simply need to restart your editor once.
Add the config for your client below.

The three clients below are the short version. The full walkthrough — config for Claude Code, Cursor, Codex CLI, Antigravity, Windsurf, VS Code and Zed, how to verify the connection, and what to check when the server does not appear — is at https://www.layerdock.io/docs/connect-your-coding-agent

Claude Code

.mcp.json in your project root:

{
  "mcpServers": {
    "layerdock": {
      "command": "npx",
      "args": ["-y", "@layerdock/mcp"],
      "env": { "LAYERDOCK_TOKEN": "ldk_..." }
    }
  }
}

Cursor

~/.cursor/mcp.json — same JSON as above.

Codex CLI

~/.codex/config.toml:

[mcp_servers.layerdock]
command = "npx"
args = ["-y", "@layerdock/mcp"]
env = { LAYERDOCK_TOKEN = "ldk_..." }

Related MCP server: Browser Feedback MCP

Tools

Tool	What it does
`list_docks`	Your sites, with any codebase hints their owner declared (framework, source root, CMS)
`list_feedback`	Pins, filterable by status. `dockId` is optional — omit it to see open work across every dock you can reach, which is the whole answer to "what needs my attention?" in one call
`get_feedback`	One pin as a fix brief, plus the screenshot as an image. Takes `detail`: `auto` (default), `minimal`, `full`
`update_feedback_status`	Move a pin through the workflow
`reply_to_feedback`	Post a reply on the thread, attributed to you and labelled as coming via a coding agent

What `get_feedback` actually returns

A fix brief, ordered by how actionable each part is:

What the reporter wants changed, plus the reply thread
The component, when the reviewed site is a dev/unminified build — sometimes the source file and line
A repetition warning when the pinned element is one of N identical siblings, so an agent doesn't hardcode a one-item fix into the shared component that renders all of them
A search string that actually matches source — one contiguous run of literal text from a single text node, whitespace collapsed, never cut mid-word. This is deliberately not the element's innerText: that spans child nodes, so it carries newlines and fragments that appear in no source file and a literal grep for it never matches
Where it is — page URL, section, CSS selector, and the full visible text marked explicitly as context rather than as something to grep for
Structure and computed styles at pin time
Console errors and failed/slow requests from the moment of capture, each stamped with how long before the report it happened
The screenshot, as an image block the agent can actually look at — downscaled server-side, and when a pin has no capture the brief says so instead of instructing the agent to consult an image that was never attached

It also states what it cannot tell you — the brief never claims to know your repository layout, and it instructs the agent to locate and confirm the file before editing rather than guessing. That includes the case where the fix is not in the repository at all: if the visible text appears nowhere in the codebase, the content is probably CMS- or API-driven and the fix belongs in the content source. Set a dock's cms field and the brief names the system directly.

Payload size

get_feedback defaults to detail: "auto". A pin that reads as a pure copy change ("fix this wording") does not need ~20 computed CSS properties, device memory, hardware concurrency and network downlink — so those are dropped, and the brief says it dropped them. A layout or behaviour bug keeps everything. Pass detail: "full" to override, or "minimal" to always trim.

Permissions

The token acts as you, and says so. A reply posted through reply_to_feedback is attributed to the person the token belongs to and labelled as arriving via a coding agent — the reviewer reading the thread is deciding whether to re-check the page themselves, and a person promising "fixed this" is not the same claim as an agent asserting it. Both facts are stamped server-side from the authenticated token, so neither can be chosen by the client. Do not sign the message text yourself.

Anything you cannot do in the dashboard, the agent cannot do either — role gating is enforced server-side, not here. A member who is not assigned to a pin cannot change its status, and nobody can read a dock they have no relationship to.

Configuration

Env var	Purpose
`LAYERDOCK_TOKEN`	Required. Your personal access token (`ldk_...`).
`LAYERDOCK_API_URL`	Optional. Defaults to `https://www.layerdock.io`. Point it at a local dev server when working on LayerDock itself.

Security

Tokens are stored as a SHA-256 hash — the plaintext is shown once, at creation, and is never recoverable afterwards. Revoke a token from the same settings page; revocation takes effect immediately.

An authentication failure names its actual cause — malformed, unknown, deleted, or expired — and echoes the first 12 characters of the token the server received (received "ldk_AbCd-EfG…"). That prefix is the same non-secret value the dashboard already displays next to each token, and it is what tells a stale client process still holding a replaced token apart from a genuinely bad one.

Note that on a dev build, sourceFile in a brief may be an absolute path from the machine that built the reviewed site. That stays within the dock's own trust boundary, but it is worth knowing before sharing a brief outside your team.

License

MIT

Available Tools

5 tools

get_feedbackA

Get one feedback pin as a complete fix brief: WHERE it is (page URL, section, CSS selector, the component name when the framework exposed it), a SEARCH STRING that actually matches source (one contiguous run of literal text, not the element's whole innerText), WHAT the reporter wants changed, the SCREENSHOT as an image when one was captured, and the DEBUG state at the moment of capture (console errors and failed/slow requests, each stamped with how long before capture it happened). The brief tells you when a screenshot was NOT captured rather than sending you looking for one. Call this before changing any code.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes
`detail`	No	How much context to send. "auto" (default) reads the pin and trims the computed-style and environment blocks for a pure copy change, keeping everything for a layout or behaviour bug. "minimal" always trims, "full" never does. The brief says which profile it used.

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are supplied, so the description carries the full burden, and it does substantial work: it discloses that a screenshot is returned as an image, that the brief explicitly reports when a screenshot was NOT captured, and that debug entries are timestamped relative to capture. It omits auth/permission requirements and any side-effect profile, which keeps it out of 5 territory.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action ('Get one feedback pin as a complete fix brief') followed by a structured enumeration of brief contents. It is dense and long, but nearly every clause conveys concrete return-value information rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description must explain the return payload, and it does so thoroughly: location, search string, requested change, screenshot presence/absence, and debug state. For a two-parameter read tool this is largely complete; only the 'id' semantics and permission context are left unspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%: the 'detail' enum is already fully documented in the schema, and the description only adds that 'the brief says which profile it used.' The required 'id' parameter has no description in either the schema or the prose (no format, no pointer to the feedback pin), so the description does not compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Get one feedback pin') and enumerates exactly what the returned fix brief contains – location fields, a search string, the requested change, screenshot, and debug state. This is far more specific than any sibling (list_feedback, update_feedback_status, reply_to_feedback), so an agent can distinguish it without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The closing line 'Call this before changing any code' gives a clear when-to-use directive anchored to the agent's workflow. It does not name alternatives or when-not-to-use conditions (e.g. list_feedback for enumeration), so it stops short of full routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_docksA

List the LayerDock docks (sites) you have access to, with any codebase hints their owner declared (framework, source root, CMS). Call this to get a dockId — but note that list_feedback no longer requires one, so "what is open across everything?" is a single call.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does disclose the access-scoped result set and the return payload (owner-declared codebase hints), which matters since there is no output schema. It stops short of stating read-only semantics, pagination, or ordering behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two front-loaded sentences that establish the listing and then the routing note; both earn their place. The second sentence's quoted phrasing is slightly informal but remains efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read tool with no annotations and no output schema, the description covers scope, result contents, and how it relates to sibling tools. Nothing needed to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description correctly implies the call is parameterless by describing a simple scoped listing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (List) and resource (LayerDock docks/sites), scopes it to 'you have access to', and adds what the results carry (framework, source root, CMS hints). This is clearly distinguishable from the list_feedback/get_feedback siblings without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to call it ('Call this to get a dockId') and names the alternative with its condition: list_feedback no longer requires a dockId, so a cross-cutting 'what is open across everything?' query is a single call. This routes the agent both toward and away from the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_feedbackA

List feedback pins. Omit dockId to see open work across EVERY dock you can reach — that is the one call that answers "what needs my attention?". Pass dockId to scope to one site. Returns a lean summary; call get_feedback for the full fix brief of the one pin you pick.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`dockId`	No
`status`	No

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It does disclose meaningful traits: read-oriented listing, access-limited scope ('every dock you can reach'), and that the response is a deliberately thin summary. It says nothing about pagination, ordering, rate limits, or what limit actually governs, which leaves real gaps for an unannotated tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action, then usage in priority order, then the sibling hand-off. Every sentence carries selection-relevant information, though the quoted 'what needs my attention?' framing is slightly chatty.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly compensates by characterizing the return ('lean summary') and pointing to get_feedback for detail. The remaining hole is the undifferentiated limit/status parameters, but an agent has enough to call the tool correctly in the common case.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across three parameters. The description adds real meaning for dockId (omit vs pass and the consequence of each), but limit and status are completely undocumented in both schema and description — including the enumerated status values that would be highly useful for filtering.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (List) and resource (feedback pins), and explicitly contrasts its output with the sibling get_feedback ('lean summary' vs 'full fix brief'). An agent can distinguish it from get_feedback, list_docks, and update_feedback_status without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit two-branch rule: omit dockId to get cross-dock open work, pass dockId to scope to one site, and names get_feedback as the alternative for drill-down detail. Both the when-to-use and the route-to-sibling are spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

reply_to_feedbackA

Post a reply on a pin's thread. It is attributed to the person who owns this token AND labelled as coming via a coding agent, so the reviewer can tell your claim from that person's own — the server stamps both from the authenticated token. Do NOT sign the message text yourself; that is duplicated, and unlike the server-side stamp it is not something the reviewer can trust. Use this to say what you changed before resolving the pin, so a silent status flip does not leave them guessing.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes
`message`	Yes

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full disclosure burden, and it does substantial work: it explains that the server stamps both author attribution and a coding-agent label from the authenticated token, and warns against self-signing because it is redundant and untrusted. It does not cover error behavior, rate limits, or whether replies can be edited/deleted, leaving some gaps for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the operation, then the attribution mechanics, then the use case. Every sentence earns its place, though the middle sentence is dense and slightly repetitive on the trust/duplication point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations and no output schema, the description covers the behavioral and usage dimension well and no return-value detail is required. The main missing piece is the meaning/format of the 'id' parameter, which neither description nor schema defines.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for both required parameters. The description gives real guidance on the content of 'message' (don't self-sign, describe what you changed), but never clarifies what 'id' refers to (presumably the pin/feedback id) or its format, so it only partially compensates for the documentation gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (post a reply on a pin's thread) and implicitly distinguishes itself from siblings like update_feedback_status and get_feedback by being the only thread-writing tool. An agent can identify the operation without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use it: 'to say what you changed before resolving the pin, so a silent status flip does not leave them guessing,' which routes the agent away from a bare status update. It stops short of naming update_feedback_status as an alternative or stating any when-not-to-use case, so it is clear context but not full when/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_feedback_statusA

Move a pin through the workflow: open, in_review, changes_requested, approved, resolved. Call this after you have actually made the fix. Your permission to set a given status depends on your role on the dock; the server rejects what you are not allowed to do.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes
`status`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden, and it does disclose two real behavioral traits: permission is role-dependent on the dock, and the server rejects unauthorized transitions. It stops short of describing side effects (e.g., notifications) or whether transitions are validated/idempotent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the core action and statuses, then the precondition, then the permission caveat. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutating tool with no annotations, no output schema, and undocumented parameters, the description covers when to call it and the permission model well. The remaining gap is the unexplained 'id' parameter and any post-transition effects, which are minor.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It re-states the status enum (already in the schema) and implies a pin/workflow context but never explains what 'id' identifies (feedback id vs pin id) or how statuses relate to one another. Partial compensation only.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb ('Move a pin') plus resource with the full set of workflow statuses enumerated, so the agent immediately understands this is a state-transition tool. It is cleanly separable from the read/reply siblings (list_feedback, get_feedback, reply_to_feedback).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit timing guidance ('Call this after you have actually made the fix') tells the agent the precondition for invoking it. It does not name alternatives or state when-not to use it, but the sibling set makes the boundary obvious.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.5.0Oct 19, 2026
- First observedget_feedback
- First observedlist_docks
- First observedlist_feedback
- First observedreply_to_feedback
- First observedupdate_feedback_status

Deploy Server

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

TDQS

A4.4/5.0

Scored 2026-10-19 14:25 across 5 tools

Disambiguation5/5

Each tool targets a clearly distinct operation: list_feedback retrieves pins across docks, list_docks retrieves sites, get_feedback retrieves one detailed brief, update_feedback_status changes workflow state, and reply_to_feedback posts a message. Descriptions explicitly clarify boundaries (e.g., lean summary vs. full brief, server-side stamping) leaving no realistic misselection.

Naming Consistency5/5

All names use snake_case with a consistent verb_noun pattern: list_feedback, list_docks, get_feedback, update_feedback_status, reply_to_feedback. The minor prep in reply_to_feedback does not break the overall predictable convention.

Tool Count5/5

Five tools are well-scoped for an agent that fixes feedback pins: see open work, find a dock, get the fix brief, update status, and reply. No tool feels redundant or missing for the stated purpose.

Completeness5/5

The surface covers the full agent workflow: discover open pins (list_feedback), resolve dock context (list_docks), retrieve all fix details (get_feedback), change lifecycle state (update_feedback_status), and communicate with the reviewer (reply_to_feedback). No obvious dead ends for the coding-agent use case.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Revisionme A
com.revisionme
Visual feedback from your website's visitors as tasks for your coding agent.
Project Management Product Management Developer Tools
41
BugTapeOAuth
ai.bugtape
Production bugs with replay, network, console and stack, ranked for your coding agent to fix.
Monitoring Observability Developer Tools
1
MarigoldOAuth
io.github.immuneeb
Comment on AI-generated webpages; feedback flows back to your coding agent. Free, MIT, local-first.
Developer Tools Browser Automation AI & Machine Learning
2
Vynix A
in.vynix
Give AI coding agents access to your Vynix visual feedback, bug reports, and AI diagnosis.
Testing & QA Tools Monitoring Developer Tools
17113

Related MCP Servers

pincushion-mcp
Developer Tools Testing & QA Tools Project Management
jcooley8
A
license
A
quality
A
maintenance
Visual feedback as agent work packets: stakeholders pin on your live app and your AI coding agent reads each pin (selector, screenshot, DOM, thread, acceptance criteria) via MCP and ships the fix.
Updated 4 days ago (2026-10-15 19:06 UTC)
39
438 npm
1
MIT
Browser Feedback MCP
Browser Automation Developer Tools
itk-dev
A
license
A
quality
C
maintenance
Enables visual browser feedback collection directly into Claude Code. Users can point at elements in their browser and send annotated feedback that Claude can act on immediately.
Updated 3 months ago (2026-07-09 06:57 UTC)
12
1
MIT
loupe-mcp
Product Management Project Management
mohamed-ashraf-elsaed
A
license
A
quality
A
maintenance
Turns product feedback pinned to a live UI into an actionable backlog for Claude Code — list comments, open one with its target element's HTML, computed styles and screenshot, and update its status.
Updated 11 days ago (2026-10-08 18:44 UTC)
2
19
55,739,560 npm
1
MIT
loopback
Developer Tools Autonomous Agents
joshidikshant
A
license
A
quality
A
maintenance
Interactive feedback layer that lets users pin comments on live web apps with auto-captured context (failing requests, console, AI metadata), and coding agents fix issues via MCP, turning pins green upon verification.
Updated 3 months ago (2026-08-02 19:56 UTC)
10
42 npm
MIT

@layerdock/mcp

Setup

Claude Code

Cursor

Codex CLI

Tools

What get_feedback actually returns

Payload size

Permissions

Configuration

Security

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

What `get_feedback` actually returns