Add Valmera as an MCP Server

JUMP TO YOUR CLIENT

Before You Start

You need a Valmera account — sign up free with email or Google, 50 credits, no card. Two things are worth knowing before you paste anything.

The connector is in limited release. Access is enabled per account, and it is re-checked on every request rather than at connection time. If a sign-in succeeds and the server still refuses, that is what happened — and the message says so, rather than claiming your password was wrong, because sending someone round a password-reset loop over an entitlement is a way to waste an afternoon.

An account created with Google sign-in has no password. The OAuth consent screen asks for one. Set it with "Forgot password" on valmera.io first, and the browser step will work the first time.

How to Add Valmera to Any MCP Client

1. 1
   Find your client's MCP config

   Most clients keep a JSON or YAML file with a map of servers. The key is mcpServers in Cursor, Cline, Claude Code and LibreChat; servers in VS Code; context_servers in Zed; extensions in Goose. Several also have a UI that writes the file for you, which is the safer path the first time.
2. 2
   Add the endpoint as a remote streamable-HTTP server

   The entry is the URL https://entrepreneur-bot-backend.onrender.com/mcp plus, in some clients, an explicit transport type — http in VS Code and Claude Code, streamable-http in Continue and LibreChat, streamableHttp in Cline, streamable_http in Goose. Windsurf calls the field serverUrl instead of url.
3. 3
   Authenticate

   If the client supports OAuth, that is the whole of it: it reads the 401 challenge, discovers the authorization server, registers itself and opens a Valmera sign-in. There is no client id, secret or token to create. If it does not, paste a bearer token into the client's headers block instead.
4. 4
   Confirm, then edit something

   Ask the model to list your Valmera projects. If it comes back with a list — or an honest empty one — the connection works. Then create a project, upload footage, wait for indexing, and describe the edit.

Setup is one paste and one sign-in in most clients. The first upload then needs a one-time analysis pass — transcript, silences, shot boundaries, frame tiles — which reports progress and is reused by every edit afterwards.

Every Client at a Glance

The spread in that third column is the whole reason this page exists. Five clients spell the same transport five different ways, one renames the URL field, and one caps how many tools it will accept — none of which is discoverable from an error message.

The Configs

https://entrepreneur-bot-backend.onrender.com/mcp

claude mcp add --transport http valmera \
  https://entrepreneur-bot-backend.onrender.com/mcp

{
  "mcpServers": {
    "valmera": {
      "url": "https://entrepreneur-bot-backend.onrender.com/mcp"
    }
  }
}

{
  "servers": {
    "valmera": {
      "type": "http",
      "url": "https://entrepreneur-bot-backend.onrender.com/mcp"
    }
  }
}

{
  "mcpServers": {
    "valmera": {
      "type": "streamableHttp",
      "url": "https://entrepreneur-bot-backend.onrender.com/mcp",
      "headers": {
        "Authorization": "Bearer vlm_mcp_..."
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

{
  "mcpServers": {
    "valmera": {
      "serverUrl": "https://entrepreneur-bot-backend.onrender.com/mcp",
      "headers": {
        "Authorization": "Bearer ${env:VALMERA_MCP_TOKEN}"
      }
    }
  }
}

{
  "context_servers": {
    "valmera": {
      "url": "https://entrepreneur-bot-backend.onrender.com/mcp"
    }
  }
}

mcpServers:
  - name: valmera
    type: streamable-http
    url: https://entrepreneur-bot-backend.onrender.com/mcp
    requestOptions:
      headers:
        Authorization: Bearer vlm_mcp_...

extensions:
  valmera:
    enabled: true
    type: streamable_http
    name: valmera
    description: Agentic video editor
    uri: https://entrepreneur-bot-backend.onrender.com/mcp
    timeout: 60

mcpServers:
  valmera:
    type: streamable-http
    url: https://entrepreneur-bot-backend.onrender.com/mcp
    timeout: 60000

mcpServers:
  valmera:
    type: streamable-http
    url: https://entrepreneur-bot-backend.onrender.com/mcp
    oauth:
      authorization_url: https://entrepreneur-bot-backend.onrender.com/mcp/oauth/authorize
      token_url: https://entrepreneur-bot-backend.onrender.com/mcp/oauth/token
      redirect_uri: http://localhost:3080/api/mcp/valmera/oauth/callback

npx @modelcontextprotocol/inspector \
  --server-url https://entrepreneur-bot-backend.onrender.com/mcp --transport http

Anything stdio-only: the mcp-remote Bridge

Some clients only know how to launch a local process and talk to it over stdin and stdout. That is not a reason to be locked out of a remote server. mcp-remote is a small npm package that runs as that local process, performs the OAuth flow in your browser, and proxies everything to the HTTP endpoint. To the client it looks like an ordinary stdio server.

{
  "mcpServers": {
    "valmera": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://entrepreneur-bot-backend.onrender.com/mcp"]
    }
  }
}

Credentials are cached in ~/.mcp-auth, so the browser step happens once. Node 18 or higher is required. If you would rather carry a token than run the flow, the --header flag takes one — and the environment-variable form below is not a style preference. Some clients mangle arguments containing spaces, and Authorization: Bearer … contains one, so the package's own documentation recommends putting the value in env and referencing it:

{
  "mcpServers": {
    "valmera": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://entrepreneur-bot-backend.onrender.com/mcp",
        "--header",
        "Authorization:${AUTH_HEADER}"
      ],
      "env": {
        "AUTH_HEADER": "Bearer vlm_mcp_..."
      }
    }
  }
}

To test the bridge on its own, before blaming your client: npx -p mcp-remote@latest mcp-remote-client https://entrepreneur-bot-backend.onrender.com/mcp. Transport selection is --transport, which accepts http-first (the default), sse-first, http-only and sse-only; Valmera is streamable HTTP, so the default is right and http-only skips one probe.

Verified 2026-08-04 against the mcp-remote README. Use it when a client has no remote support at all — a client with native HTTP support should use it directly, since every bridge is another process that can fail.

The OAuth Flow: Nothing to Paste

Most instructions for connecting a service to an AI client start with "create an app, copy the client id, copy the secret". There is none of that here, and the reason is worth understanding because it is also how you debug it when it fails.

1. The client connects and is refused. The server answers 401 with a WWW-Authenticate header carrying a resource_metadata URL. That header is the entire entry point — a connector UI with no field to type a token can only find the authorization server by being told, here, where it lives.
2. The client discovers the authorization server from /.well-known/oauth-protected-resource (RFC 9728), then reads /.well-known/oauth-authorization-server (RFC 8414) for the endpoints and supported grants.
3. The client registers itself via dynamic client registration (RFC 7591), inventing its own client id on the spot and declaring the redirect URIs it will use. This is the step that removes the developer-portal detour. Registration accepts any https URI, plus http on localhost or 127.0.0.1 because desktop clients loop back to those — which covers Cursor's https://www.cursor.com/agents/mcp/oauth/callback and http://localhost:8787/callback, and the Inspector's http://127.0.0.1:6276/oauth/callback. No secret is issued: a client that cannot keep one is more honest as a public client with PKCE than as a confidential one whose secret ships inside an app.
4. You sign in and consent in a browser window the client opens, with PKCE (S256) mandatory on the exchange.
5. The code is exchanged for tokens and the original request is retried. Refresh tokens rotate, and replaying an authorization code revokes the whole grant rather than quietly issuing a second one.

Two details that decide how it feels day to day. The project you have open lives on the grant, so a reconnect resumes the same edit rather than dropping you at a blank canvas. And an unregistered redirect URI dead-ends on our own page instead of redirecting to it — a misconfigured client fails visibly, which is the behaviour you want from the one hop that carries an authorization code.

The Bearer Token Path

OAuth is the better path when there is a person and a browser. There often is not — a CI runner, a container, a client that never implemented the OAuth half of the spec. Cline and Continue are in that second category today. For those, the server accepts a static token on the standard header:

Authorization: Bearer vlm_mcp_...

A token is minted against your signed-in Valmera account and shown exactly once — it is stored only as a sha256 hash, so a lost token is replaced rather than recovered. While the connector is in limited release, minting is enabled per account; the MCP server page is where to ask for one.

Both credential types resolve to the same session inside the server — who you are, and which project is open — so a token session and an OAuth session receive an identical tool registry and identical refusals. Nothing is degraded by choosing the simpler one.

Do not commit it. Every client here supports a way not to: ${VALMERA_MCP_TOKEN} in Claude Code, ${env:VALMERA_MCP_TOKEN} in Windsurf and Cursor, an inputs entry with password: true in VS Code, customUserVars in LibreChat, and an env block with mcp-remote. A token in a repo is a token in everyone's clone.

The First Call, in Order

A connected client has 108 tools and no context. The studio hands Valmera's own agent a project, an upload and an index for free; a headless model has to be handed all three. The order is not optional, and the server enforces it rather than letting a model guess.

The complete registry — every tool name, what it does and what it refuses — is the tool reference.

Slow Work Returns a Ticket: wait_for_job

A render is minutes of ffmpeg; an MCP tool call is a request. Something has to give, and what gives is the pretence that the call finished. Renders, exports, pixel repainting and browser recording answer like this:

STILL RUNNING — render_preview is job 8814 (running, 12%). Nothing
has failed; call wait_for_job(job_id=8814) to pick the result up.

Every call returns within about 25 seconds. That bound is deliberate: clients put a first-byte timer on HTTP MCP servers — 60 seconds in Claude Code — so a tool that blocked for the length of a render would be killed by the client rather than finished by the server. wait_for_job is meant to be called in a loop. It waits a bounded time too and returns either the finished result or the same line at a higher percentage; there is no penalty for calling it repeatedly, and the job continues server-side whether or not anything is waiting on it.

Three jobs per account run at once. A fourth is refused with "Too much is already running on this account" — which matters more from a script than from a chat window, because a loop will fire off exports faster than they render.

One Project, One Editor

If the Valmera studio is open on the same project in a browser tab, an MCP tool call answers:

Valmera's own agent is mid-turn on this project — wait for it to
finish before editing, or the two of you will overwrite each other's
edit.

This is a deliberate refusal, and it runs in both directions: the studio will not start a turn while an MCP call is in flight either. Two writers on one edit decision list each read state the other is halfway through changing, so the loser is not a merge conflict anyone would notice — it is a silently wrong edit, discovered at export.

The fix is to let the turn finish, or work on a different project. Every MCP call writes an activity row, so the studio shows the outside model editing live rather than appearing to be broken.

When It Does Not Connect

• Prove whose fault it is first. Point the MCP Inspector at the endpoint. If it connects and lists tools, the server and your account are fine and the problem is the client's config. That one check saves most of the guessing below.
• The server loads but shows no tools. Almost always authentication that has not completed — the client connected, got a 401, and has not run the sign-in yet. Look for the client's authenticate action rather than editing the config again.
• A url with no type. In Claude Code and VS Code an entry with a url and no type is read as a stdio server and skipped. Claude Code names it precisely: MCP server "valmera" has a "url" but no "type".
• The wrong field name. Windsurf wants serverUrl, Goose wants uri, VS Code wants servers rather than mcpServers, Zed wants context_servers. A config copied from another client's docs fails quietly.
• The sign-in rejects a password you are sure of. A Google-only account has no password. Set one with "Forgot password" and reconnect.
• "The account does not have access." A different message from a wrong password, on purpose: the password was right and the account is not enabled. See the limited-release note above.
• Fewer tools than expected. A tool whose backing service is unconfigured is hidden from tools/list rather than exposed and failing at call time, so a session can be a few short. Windsurf's 100-tool cap is a separate, larger cut.
• Every call asks for approval. Most of an edit is reading — look_at, get_words, project_state, get_shots. Use your client's allowlist, but be deliberate: reading costs nothing while rendering, exporting and generating spend credits. Allowing the read tools and prompting on export_final is a reasonable middle.

One thing that is never the answer: retrying a tool call because the reply mentioned a job number. That is a receipt, not an error.

What This Does Not Do

Connecting the server does not change what the editor is. The honest edges, so a model reading this page does not promise them:

• It edits footage, it does not generate it. Short generated clips and stills can be spliced in; there is no whole-video text-to-video. Upload something real.
• Nothing renders locally. Only the upload and the download run on your machine. There is no local ffmpeg step to pin or cache.
• Captions are burned in. No SRT or VTT is accepted or produced, and no chapter metadata — so there is no subtitle file to commit next to the MP4.
• One deliverable per request. A 16:9 for the docs and a 9:16 for social are two requests, not one matrix build.
• No NLE interchange, and no multi-cam. No project file for Premiere, Resolve or Final Cut, no true crossfade, and one transition style per video rather than per cut.
• No team seats, share links or direct publishing. The export is a file you download and post yourself. Also no custom font uploads, no motion-tracked overlays, no audio denoise, no diarization output, and no AI music generation.

The agent knows these edges and refuses out-of-scope requests instead of faking them — every reply is verified server-side against the edit decisions actually recorded, so it cannot report a change it did not make. The category argument for why an editor built this way is the kind another agent can drive is on the agentic video editor page, and the field of alternatives is on video editing MCP servers.

Frequently Asked Questions

Connect It and Edit Something

Create a free Valmera account, paste the endpoint into your client, sign in — then upload footage and describe the edit from the chat you are already in.