VibeSharing MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VIBESHARING_URL | No | Custom API URL (defaults to https://vibesharing.app) | |
| VIBESHARING_TOKEN | Yes | Your deploy token from VibeSharing (required) |
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 | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| register_prototypeA | Register a prototype on VibeSharing. Creates a standalone prototype by default. To add it as a version under an existing project, provide parent_project_id. IMPORTANT: Before calling this, use resolve_target to confirm the collection and project name with the user. Do not auto-generate names without user confirmation. Returns the VibeSharing URL where the team can view and leave feedback. |
| list_prototypesA | List all prototypes in your VibeSharing organization. Shows name, URL, and recent activity. Optionally filter by search query (fuzzy matched). |
| list_collectionsA | List all collections (folders) in your VibeSharing organization. Use this to find the collection_id when registering prototypes. Optionally filter by search query (fuzzy matched). |
| get_feedbackA | Get feedback and comments for a specific prototype. Can filter by status (open, in_progress, resolved, wont_fix, deferred), priority (critical, high, medium, low), or assignee. |
| triage_feedbackA | Update status, priority, or assignee on one or more feedback items. Use this to triage feedback from within your editor. |
| close_feedback_loopA | CALL THIS AFTER DEPLOYING when there is open feedback. Matches what you just built to open feedback items, resolves them with explanations, and notifies the original stakeholders with a personalized digest. The stakeholder sees exactly what happened to their feedback. Flow:
|
| sync_contextB | Sync your CLAUDE.md, AGENTS.md, or project context to VibeSharing. This helps maintain context across AI sessions and team members. |
| verify_tokenA | Verify that your VibeSharing deploy token is valid. Use this to check connectivity and authentication before other operations. |
| upload_sourceA | Upload source code for an existing prototype on VibeSharing. Colleagues can then download the source from the prototype page. Use this when you want to share code without deploying it. |
| deploy_prototypeA | Deploy code directly to VibeSharing. This deploys your code to Vercel and registers it as a prototype in one step. IMPORTANT: Before calling this, use resolve_target to confirm the collection, project name, and deploy name with the user. Do not deploy without user confirmation on where it should go. |
| share_htmlA | Share a static HTML page on VibeSharing — the simplest way to share. No Vercel, no GitHub, no React wrapper. Just uploads the HTML and gives you a shareable link with the feedback widget built in. Use this for standalone HTML files, one-page prototypes, or any static content that doesn't need a build step. For large HTML files, use file_path instead of html to avoid MCP parameter size limits. |
| create_collectionA | Create a new collection in your VibeSharing organization. Collections group related projects and prototypes. Use this before deploying a prototype if you need a new collection to put it in. |
| deploy_filesA | Deploy a multi-file Next.js project to VibeSharing. Pushes files to GitHub, deploys to Vercel. Requires an existing prototype ID. For large files, use file_paths instead of files to read from disk and avoid MCP parameter size limits (~100KB). IMPORTANT: Before calling this, use resolve_target to confirm the target prototype with the user. If the user hasn't specified where to deploy, do NOT proceed — ask first. |
| import_repoA | Import an existing GitHub repo into VibeSharing. Pulls the code into a VibeSharing-hosted repo and deploys it to Vercel. IMPORTANT: Before calling this, use resolve_target to confirm the collection, project name, and deploy name with the user. Do not import without user confirmation on where it should go and what it should be called. |
| resolve_targetA | CALL THIS BEFORE deploying or registering a prototype when the user hasn't provided exact IDs. Fuzzy-matches collection and project names, suggests where to put the prototype, and checks deploy_name availability. Returns structured options so you can confirm with the user before proceeding. |
| add_context_linkA | Attach a reference link or note to a collection or project/prototype. Use this to add links to Figma designs, PRDs, Confluence docs, or free-text notes that provide context for reviewers. |
| list_context_linksA | List all reference links and notes attached to a collection or project/prototype. |
| remove_context_linkB | Remove a reference link or note by its ID. |
| generate_feedback_topicsA | Auto-generate feedback questions for a prototype based on what was built. IMPORTANT: Before generating questions, ask the user: 'What type of feedback is most important for this deploy?' and present these options:
Use their answer as the 'focus' parameter. If 'awareness', skip topic generation and just set the brief. Otherwise generate 3-5 questions, weighting toward the chosen focus theme. |
| diagnoseA | Run a comprehensive health check on the user's VibeSharing setup. Checks token validity, GitHub connection, stuck deploy locks (auto-clears them), recent deploy errors, and prototype status. Use this to troubleshoot issues. |
| send_support_requestA | Send a support request to the VibeSharing admin. Use this when the user has an issue you can't resolve, needs a configuration change, or wants to report a bug. |
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 21 tools
Most tools have clearly distinct purposes (e.g., list vs. create vs. deploy vs. share), but the deploy/share family (deploy_prototype, deploy_files, share_html, import_repo) could be misselected without careful description reading. The descriptions are detailed enough to disambiguate, but the overlapping actions of deploying and registering create minor ambiguity.
All tool names follow a consistent verb_noun snake_case pattern (e.g., list_prototypes, create_collection, send_support_request). Even multi-word names like close_feedback_loop and generate_feedback_topics maintain the convention. No camelCase or mixed styles detected.
With 21 tools, the server is at the 'heavy' end of the borderline range. While each tool appears to serve a distinct purpose, the count feels substantial for a typical MCP server, and an agent may need to scan many options before choosing.
The server covers a wide range of operations: authentication, deployment, sharing, feedback triage, context management, and diagnostics. However, there are notable gaps: no update or delete operations for prototypes or collections, and no get-by-ID function for prototypes. These limitations could force agents to work around them.