Skyelight MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SKYELIGHT_API_URL | No | The Skyelight API host, the same host as the MCP URL without /mcp (e.g. https://app.skyelight.ai). A deployment's .convex.site host also works. | https://app.skyelight.ai |
| SKYELIGHT_API_TOKEN | Yes | Your Skyelight personal access token (starts with sky_...), created in the Skyelight web app under account settings → API Keys. Required when running the local stdio server with a token; the default remote connection uses OAuth browser sign-in instead. It may also be supplied via .env.local, .env, or ~/.skyelight/credentials. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Skyelight holds feedback people left directly on pages of a running app. list_items to see what is outstanding, get_item for the full thread and the element it points at. whats_new catches you up since you last looked; find_by_source shows feedback on a file before you edit it; find_similar checks for an existing report before create_item; project_review and decision_log hold what a project settled, for reviews and summaries. An item can carry a hand-off the team set: investigate, plan or fix. It is binding. On investigate or plan, reply on the thread with post_update and change no code, even if asked to in chat; the go-ahead is the hand-off being switched to fix in Skyelight. On fix, make the change, following any plan or findings already on the thread.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_workspacesA | 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_projectsA | Projects you can reach, newest activity first, across every workspace unless one is named. Start here when no project is bound — |
| list_itemsA | 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_itemsB | 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_updateA | 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_itemA | 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_linkA | Share something with Skyelight for review, and get a link people can pin feedback on. Two ways:
|
| list_membersA | 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. |
| assignA | 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_statusA | 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_itemA | 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_reviewA | 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_newA | 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 |
| find_by_sourceA | 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_similarA | 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_itemsA | 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_logA | 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_ruleA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Skyelight item card | Renders a feedback item as an interactive card: the thread, the page it is on, and what the person pointed at. |
TDQS
Scored across 18 tools
Most tools target clearly distinct resources or workflow steps, and descriptions explicitly disambiguate similar-seeming operations like list_items vs whats_new vs project_review. A few overlaps remain, such as project_review and decision_log both surfacing resolved/deferred conversations, but they are differentiated enough for an agent to choose correctly.
Names are consistently snake_case and mostly follow a verb_noun or action-oriented pattern. Minor deviations such as whats_new, project_review, and decision_log break the verb_noun convention slightly, but remain readable and predictable overall.
The 18 tools are slightly above the ideal compact range but each covers a meaningful part of the feedback, review, and decision workflow. Given the domain complexity, the count is reasonable rather than excessive.
The surface covers discovery, item reading, searching, replying, assignment, status changes, duplicate detection and merging, review links, decision logs, and saved rules. Minor gaps exist, such as no explicit item edit/delete or list-review-links operation, but core workflows are well supported.