Skip to main content
Glama
Zhao73

Grok Membership Media MCP

by Zhao73
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Grok Membership Media MCP

Local MCP server that turns paid ChatGPT and Grok memberships into a reusable website media tool for Claude Code, Claude Desktop, Codex CLI, and Codex Desktop.

Open the live project page · Read the Chinese architecture

Real six-second membership output

The implementation has produced and re-verified a real 6.04-second 720p MP4 through a Grok paid-member session. The public demo is a metadata-cleaned copy; raw job manifests and local session data are not published.

Non-negotiable policy

The MCP implementation contains no xAI/OpenAI developer API adapter and its runtime cannot select one:

  • no XAI_API_KEY;

  • no OPENAI_API_KEY;

  • no direct xAI/OpenAI REST request;

  • no xAI public API fallback;

  • no chatgpt-imagegen Codex backend.

The pinned upstream chatgpt-imagegen file is vendored unchanged for provenance and still contains its upstream Codex implementation. This MCP never invokes it: scripts/chatgpt-imagegen-web-only rejects every generation command unless it contains exactly --backend web, and the Python adapter independently hardcodes the same value.

GPT first frames are created by the vendored chatgpt-imagegen v0.21.0 with --backend web, using the logged-in ChatGPT browser. Grok images and videos are created by the locally installed Grok Build CLI using its cached grok.com paid membership. Every Grok subprocess gets GROK_DISABLE_API_KEY_AUTH=1 and all known API-key environment variables are removed.

Grok Build itself must communicate with grok.com; “no API” here means no developer API, no developer API key, and no direct REST implementation in this plugin.

Related MCP server: DOOMSCROLLR MCP Server

Tools

  • media_doctor: verifies membership auth and the no-API policy without generating media.

  • start_website_video: starts a detached, persistent job and returns a job ID.

  • get_media_job: polls status and returns verified artifacts.

  • list_media_jobs: lists recent jobs.

  • cancel_media_job: stops the local worker without pretending the upstream generation was cancelled.

Routing

ChatGPT browser membership first frame
  -> Grok Build membership image_to_video

ChatGPT unavailable before submission
  -> Grok Build membership image_gen
  -> Grok Build membership image_to_video

If ChatGPT or Grok may already have received a request, the job is not retried.

Setup

git clone https://github.com/Zhao73/grok-membership-media-mcp.git
cd grok-membership-media-mcp
./scripts/setup.sh

Setup installs an isolated runtime at $HOME/.local/share/grok-membership-media-mcp/runtime and an ASCII-safe, non-symlink launcher at $HOME/.local/bin/grok-membership-media-mcp. Use this stable launcher even when the repository lives under Documents or in a path with spaces or non-ASCII names. macOS can deny desktop MCP child processes access to the checkout, and a symlink back to it does not bypass that policy.

Install the same launcher for Codex/Codex Desktop and Claude Code:

codex mcp add grok-membership-media -- \
  "$HOME/.local/bin/grok-membership-media-mcp"

claude mcp add --scope user grok-membership-media -- \
  "$HOME/.local/bin/grok-membership-media-mcp"

Codex Desktop uses the Codex MCP configuration. Claude Desktop uses the same absolute launcher path in ~/Library/Application Support/Claude/claude_desktop_config.json.

The routing skill can be symlinked into both clients:

ln -s "$PWD/skills/grok-membership-media" \
  "$HOME/.codex/skills/grok-membership-media"
ln -s "$PWD/skills/grok-membership-media" \
  "$HOME/.claude/skills/grok-membership-media"

The MCP writes job state to:

~/.local/share/grok-membership-media-mcp/

Generated files are written into the absolute output_dir supplied to start_website_video:

name.mp4
name-web.mp4
name-poster.jpg
name-first-frame.png
name-manifest.json

name.mp4 preserves the Grok audio. name-web.mp4 is muted and fast-started for website autoplay and is always encoded as H.264 8-bit yuv420p. Every user-supplied source image is hash-checked, copied into an immutable per-job snapshot, decoded, cropped/scaled to the requested aspect ratio, and normalized to PNG before Grok video generation.

Before quota can be spent, SQLite atomically reserves output_dir + name. Publishing uses no-replace hard links from a same-filesystem staging directory, so a file that appears concurrently is never overwritten. Completed-job reads recompute every artifact SHA-256, verify the manifest's own SHA-256, and compare its request, output map, and no-developer-API policy with the database record. The manifest is published last. An uncatchable power loss or SIGKILL can leave partial media files, but cannot create a valid completed bundle or trigger an automatic retry.

Example MCP call

{
  "prompt": "A refined black-and-gold product scene matching the current website",
  "motion_prompt": "Slow cinematic push-in, subtle dust and light movement, product remains stable.",
  "output_dir": "/absolute/site/public/media/hero",
  "name": "hero",
  "first_frame_provider": "auto",
  "duration_seconds": 6,
  "resolution": "720p",
  "aspect_ratio": "16:9"
}

Limits

  • Grok membership video accepts 6 or 10 seconds.

  • Video resolution is 480p or 720p.

  • Grok Build has no machine-readable remaining-quota command; quota exhaustion is reported only when the media tool is submitted.

  • All Grok video tasks should be treated as machine-wide single-concurrency; the job store prevents MCP-client restarts from losing status.

ChatGPT browser relay

The GPT route requires chrome-use and its Chrome Web Store extension in the ChatGPT logged-in profile. The CLI/native host can be installed automatically; Chrome itself requires the user to confirm the extension once:

https://chromewebstore.google.com/detail/chrome-use/knfcmbamhjmaonkfnjhldjedeobeafmk

After that confirmation, connect without restarting Chrome:

~/.local/bin/chrome-use reconnect --keep-banner
~/.local/bin/chrome-use extension status --json
~/.local/bin/chrome-use browsers --json

Until the relay is connected, first_frame_provider=auto safely uses Grok membership image generation only when ChatGPT failed before submission. Grok video generation remains fully available.

Verified real output

The demo was submitted through the Grok Build grok.com membership mode and completed with submission=confirmed:

  • site/media/demo.mp4: 6.041667 seconds, 1280x720, silent H.264/yuv420p, fast-started for the web;

  • site/media/demo-evidence.json: sanitized codec, policy, provider, and SHA-256 evidence;

  • full decode, duration, aspect, stream, output hash, manifest hash, state, and policy checks pass in the local completed bundle;

  • the automated suite covers provider policy, job persistence, retry safety, path containment, publication races, artifact verification, and the public site contract.

Requirements

  • macOS and zsh (the currently verified platform);

  • Python 3.11 or newer and uv;

  • FFmpeg and ffprobe;

  • a locally installed, logged-in Grok Build client with paid video quota;

  • optionally, Chrome logged into ChatGPT plus the chrome-use relay for GPT first frames.

Linux and Windows support is not claimed yet.

Development and security

See CONTRIBUTING.md for setup and pull-request rules, and SECURITY.md for private vulnerability reporting. Never attach raw manifests, cookies, local job databases, or provider session files to a public issue.

License and attribution

This project is MIT licensed. The vendored chatgpt-imagegen launcher retains its upstream MIT license and pinned provenance; see THIRD_PARTY_NOTICES.md.

This is an independent, unofficial project. It is not affiliated with, endorsed by, or sponsored by xAI, OpenAI, or Anthropic.

Available Tools

5 tools
cancel_media_jobA

Stop the local worker for a queued/running job. If Grok already received the media tool call, upstream quota consumption may continue; the job is marked cancelled_local or submitted_unknown and is never auto-retried.

ParametersJSON Schema
NameRequiredDescriptionDefault
job_idYes

TDQS

A4.1/5.0
Behavior4/5

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

Discloses that local worker is stopped, upstream quota may continue, and the job is not auto-retried. With no annotations, the description carries the burden and does so adequately.

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 concise sentences with no redundant information; purpose and caveat are clearly front-loaded.

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?

Covers the action, side effects, and status outcomes. Missing details like error handling for non-existent jobs or return values, but acceptable for a simple tool.

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

Parameters2/5

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

The description does not clarify the job_id parameter (e.g., format, source) despite 0% schema coverage. The parameter is simple, but additional context like 'obtained from list_media_jobs' would improve usability.

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

Purpose5/5

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

The description clearly states the specific verb 'Stop' and resource 'local worker for a queued/running job', distinguishing it from sibling tools like list_media_jobs and start_website_video.

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

Usage Guidelines4/5

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

Provides context on upstream quota consumption and job status outcomes, but does not explicitly state when not to use the tool or alternative approaches.

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

get_media_jobA

Return the current status and verified output paths for one media job.

ParametersJSON Schema
NameRequiredDescriptionDefault
job_idYes
include_logNo

TDQS

A3.6/5.0
Behavior3/5

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

Description states it returns status and output paths, implying a read-only operation. No annotations provided; could mention that it does not modify state but is otherwise adequate.

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?

Single sentence with no redundant words. Front-loaded essential information.

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?

Covers core purpose for a simple read operation with 2 params. Lacks explicit output format details but acceptable given no output schema.

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?

With 0% schema description coverage, the description adds minimal meaning: implies job_id is the identifier. Does not explain include_log parameter, leaving ambiguity.

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

Purpose5/5

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

Clear verb 'Return' and resource 'status and verified output paths for one media job.' Distinguishes from siblings like list_media_jobs (multiple) and cancel_media_job (mutation).

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives (e.g., when to poll vs use list_media_jobs). No prerequisites or context provided.

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

list_media_jobsB

List recent membership media jobs without starting any generation.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, so the description must carry all behavioral info. It only states that no generation is started, which is safe, but omits details like whether it is read-only, rate limits, or data freshness.

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?

The description is a single, efficient sentence that immediately conveys the core purpose. No wasted words.

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

Completeness3/5

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

The description is minimal and does not explain what 'recent' means, the structure of returned jobs, or how limit works. For a simple list tool, it is adequate but lacking depth.

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

Parameters1/5

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

The description does not mention the 'limit' parameter at all. With 0% schema description coverage, the description fails to add any meaning beyond the raw schema.

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

Purpose5/5

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

The description clearly states the action 'List', the resource 'membership media jobs', and adds a distinguishing feature 'without starting any generation'. It is specific and distinguishes from siblings like start_website_video.

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

Usage Guidelines3/5

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

The description implies usage for listing jobs without starting generation, but does not explicitly state when to use this tool versus alternatives like get_media_job or cancel_media_job.

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

media_doctorA

Check Grok.com membership login, strict API-key disable policy, ChatGPT browser membership readiness, FFmpeg, state storage, and allowed roots. Does not generate media.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4/5.0
Behavior3/5

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

Without annotations, the description carries full burden. It discloses the tool is read-only by implication ('check') and states it does not generate media, but does not mention side effects, authentication needs, or rate limits.

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

Conciseness4/5

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

Two sentences, one listing checks and one clarifying non-generation. Efficient but could be improved with clearer structure.

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

Completeness3/5

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

Given no output schema, the description should explain return format. It lists what is checked but not what the output looks like (e.g., pass/fail, details). Adequate but missing critical return info.

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

Parameters4/5

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

No parameters exist, so schema coverage is 100%. Per guidelines, baseline is 4; description adds no further parameter info as none needed.

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

Purpose5/5

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

The description lists specific resources to check (Grok.com membership login, API-key disable policy, etc.) and explicitly states 'Does not generate media,' distinguishing it from sibling tools that handle media jobs.

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

Usage Guidelines4/5

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

The description implies usage for pre-checks and policy verification by listing what it checks, but does not explicitly state when to use or when not to use this tool versus alternatives like start_website_video.

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

start_website_videoB

Start an asynchronous website video job using only paid ChatGPT/Grok membership sessions. GPT browser creates the first frame when available; Grok membership image_gen is the safe pre-submit fallback; Grok membership image_to_video creates the MP4. Returns immediately with a job_id.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameNogrok-website-video
promptYes
output_dirYes
resolutionNo720p
create_webmNo
aspect_ratioNo16:9
source_imageNo
motion_promptNoSlow cinematic push-in with subtle atmospheric motion; keep the subject stable.
duration_secondsNo
first_frame_providerNoauto

TDQS

B3/5.0
Behavior3/5

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

The description discloses asynchronous behavior, immediate job_id return, and workflow (GPT first frame, Grok fallback, image_to_video). However, lacks details on error handling, permissions, or side effects. No annotations provided to supplement.

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

Conciseness4/5

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

Three sentences front-load purpose and workflow. Efficient but could be better organized with bullet points or clearer separation of process steps.

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

Completeness2/5

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

With 10 parameters, no annotations, and no output schema, the description is severely incomplete. It omits parameter explanations and return structure, making it hard for an agent to use correctly.

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

Parameters1/5

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

Schema coverage is 0% and description does not explain any of the 10 parameters. It only describes high-level process, leaving parameter semantics entirely to the schema.

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

Purpose5/5

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

The description clearly states the tool starts an asynchronous website video job, specifying use of ChatGPT/Grok sessions. It distinguishes from sibling tools (cancel, get, list, doctor) by focusing on job initiation.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus siblings or alternatives. The description does not mention context, prerequisites, or when not to use it.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 5 tool updatesv0.1.0
    • First observedcancel_media_job
    • First observedget_media_job
    • First observedlist_media_jobs
    • First observedmedia_doctor
    • First observedstart_website_video
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a distinct purpose: cancel, get, list, diagnose, and start. While get_media_job and list_media_jobs both retrieve job info, they are clearly differentiated by specificity. No two tools are easily confused.

Naming Consistency4/5

Four tools follow a consistent verb_noun pattern (cancel_media_job, get_media_job, list_media_jobs, start_website_video). media_doctor breaks this pattern with a noun_verb structure, causing minor inconsistency.

Tool Count5/5

With 5 tools, the server is well-scoped for its purpose of managing media jobs. It covers essential operations without being bloated or too sparse.

Completeness4/5

The tool set covers core operations: start, list, get, cancel, and diagnostic check. Minor gaps like updating or retrying jobs are not critical for the primary workflow, making it nearly complete.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers