Agent product surface

MCP for Agents

Vibecodr exposes an agent-facing MCP product surface at `https://openai.vibecodr.space/mcp`. It is designed for task-oriented agent workflows without turning MCP into an admin backdoor, unmediated control plane, or second product source of truth.

Agent-facing MCP gateway and workspace guidance for safe Vibecodr automation.

Implementation focus

Use this guide when connecting an MCP client, designing agent workflows, or deciding what belongs in the separate Vibecodr-MCP workspace versus the main Vibecodr product contract.

Expected outcomes

What the MCP gateway is

The Vibecodr MCP gateway is the agent-facing product surface at https://openai.vibecodr.space/mcp. It lets remote MCP clients inspect public Vibecodr context and use product-shaped tools without becoming the Vibecodr app, an admin panel, or a second source of truth for publishing, profiles, runtime, storage, Pulse, or moderation behavior.

The source and release workspace is the separate Vibecodr-MCP product repo, commonly referred to locally as vibecodr - mcp. Main Vibecodr remains the canonical product contract; the MCP workspace adapts that contract into a small, validated, model-readable tool surface.

  • Use MCP for agent workflows that need product-shaped context, launch guidance, social polish, or controlled authenticated actions.
  • Do not use MCP as an unmediated tunnel to platform capabilities, database names, storage buckets, secrets, or platform grants.
  • The default native surface is Streamable HTTP at /mcp with OAuth-compatible authentication for protected operations.
  • Code Mode is a separate constrained execution lane. It becomes available only after Vibecodr has provisioned the runtime loader and completed staged release verification.
Remote MCP endpoint text
https://openai.vibecodr.space/mcp

Agent workflow boundaries

MCP tools should be phrased around the tasks agents actually perform: search public Vibecodr content, inspect a live vibe, build share copy, review a launch checklist, suggest post-publish next steps, or update live metadata only after explicit confirmation.

Lane separation matters. Package preflight, import, preview compile, canonical publish, runtime readiness, social copy, and metadata updates should remain distinct steps so agents can explain what happened and recover safely when one step fails.

  • Public reads can expose public social and discovery facts, not private drafts or owner-only backend metadata.
  • Authenticated writes require user authorization, narrow schemas, explicit confirmation where state changes are meaningful, and safe error messages.
  • Public Vibecodr guidance names product features, not cleanup authority, dispatch details, physical storage names, or hidden compatibility handlers.
  • When main Vibecodr changes publish/runtime/social metadata behavior, update the MCP gateway schemas, prompts, docs, and tests in the same release cycle.

How this maps to Vibecodr

Vibecodr treats MCP as a focused product surface: agents get the same product-shaped actions a creator would recognize, such as finding public vibes, preparing a publish package, checking runtime readiness, building share copy, or updating live metadata after confirmation.

Use the named Vibecodr capability for the job. Put browser UI in the vibe, put trusted backend work in Pulses, use MCP tools for agent workflows, and use Code Mode only when a constrained execution lane has been explicitly enabled.

  • Agents can ask for Vibecodr tasks; they do not get a private control panel.
  • Signed-in actions still depend on the user's session and permissions.
  • Generated Code Mode code can only use the host capabilities Vibecodr exposes to it.
  • If a workflow needs secrets, storage writes, schedules, or provider calls, model it as a Pulse capability instead of browser code.

Task example and next paths

Example: an AI agent needs to publish and inspect Vibecodr work. Connect it to https://openai.vibecodr.space/mcp, use product-shaped native tools by default, and reserve Code Mode for explicitly enabled constrained execution.

Use the related paths below as the next reading order. They are generated from the same route metadata that powers public HTML, markdown aliases, sitemap coverage, and docs navigation, so users and agents see one consistent documentation graph.

  • Related path: /docs/vibes-pulses
  • Related path: /docs/handlers
  • Related path: /docs/automation-safety
  • Related path: /docs/seo-discovery

Related documentation