loupe-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOUPE_API | Yes | Base URL of the Loupe API server | |
| LOUPE_ADMIN_KEY | Yes | Admin secret key for authentication | |
| LOUPE_PROJECT_KEY | Yes | Project key for the Loupe project |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_commentsA | List Loupe product-feedback comments for the project as a task backlog. Use this to see what a PM has flagged, then work through the items. |
| get_commentA | Get the full context for one comment: the request, the page, the target element's HTML, and its computed styles — everything needed to make the change. |
| update_statusA | Update a comment's status. Set to in_progress when you start it and done when the change is shipped — this closes the loop back to the PM. |
| propose_changeA | Submit the modified UI for a comment: the rewritten HTML (and optional CSS) that resolves the PM's request. This stores your proposal on the comment so the dev team can review the code and a live preview in the dashboard. Use get_comment first to see the original element, its computed styles, and the screenshot. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool has a clearly distinct role in the comment-resolution workflow: listing comments, fetching one comment's context, proposing a UI change, and updating status. There is no meaningful overlap between them, so an agent can easily select the right tool.
All four tools use a consistent snake_case verb_noun pattern: list_comments, get_comment, propose_change, update_status. This makes the names predictable and easy to scan.
Four tools is well-scoped for a focused workflow of reviewing feedback, gathering context, submitting a proposal, and closing the loop. Each tool earns its place without redundancy.
The surface covers the full agent-facing lifecycle: discover comments, inspect context, propose a change, and update status. Creation and review of PM comments happen outside this MCP server, so no critical gap remains.