Skyelight MCP Server

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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. Call it at the start of a session. Without `since` it reads from your bookmark and moves it forward; with `since` it reads that window and leaves the bookmark alone.

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.