Project sync service with PM agent orchestration and MCP server for managing projects, dispatching molecules, querying beads, and coordinating with PM agents
Vibesync presents a mixed quality MCP server. Strengths: 13 tools with explicit schemas, proper descriptions for most tools, clear risk categorization (READ_ONLY vs WRITE), and good naming conventions using verb_noun patterns (query_, show_, dispatch_, assign_, review_, verify_, request_, look_at_, unmount_, list_). Weaknesses: (1) Several parameters lack detailed type constraints and descriptions (e.g., vibesync_query_beads 'search' parameter has no format constraints; 'limit' lacks range specification). (2) Output schemas are not documented, critical for LLM chaining. (3) Error handling lacks recovery guidance; no mention of what errors are retryable vs fatal. (4) Some parameter descriptions are generic (e.g., 'Rig name' repeated 4 times without explaining what a rig is or how to discover valid ones). (5) Confirmation requirement stated in tool descriptions (e.g., vibesync_dispatch_molecule) but no mechanism shown for confirming before execution. (6) File-mounting tools (look_at_file, unmount_file, etc.) have poor descriptions for a core feature, 'Mount and look at a file's contents' is vague about what 'mounting' does or enables.
Show currently mounted files and available file-handling tools. Returns a list of all files you've mounted in this session.
Mount and look at a file's contents. This attaches file-handling tools to your session so you can interact with the file. Use this when you need to examine code, documentation, or any file in your project. After calling this, you'll have access to tools for reading sections and editing.
Query registered projects from the database or project registry
Unmount all currently mounted files and detach all file-handling tools. Use this when you're done working with files and want to clean up your session.
Unmount a file that was previously mounted with look_at_file. If this is the last mounted file, file-handling tools will be detached from your session.
Assign a bead to a role-agent or user and optionally claim it (set status to in_progress). REQUIRES user confirmation before calling.
Output schemas not documented. Tools like vibesync_status, vibesync_query_beads, vibesync_show_dispatch, and vibesync_verify_pr lack documented return types. LLMs cannot plan downstream tool calls or know what fields to extract without this schema.
Numeric parameters lack range constraints. 'limit' in vibesync_query_beads (default 20) and 'start_line', 'max_lines' in look_at_file have no documented min/max bounds. This invites LLMs to pass absurd values (limit=999999, max_lines=1000000).
String parameters lack format constraints. 'search' in vibesync_query_beads, 'formula' in vibesync_dispatch_molecule, 'file_path' in look_at_file have no mentioned length limits, regex patterns, or allowed character sets. 'formula' and 'file_path' especially risk injection attacks if not validated server-side.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 71 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 21 | - | v1 |
Fire a formula (molecule) against a rig. REQUIRES user confirmation before calling — present the dispatch plan to the user first.
Cross-rig bead query with filters. Returns matching beads from one or more rigs, each tagged with its rig name.
Request merge of a PR. Does NOT merge directly — creates a merge-request bead for human approval. REQUIRES user confirmation.
Review a completed dispatch: accept, reject, or request changes. Adds review notes to the molecule root bead. Accept also closes the dispatch.
Inspect a completed or in-flight dispatch (molecule). Shows the molecule root, all steps with status, output artifacts, provider info, and related beads.
Return current rig health, active dispatches, and recent bead activity. Safe to call frequently.
Run a verification suite (typecheck, test, lint) against a rig. Returns structured pass/fail result with output.
Error handling lacks recovery guidance. No indication of which errors are retryable, which require user action, or which are fatal. E.g., if vibesync_dispatch_molecule fails with 'Rig not found', should the LLM retry, ask the user, or try a different rig?
Confirmation mechanism not shown. vibesync_dispatch_molecule and vibesync_assign_bead state 'REQUIRES user confirmation' but no tool implements a confirmation step (e.g., dry-run output + confirm_dispatch). LLMs cannot ensure consent before destructive action.
Vague domain terminology in descriptions. 'Rig' and 'bead' and 'molecule' are not explained. A new user of the MCP does not know what a rig is (directory? host? test environment?) or how to discover valid rig names without context from outside the tool definitions.
File-mounting tools have weak descriptions. 'Mount and look at a file's contents. This attaches file-handling tools to your session...' is too vague. What file-handling tools are created? How are they used? What is the intended workflow? Descriptions should state: 'Call this to make a file readable via embedded tools: get_file_section, edit_file_lines, etc. Unmount when done.'
Parameter descriptions repeat generic info. 'Rig name' and 'rig name (searches all if omitted)' appear in 4+ tools with no guidance on how to discover valid rig names or what happens if omitted.