Makers Page MCP

The indie stack Model Context Protocol server — one connection for your founder tools, instead of wiring a hundred separate ones.

Indie founders already juggle socials, Stripe, analytics, GitHub, and a database. Each usually means another MCP, another config block, another context the agent doesn't share. Makers Page MCP aggregates those surfaces into one local server your coding agent already understands, so it can draft a launch post with revenue context, check a deploy, or pull product metrics without hopping tools.

makers-page-mcp runs locally next to Cursor, Claude Code, Codex, or any other MCP client. v1 ships X first: your agent drafts a channel-native post about what you just built, you approve it, and it goes out through the real X API v2. Nothing publishes without a human in the loop. More connectors (payments, analytics, GitHub, DBs, and more) are on the roadmap.

makers.page — the indie stack MCP that already knows your tools.

• Why this exists

• How it compares

• Cost per post

• Quick start

  • 1. Create an X developer app

  • 2. Install

  • 3. Set credentials and authorize

  • 4. Connect it to your coding agent

• Works with any MCP client

• Tools

• If a publish attempt fails ambiguously

• Configuration

• Roadmap

• Development

• FAQ

• Contributing

• Security

• License

Why this exists

Most agents end up with a pile of MCP servers — one for GitHub, one for Stripe, one for analytics, one for socials — each with its own auth and none sharing context. Makers Page MCP is the opposite bet: one indie stack connection that already knows the tools founders actually use, so the agent can act across the stack instead of juggling integrations.

Today that means approval-gated publishing to X. Next: the rest of the stack (see Roadmap).

• One MCP, not a hundred. Aggregate the indie stack (socials, payments, analytics, GitHub, DBs) behind a single local server instead of a config file full of one-off connectors.

• Shared context by design. The agent shouldn't re-learn who you are and what you shipped every time it switches tools.

• Agent-native, not another dashboard. Same protocol, same config file as your other MCP servers. No new app to log into.

• Approval-gated by default. Every post is a draft until you explicitly call approve_draft. publish_draft refuses to post anything that hasn't been approved, unless you turn that off yourself. The same pattern will apply to anything that spends money or posts publicly.

• Built for real, paid API calls. X's write API costs money per post (see below). The draft/approve/publish split exists so an agent can never spam your account or your wallet.

• Crash-safe by design. Publishing uses atomic file writes, keyed locks around concurrent operations on the same draft, and a three-way error split (definitive failure, ambiguous network failure, unexpected error) so a dropped connection can never turn into a silent duplicate post.

• Local-first. Drafts and credentials live on your machine (~/.local/share/makers-page-mcp, ~/.config/makers-page-mcp), written with 0600 permissions, not in someone else's cloud.

• Zero lock-in. It's a stdio MCP server distributed on npm under the MIT license. Read the source, fork it, self-host it.

Related MCP server: MCP Twitter

How it compares

v1 covers X posting today; the aggregator columns describe where this indie stack MCP is headed.

Cost per post

As of 2026, X's API is pay-per-use for self-serve developer accounts: creating a post costs $0.015 (plain text) or $0.20 (if the post contains a URL), charged against credits you prepay in the X developer console. There's no free write tier anymore. Every publish_draft call is a real charge: treat it accordingly (approve deliberately, don't script bulk test-publishing).

Quick start

1. Create an X developer app

1. Go to the X developer portal and create (or open) a project + app.

2. Under User authentication settings, enable OAuth 2.0.

3. Set App permissions to Read and write.

4. Set the Type of App to Web App, Automated App or Bot (this gives you a Client ID, and a Client Secret if confidential).

5. Add an exact-match Callback URI / Redirect URL: http://127.0.0.1:8879/callback (must be a loopback host: 127.0.0.1, localhost, or ::1 — non-loopback URIs are rejected at auth time).

6. Copy the Client ID (and Client Secret, if shown).

2. Install

Pick one:

Option A: npm (recommended, no clone needed)

npx -y makers-page-mcp-auth   # run once to authorize, see step 3

npx/bunx fetch and cache the package on first run; nothing to build yourself.

Option B: from source

git clone https://github.com/alexcloudstar/makers.page-mcp.git
cd makers.page-mcp/mcp
bun install
bun run build

3. Set credentials and authorize

Set these environment variables (from your X developer app, step 1):

export TWITTER_CLIENT_ID=your-client-id
export TWITTER_CLIENT_SECRET=your-client-secret   # omit if your app is a public client
export TWITTER_REDIRECT_URI=http://127.0.0.1:8879/callback  # must match the portal exactly

If you're building from source, you can instead copy .env.example to .env and fill in the same values. Bun loads .env automatically for anything run with bun (bun run auth, bun run dev, bun dist/index.js). .env is gitignored, so your keys never get committed.

Run the one-time authorization flow:

npx -y makers-page-mcp-auth   # npm install
bun run auth                  # from source

This prints an authorize URL: open it, log in as the X account you want to post from, and approve. The server captures the redirect locally and stores an access + refresh token at ~/.config/makers-page-mcp/credentials.json. Tokens auto-refresh on future use; re-run auth if you revoke access, or after upgrading to a version that adds scopes (e.g. media.write for image/GIF/video uploads).

4. Connect it to your coding agent

Add to your Cursor mcp.json (Settings → MCP, or ~/.cursor/mcp.json). The same shape works for Claude Desktop/Code, Codex, GitHub Copilot, and other MCP clients, just under each tool's own config file:

If you installed via npm:

{
  "mcpServers": {
    "makers-page": {
      "command": "npx",
      "args": ["-y", "makers-page-mcp"],
      "env": {
        "TWITTER_CLIENT_ID": "your-client-id",
        "TWITTER_CLIENT_SECRET": "your-client-secret",
        "TWITTER_REDIRECT_URI": "http://127.0.0.1:8879/callback"
      }
    }
  }
}

(bunx works the same way if you'd rather use Bun: "command": "bunx", "args": ["-y", "makers-page-mcp"].)

If you built from source:

{
  "mcpServers": {
    "makers-page": {
      "command": "bun",
      "args": ["--env-file=/absolute/path/to/mcp/.env", "/absolute/path/to/mcp/dist/index.js"]
    }
  }
}

Bun's automatic .env loading is relative to the process's working directory, which most MCP clients don't guarantee is mcp/. The explicit --env-file flag above points straight at your .env regardless of where the server is launched from, so you don't have to duplicate credentials inside mcp.json itself.

Works with any MCP client

This server only uses the standard MCP stdio transport: no client-specific extensions, no remote/HTTP requirement. That means the same command/args/env block above works everywhere, just under each client's own config file:

All of these read the same mcpServers-style JSON (Gemini CLI and JetBrains use slightly different top-level keys, mcpServers and a UI form respectively, but the same command/args/env fields underneath). If your tool of choice isn't listed here but supports MCP over stdio, the config above should work unchanged.

Tools

Typical retweet flow: create_retweet_draft → user approves → approve_retweet_draft → retweet_post (or undo_retweet for undo drafts).

Typical DM flow: lookup_x_user (optional) → create_dm_draft → user approves → approve_dm_draft → send_dm_draft.

To reply in context: list_dm_inbox or list_dm_conversation_events → draft with conversationId → approve → send.

X create/update fields

Caveats (X product limits)

• Links in comments, not the main post: By default, create_draft / update_draft / edit_published_draft reject http:// or https:// URLs in text / parts[0]. Put links in follow-up thread parts (parts[1], parts[2], …). Override only with allowLinksInMainPost: true when the user forces it.

• Re-auth for media: OAuth scopes now include media.write. If you authorized before this change, run makers-page-mcp-auth / bun run auth once more.

• Re-auth for DMs: OAuth scopes now include dm.read and dm.write. Re-run auth after upgrading to send or read DMs.

• Quote posts: OpenAPI documents quote as Enterprise-only on self-serve; expect API errors on lower tiers.

• Edit: Requires X Premium, roughly a 30-minute window and up to 5 edits from the original. Each edit returns a new post id (we update the local draft). Polls and community posts are not editable.

• Replies: Self-serve apps can create self-threads (reply to your own previous part). Replies to other accounts are blocked unless summoned.

• Cashtags: Self-serve allows at most one cashtag ($TICKER) per post.

If a publish attempt fails ambiguously

publish_draft marks a draft publishing before calling the X API, and only clears that if the API gives a definitive answer (a real HTTP response, or a clear "not authenticated" error). If the request instead fails in a way that could mean X received it anyway (a timeout or network drop), the draft is deliberately left in publishing and not auto-reverted, so an agent can't retry and risk a second, real, paid post.

Reconciliation:

• Nothing posted (no live ids recorded): call reject_draft or update_draft to reset.

• Partial thread (some ids recorded): do not retry publish_draft. Call delete_published_draft to remove the live posts, or finish the remainder on X manually.

• Ambiguous single post (may or may not have posted, no ids recorded): check X yourself; if it did not post, reset with reject_draft / update_draft; if it did, leave the draft as-is and note the URL.

Configuration

Environment variables:

Roadmap

Destination: one local indie stack MCP that already knows the founder tools — socials, payments, analytics, GitHub, databases — so you don't maintain a hundred separate connections. v1 ships X only, on purpose: prove the approval-gated write loop before adding more surfaces that spend money or post publicly.

Shipped

• X manage-posts: text, threads, polls, media (chunked upload), quote, community + share_with_followers, paid partnership, edit, and delete — still behind draft → approve → publish with crash-safe / no-auto-retry semantics.

• X DMs: draft → approve → send (1:1 text, media attachment, group conversations) with local rate limits; read inbox and thread events; @handle lookup.

• X analytics (read-only): post metrics, account summary (today + top posts), posting-time analysis. No local DB; fetches from X API on demand.

• X retweets: draft → approve → retweet_post / undo_retweet (immediate; no scheduling).

Next

1. More socials — LinkedIn, Reddit, Threads, Bluesky; same draft adapted to channel-native tone and length.

2. Payments & code — Stripe (Lemon Squeezy as a secondary path), GitHub.

3. Analytics & data — PostHog / Plausible, Postgres via Supabase / Neon.

4. Ops extras — Resend, Sentry, as the core set stabilizes.

5. Launch directories — research launches and draft listing copy where useful; submit only where a stable API or first-class MCP write path exists. Today that is thin: Product Hunt community MCPs are read-only (the PH API has no create-post mutation), Hacker News write MCPs scrape browser login (no public write API), and Peerlist / BetaList / Uneed / Fazier / Microlaunch / Dev Hunt / Tiny Launch have no MCP for submissions. MCP registries (official registry, Smithery, PulseMCP, Glama, mcp.so) are for listing this server, not for submitting your product to launch boards.

Always

• Local-only drafts and credentials, whichever connectors land.

• Approval gates for anything that posts publicly or spends money.

Want a connector prioritized? Open an issue.

Development

bun test        # run the unit test suite
bun run typecheck

FAQ

No, not by default. Every draft starts in draft status, and publish_draft refuses to run unless the draft has gone through approve_draft first. You can disable that gate with MAKERS_PAGE_REQUIRE_APPROVAL=false if you fully trust the flow, but it's opt-in.

It's a local process. Drafts, DM drafts, retweet drafts, and rate-limit state are stored as files under MAKERS_PAGE_DATA_DIR (default ~/.local/share/makers-page-mcp); your X OAuth tokens live under MAKERS_PAGE_CONFIG_DIR (default ~/.config/makers-page-mcp/credentials.json). All of these files are written with 0600 permissions. Nothing goes through a third-party server; the server talks directly to api.x.com.

That's an X API pricing decision, not this project's. As of 2026 there's no free write tier for X's API; see Cost per post above for current rates. The approval gate exists specifically so an agent can't accidentally run up a bill.

See If a publish attempt fails ambiguously. Short version: definitive failures revert the draft automatically; anything ambiguous (timeouts, dropped connections) is left in publishing for you to check and reconcile manually, so you never get a silent double-post.

Yes. It's a plain stdio MCP server with no client-specific extensions, so it works anywhere MCP is supported: Claude Desktop/Code, OpenAI Codex, Gemini CLI, GitHub Copilot, Windsurf, Cline, Zed, JetBrains AI Assistant, and more. See Works with any MCP client.

Yes, it's MIT-licensed. See Option B: from source to build it yourself, and CONTRIBUTING.md if you want to send changes back upstream.

Contributing

Contributions are welcome. See CONTRIBUTING.md for setup, testing, and PR guidelines.

Security

Found a vulnerability? Please don't open a public issue: see SECURITY.md for how to report it privately.

License

MIT. See the changelog for release notes.