# @skyelight/mcp [Health: Active]

**Category:** 📋 Product Management  
**Repository:** https://github.com/plastrlab/skyelight-mcp  
**GitHub Stars:** 1  
**npm Downloads (last month):** 1650  
**Views:** 0  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/skyelight-mcp

## Description
Give your AI assistant feedback pinned to the exact element, with its code, so it can fix and reply.

## Tools
Capabilities this server exposes over MCP:

- **list_workspaces** — Workspaces you can reach, with the role you hold in each, and who you are. Use when you do not know what exists yet, to find which workspace a project belongs to, or to learn your own user id.
- **list_projects** — Projects you can reach, newest activity first, across every workspace unless one is named. Start here when no project is bound — `list_items` needs a project id and this is where one comes from.
- **list_items** — List feedback items (bugs, ideas, comments) people left on a Skyelight project. Returns a summary of the project plus matching items. Start here to see what is outstanding. An item's hand-off (investigate, plan, fix) is set by the team and binding: on investigate or plan, reply on the thread and change no code.
- **search_items** — Find items whose thread mentions some text. Searches replies as well as the original message, so an item someone already diagnosed in a reply still turns up.
- **post_update** — Report back on an item: what you found, what you changed, a link to the PR. Posts as a reply on the thread the feedback was left on, so the person who reported it sees the answer where they asked. Use this when you finish work on an item, and when you get stuck.
- **create_item** — Open a new thread on a page, as the person whose connection you are using. Only available on a person's own connection — an agent reporting what it found or changed uses post_update on the thread it was working, so the answer lands where the question was asked.
- **publish_review_link** — Share something with Skyelight for review, and get a link people can pin feedback on. Two ways:
- code: one file Skyelight hosts at its own link with the review badge on it. A whole HTML page, or one React component with an export default (Tailwind classes and npm imports work; local imports such as @/components do not). For Claude prototypes, v0 snippets and single pages. Publishing again with the same prototypeId, or the same name in the same project, makes a new version at the same link.
- url: an app already deployed (a Lovable, v0, Bolt or Vercel project: anything with more than one file). Adds its address to the project's Review Links and returns a script tag to add to the app's <head> (index.html, or the root layout); add it and redeploy. Owners and admins.
Returns the share link and the project link; give both to the person. A hosted link is public to anyone who has it.
- **list_members** — The people in a workspace: name, email, role and id. Call it when you are asked to tell, ask or hand something to someone by name, then pass their name or id to assign, or in mentions on create_item or post_update.
- **assign** — Hand an item to a person, who is notified the way an assignment in the app notifies them. Pass null as the assignee to unassign it. Only owners, admins and collaborators can assign; a resolved item has to be reopened first.
- **set_status** — Move an item to open, deferred or resolved. Use it to close the loop after you have fixed something and said so — post_update first, so the person who reported it reads what changed, then set_status. "deferred" is for work that is real but not now.
- **get_item** — Everything needed to work one item: the whole thread in order, the page and URL it is on, the anchor identifying the element the person pointed at, and the pictures — what the page looked like when it was pinned, plus anything people attached — returned as images you can look at rather than links you cannot.
- **project_review** — Everything needed to write an accurate project review or hand-off document: the shape of the work, every resolved thread and how it ended, what was deferred and why, what is still open, and the longest conversations quoted in full, which is where decisions were made. Every entry carries its item id, so each claim in your document can be traced back to its thread. Quote; do not invent outcomes the threads do not state.
- **whats_new** — What changed on a project since you last looked: new threads, new replies grouped by thread, what was resolved or deferred, and what was assigned to you or mentioned you. Use when the user asks what has changed on a project since they last checked. Without `since` it reads from their bookmark and moves it forward; with `since` it reads that window and leaves the bookmark alone.
- **find_by_source** — Feedback by the code that rendered it, from the file and line the Skyelight build plugin stamps on each element. Pass a file (a path or just its name) or a component to see every thread about it before you edit it; pass neither to get the hot spots, every stamped file ranked by outstanding feedback.
- **find_similar** — Has this already been reported? Pass the text you are about to report (and the page, if you know it) before create_item, or an itemId to find what an existing thread duplicates. Returns likely matches with why each matched: shared words, same page, same element, same source file. If two are the same problem, merge_items folds one into the other.
- **merge_items** — Fold duplicate items into one, the way merging works in the app: the duplicates leave the list and count as extra reports on the item they were merged into. Use it only when find_similar and the threads themselves show they are the same problem. Owners, admins and collaborators can merge.
- **decision_log** — The decisions a project made in its threads, quoted: every thread resolved or deferred after a discussion, with the conversation, plus types people corrected and where outcomes keep recurring. Also returns the project's existing rules, so you can tell what is new. Use it to write a decision log, or to find rules worth keeping with save_rule.
- **save_rule** — Keep a rule the team agreed on ("sentence case in every button", "the brand gray stays, do not raise contrast bugs on it") in the project's context, under Rules learned. The classifier reads that context, and every agent reads it through decision_log, so it shapes future threads. Cite the threads it came from. Workspace owners and admins only; confirm with the person before saving.

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `npx` (confidence: high):

```json
"mcpServers": {
  "mcp": {
    "command": "npx",
    "args": ["-y","@skyelight/mcp"],
    "env": {
      "SKYELIGHT_API_URL": "",
      "SKYELIGHT_API_TOKEN": ""
    }
  }
}
```

**Requires environment variables:** `SKYELIGHT_API_URL`, `SKYELIGHT_API_TOKEN` — the values above are empty placeholders; fill in real credentials before running (see the repository for what each one is for).

## Documentation

## What @skyelight/mcp does

@skyelight/mcp gives coding agents access to feedback collected in Skyelight. A feedback item can include its discussion, the page where it was created, the selected element or source location, related code, and images. Agents can use that context to understand a report before editing code, then reply on the original thread or update the item's workflow state.

The server also exposes project-level context. Agents can read workspace and project membership, review recent changes, retrieve decision history, save agreed rules, identify feedback associated with a file or component, and look for duplicate reports. This makes it suitable for coding-agent workflows that move from feedback triage to implementation and hand-off.

## How it works

There are two connection modes. The remote mode uses HTTP and OAuth; the agent opens a browser for sign-in and approval, so a token is not stored locally. The local mode runs the package as an MCP stdio process and uses a Skyelight personal access token.

The tools are split between read and write operations. Reading includes workspace discovery, project listing, item search, item retrieval, member lookup, project reviews, source searches, duplicate searches, and decision-log access. Writing includes thread updates, new items, status changes, assignments, saved rules, merges, review-link publishing, and advancing the “last looked” bookmark used by `whats_new`. MCP annotations identify tool behavior, including the destructive nature of `merge_items`.

A local repository can contain `.skyelight.json` with a project ID and name. That lets local tools use the project by default. Without that binding, the agent selects a project through `list_projects`.

## Setup and configuration

The shortest setup is:

```bash
npx @skyelight/mcp init
```

The initializer detects supported coding agents, registers Skyelight's remote MCP endpoint, and leaves authentication to OAuth. Use `--client cursor`, `--client all`, or another supported client selection when needed. `npx @skyelight/mcp remove` removes the registered entry. `SKYELIGHT_URL` can point the initializer at another deployment.

For token-based use, create a personal access token in Skyelight under account settings and configure the server with `SKYELIGHT_API_URL` and `SKYELIGHT_API_TOKEN`. Credentials are checked from environment variables, `.env.local`, `.env`, and `~/.skyelight/credentials`, in that order. The package can also be installed as a Claude Code plugin or a Gemini CLI extension, both of which use remote OAuth.

## Tools and capabilities

The 18 tools cover:

- Workspace, project, member, and project-review discovery.
- Filtering, searching, opening, and tracking feedback items.
- Thread replies, new findings, status changes, assignments, and duplicate merging.
- Source-based feedback lookup, similarity checks, decision logs, and saved project rules.
- Publishing a standalone HTML page, a React component with a default export, or a deployed application for review.

`publish_review_link` can host supported code on a Skyelight review URL or register an existing deployed URL and return the review link and script needed for the application.

## Limitations and notes

The hosted-code publishing path accepts one HTML page or one React component with an export default; code that imports the rest of an application should be supplied as a deployed URL instead. A deployed application can be registered through its URL, including supported `lovable.app` and `vercel.app` addresses.

All plans expose the tools to owners, admins, and collaborators. Free plans allow 25 agent threads per month, while Pro and higher plans remove that limit. Reviewers can read and comment in the Skyelight web application but do not receive agent tools.

_Full upstream README: https://allmcps.com/mcp/skyelight-mcp/readme_