list_workspaces
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.
Takes no parameters.
Skyelight
io.github.plastrlabPublished by GitHub account plastrlabv1.0.0Updated Nov 6, 2026
Give your AI assistant feedback pinned to the exact element, with its code, so it can fix and reply.
The publisher's own server: Skyelight
Overview
AI-generated overview
Skyelight lets a coding agent read feedback pinned to elements of a running app, work the thread, and report back where the feedback was left.
- What you can do
- Browse workspaces, projects and feedback items, with search and a summary of what is outstanding
- Read one item in full: thread, page, element anchor, screenshots and the source file and line that rendered it
- Report back on a thread, raise new items, set status, assign people, merge duplicates and save team rules
- Catch up on what changed since last look, and pull project reviews and quoted decision logs
- Find feedback on a file before editing it, and check for an existing report before creating one
- Publish a page or component for review, or register a deployed app's address as a review link
- When to use it
- Useful when a team collects in-app feedback through Skyelight and wants a coding agent to triage it, fix items handed off to it, and answer reporters on the original thread. Also fits review and hand-off write-ups from a project's resolved and deferred threads.
- Requirements
- Either the remote endpoint with browser OAuth sign-in, or the local npm package run with npx over stdio. The local route needs SKYELIGHT_API_URL and a personal token in SKYELIGHT_API_TOKEN from account settings, API Keys. A Skyelight account with owner, admin or collaborator role in the workspace; network access.
Before you install
Writes are attributed to the signed-in person, so replies and status changes appear as yours. Several tools change data: post_update, create_item, set_status, assign, save_rule, merge_items (marked destructive) and publish_review_link; whats_new moves a bookmark. The token is shown once and is scoped to its organization. Free plans count agent threads monthly, and publishing code hands it to Skyelight to host.
Installation
In SourceWeft
- Open Skyelight in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.
Use with an agent
Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.
Read https://sourceweft.com/mcp/io.github.plastrlab%2Fskyelight-mcp/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.Other MCP clients
Add this to your client's mcpServers config.
{
"mcpServers": {
"skyelight": {
"type": "http",
"url": "https://app.skyelight.ai/mcp"
}
}
}README
@skyelight/mcp
[Skyelight: feedback pinned to the element, with the source behind it, for your coding agent]
An MCP server that lets a coding agent read the feedback people left on your running app — the thread, the page, and the element they were pointing at — and report back on it when the work is done.
Full guide: skyelight.ai/docs/mcp. The REST API behind the local server is documented at skyelight.ai/docs/api.
Two ways to connect, with the same eighteen tools either way:
- Remote, with OAuth — the default. Your agent talks to Skyelight over HTTP and you sign in once in the browser. Nothing is pasted and no key is stored on disk.
- Local, with a token — this package runs as a stdio server on your machine and carries a personal token. For clients or machines where the browser sign-in is not an option.
Every plan includes every tool, Free included, for owners, admins and collaborators. On Free, your agent gets 25 agent threads a month; Pro and above have no limit. A reviewer reads and comments in the web app but does not get agent tools.
The short way
Finds your coding agents, registers Skyelight's remote server with them, and
leaves the sign-in to OAuth — the first time the agent connects it opens a
browser and you approve it there. It shows what it will change and waits;
--yes skips that once you have read it.
It knows Claude Code, Cursor, Grok, Codex, Gemini CLI and Windsurf. With several
installed it asks which; --client cursor or --client all answers in
advance. npx @skyelight/mcp remove takes the entry out again. Point at
another deployment with SKYELIGHT_URL=https://…; the deployment tells the
installer its own MCP URL and OAuth client over /mcp/install-config, so this
package holds no environment-specific constants.
The same setup, with a snippet per client, is in the Skyelight web app under account settings → Coding Agents.
As a Claude Code plugin
The plugin connects Claude Code to Skyelight's remote server (sign-in is
OAuth, as above) and adds a skill for working through feedback and two
commands: /skyelight:whats-new and /skyelight:fix-feedback. Its files are
.claude-plugin/marketplace.json and plugin/ in this repository.
As a Gemini CLI extension
Then, in Gemini CLI, sign in once:
A browser opens on Skyelight; sign in and allow the connection. Gemini CLI
lists the tools before you sign in, so it won't ask by itself. The extension
connects Gemini CLI to Skyelight's remote server and adds the same skill and
the same two commands as the Claude Code plugin: /skyelight:whats-new and
/skyelight:fix-feedback. Its files are gemini-extension.json,
GEMINI.md, commands/ and skills/ at the root of this repository.
With a token
Get a personal access token. In the Skyelight web app, go to account settings → API Keys → create one. It is shown once, belongs to the organization you create it in, and can be given an expiry.
Then add the server to your client:
Claude Code users can skip the file:
SKYELIGHT_API_URL is https://app.skyelight.ai, the same host as the MCP
URL on the Coding Agents page (https://app.skyelight.ai/mcp), without
/mcp. A deployment's .convex.site host also works.
Credentials
Checked in order, so an existing setup keeps working:
SKYELIGHT_API_TOKEN/SKYELIGHT_API_URLin the environment.env.local, then.env, in the working directory~/.skyelight/credentials—{"apiUrl": "...", "token": "sky_..."}
Binding a repo to a project
With the local server, if you can reach several projects, drop a
.skyelight.json at the repo root:
Tools then default to that project and nobody has to pass an id. Without it
(and always on the remote server), list_items asks for a project and the
agent calls list_projects first rather than guess.
Tools
Which tools change things. list_workspaces, list_projects,
list_items, search_items, get_item, list_members, project_review,
find_by_source, find_similar and decision_log only read. post_update,
create_item, set_status, assign, save_rule, merge_items,
publish_review_link and whats_new (which moves your "last looked"
bookmark) make changes. Every tool carries MCP annotations saying which it
is, with merge_items marked destructive, so your client can ask before a
write runs.
Publishing for review. publish_review_link takes one of two things:
code: one HTML page, or one React component with an export default (a Claude prototype, a v0 snippet). Skyelight hosts it at its own link onskyelight.pagewith the review badge on it, in a project you name or a new one. Publishing again makes a new version at the same link.url: an app already deployed, such as a Lovable, v0 or Bolt project on*.lovable.appor*.vercel.app. The address goes on the project's Review Links, and the answer carries a script tag for the app's<head>and the review link to share (the address with?skyelight=1).
Code that imports the rest of its app is not hosted; the answer says to send
the app's url instead. It answers to publish_prototype too, its name
before 0.7.0.
list_items leads with a summary — totals, breakdown by type and by page — so
an agent can tell you the shape of the work before pulling any of it. Rows are
stubs; get_item is where the thread and the anchor live.
"What is assigned to me." list_workspaces returns your own user id, and
list_items takes assignee: "me", so the most ordinary question anyone asks
an agent needs no id looked up by hand.
"What was I asked to fix." A person can hand a thread to an agent in the
app (Hand off: Investigate, Plan or Fix). list_items takes task with one of
those, or "none", and each row names its hand-off. With assignee: "me" it
is your own queue of fixes.
Merged duplicates do not appear twice. When somebody merges five reports of
one problem in the web app, the duplicates leave the list and the item they were
merged into says 5 reports. A list that shows all five reads as five bugs.
What the agent sees
Deliberately prose rather than JSON. A tool that returns a bare array invites a model to read the array out; this one invites it to summarise.
A row's line is the one-sentence summary Skyelight's classifier wrote, where there is one, rather than the first 140 characters of whatever somebody typed — four truncated paragraphs are not something you can choose between.
One call reads the 2,000 most recent items in a project. Past that the result says so, in words, rather than presenting a slice as the total.
The pictures
get_item returns the screenshot taken when the pin was left, and any images
people attached to the thread, as image content blocks — things a model can
actually look at, not links it cannot open.
Capped at four per call. Anything too large to inline comes back as its link with the reason, so a picture never disappears silently.
What somebody else already did
get_item also names the Linear issue a thread was handed to, and who it was
delegated to, so an agent does not start work a Linear-hosted agent is
finishing. Reactions come back counted by emoji — a thread with one comment and
nine thumbs up is not a thread with one comment.
Where the code is
If the app was built with @skyelight/build,
get_item ends with the line that changes what an agent does next:
The file saves a grep. The commit and branch are how an agent tells "still broken" from "already fixed, this pin is stale" — and, on a preview deployment, which branch the code it wants is actually on.
Who a write belongs to
Every write is a person's. Your sign-in or token carries your access, so a reply the agent posts is yours. Over the remote server, the editor it came through is shown as a mark beside the timestamp rather than as the author.
There is no service-account mode, and workspace API keys (sk_live_...) no
longer work. The API accepts two credentials, both of which are you: an OAuth
sign-in and a personal token (sky_...).
Permissions
The server enforces nothing; the API does. The agent can do what your account can do in that workspace, and nothing more:
- Agent tools work on every plan, Free included, for owners, admins and collaborators. A reviewer is refused with the reason — the workspace is listed and marked rather than hidden, so you are told which gate closed instead of being told it does not exist.
- On Free, your agent gets 25 agent threads a month. Two things
count: each conversation, once, on its first call of any tool, listing
included; and each thread the first time in the month
get_item,post_update,set_status,assignormerge_itemstouches it. So "what feedback do I have?" then "fix that one" is 2. Nothing counted is given back.list_workspacessays how many are left, and at the limit anything new is refused with the reset date. Free hosts one prototype. - Adding a deployed app's address to Review Links is for owners and admins.
- Owners, admins and collaborators read, reply, raise items and change any thread's status.
- A token only reaches workspaces in the organization it was created in.
Source: README.md at commit 1a2e0e6
Tools
18list_projects
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.
Parameters
workspaceIdlist_items
List feedback
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.
Parameters
pagetasktypelimitstatusassigneeprojectIdsearch_items
Search feedback
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.
Parameters
limitqueryrequiredstatusprojectIdpost_update
Post an 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.
Parameters
bodyrequiredlinksitemIdrequiredmentionscreate_item
Create feedback
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.
Parameters
urlrequiredbodyrequiredassigneementionsselectorpageTitleprojectIdpublish_review_link
Publish a 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.
Parameters
urlcodekindnamesourceprojectIdprototypeIdworkspaceIdlist_members
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.
Parameters
projectIdworkspaceIdassign
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.
Parameters
itemIdrequiredassigneerequiredset_status
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.
Parameters
itemIdrequiredstatusrequiredget_item
Get feedback 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.
Parameters
itemIdrequiredproject_review
Review project
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.
Parameters
offsetsectionprojectIdwhats_new
What's 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. 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.
Parameters
sinceprojectIdfind_by_source
Find feedback by source file
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.
Parameters
filelinelimitstatuscomponentprojectIdfind_similar
Find similar feedback
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.
Parameters
pagetextlimititemIdselectorprojectIdincludeResolvedmerge_items
Merge duplicates
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.
Parameters
itemIdrequiredduplicateIdsrequireddecision_log
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.
Parameters
limitsinceoffsetprojectIdsave_rule
Save a 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.
Parameters
rulerequiredprojectIdsourceItemIdsVersion history
1- v1.0.0LatestOct 23, 2026
Score
90% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 daysRequired25 pts
- Auth declaredRequired10 pts
- Tools listedRequired15 pts
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts
Declare a license in the repository or the registry entry.