Skip to main content
Glama
erova

VibeSharing MCP Server

by erova

import_repo

Import an existing GitHub repo into VibeSharing, host it, and deploy to Vercel. Requires user confirmation on target collection, project name, and deploy name.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoOptional: Name for the prototype. Defaults to the repo name if not provided.
repo_urlYesGitHub repo URL (e.g., 'https://github.com/my-org/my-repo')
deploy_nameNoOptional: Friendly name for the Vercel project URL (e.g., 'erg-v3-teams' → erg-v3-teams.vercel.app). Lowercase, hyphens allowed, max 100 chars. Auto-derived from 'name' if omitted.
descriptionNoOptional: Description of the prototype.
prototype_idNoOptional: Existing VibeSharing prototype ID. If not provided, a new prototype is created.
collection_idNoOptional: Collection (folder) ID to place the prototype in. Use list_collections to find IDs.
parent_project_idNoOptional: Parent project ID if this is a version/iteration of an existing project.
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It discloses that the tool mutates state by 'Pulling the code into a VibeSharing-hosted repo and deploys it to Vercel,' and it highlights a critical safety requirement (user confirmation). It does not mention permissions or failure modes, but the provided context—especially the importance warning—is substantial for an import/deploy tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two well-structured sentences plus a bolded IMPORTANT admonition. Every sentence contributes: the first defines the action, the second elaborates on the process, and the third provides critical usage safety. There is no fluff, and the most important instruction is visually emphasized. This is an exemplary concise description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters, 100% schema coverage, and no output schema, the description adequately covers the tool's flow and key precondition. It tells the agent to use resolve_target first and warns against unconfirmed imports. It doesn't detail what happens after execution (e.g., response format), but with no output schema the description is not required to. The main gap is lack of mention of potential side effects on existing prototypes, but schema covers parameter semantics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so each parameter already has descriptive meaning in the schema. The tool description adds minimal new parameter-level information beyond restating default behaviors (e.g., 'Defaults to the repo name' is already in the schema). Thus it meets the baseline but does not slightly exceed it by clarifying relationships between parameters like 'deploy_name' and 'name'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool imports an existing GitHub repo into VibeSharing, pulls code, and deploys to Vercel. The verb 'import' and specific resource 'GitHub repo' make the primary purpose obvious. It doesn't explicitly differentiate from siblings like upload_source or deploy_prototype, but the combined import+deploy behavior is distinct enough for an agent to recognize its role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use guidance: 'Before calling this, use resolve_target to confirm the collection, project name, and deploy name with the user.' It also states a clear precondition: 'Do not import without user confirmation on where it should go and what it should be called.' This tells the agent exactly when and under what conditions to invoke the tool, going beyond vague hints.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/erova/vibesharing-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server