Makers Page MCP

Consigue que tu producto sea visto sin el trabajo de marketing.

GitHub
4
Prueba este MCPPatrocinado

Documentación

Makers Page MCP

El servidor Model Context Protocol del stack indie — una sola conexión para tus herramientas de fundador, en lugar de conectar un centenar por separado.

Los fundadores independientes ya tienen que lidiar con redes sociales, Stripe, analíticas, GitHub y una base de datos. Cada una suele significar otro MCP, otro bloque de configuración, otro contexto que el agente no comparte. Makers Page MCP agrega esas superficies en un único servidor local que tu agente de código ya entiende, para que pueda redactar un post de lanzamiento con contexto de ingresos, revisar un despliegue o consultar métricas de producto sin saltar de herramienta en herramienta.

makers-page-mcp se ejecuta localmente junto a Cursor, Claude Code, Codex o cualquier otro cliente MCP. La v1 trae X primero: tu agente redacta un post nativo del canal sobre lo que acabas de construir, tú lo apruebas, y sale a través de la API real de X v2. Nada se publica sin un humano en el circuito. Más conectores (pagos, analíticas, GitHub, bases de datos y más) están en el roadmap.

License: MIT npm version npm downloads MCP Registry makers.page-mcp MCP server Node Bun

makers.page — el MCP del stack indie que ya conoce tus herramientas.

Tabla de contenidos

Por qué existe esto

La mayoría de los agentes terminan con un montón de servidores MCP — uno para GitHub, uno para Stripe, uno para analíticas, uno para redes sociales — cada uno con su propia autenticación y ninguno comparte contexto. Makers Page MCP es la apuesta contraria: una única conexión de stack indie que ya conoce las herramientas que los fundadores usan de verdad, para que el agente pueda actuar en todo el stack en lugar de gestionar integraciones sueltas.

Hoy eso significa publicación en X con aprobación previa. Después: el resto del stack (ver Roadmap).

  • Un solo MCP, no un centenar. Agrega el stack indie (redes sociales, pagos, analíticas, GitHub, bases de datos) detrás de un único servidor local en lugar de un archivo de configuración lleno de conectores sueltos.
  • Contexto compartido por diseño. El agente no debería tener que reaprender quién eres y qué has lanzado cada vez que cambia de herramienta.
  • Nativo de agentes, no otro panel. Mismo protocolo, mismo archivo de configuración que tus otros servidores MCP. Sin nueva app a la que iniciar sesión.
  • Aprobación obligatoria por defecto. Cada post es un draft hasta que llamas explícitamente a approve_draft. publish_draft se niega a publicar nada que no haya sido aprobado, a menos que tú mismo lo desactives. El mismo patrón se aplicará a cualquier cosa que gaste dinero o publique contenido públicamente.
  • Construido para llamadas API reales de pago. La API de escritura de X cuesta dinero por post (ver abajo). La separación borrador/aprobación/publicación existe para que un agente nunca pueda hacer spam a tu cuenta ni a tu cartera.
  • A prueba de caídas por diseño. La publicación usa escrituras atómicas de archivos, bloqueos con llave alrededor de operaciones concurrentes sobre el mismo borrador, y una división de errores en tres vías (fallo definitivo, fallo de red ambiguo, error inesperado) para que una conexión caída nunca se convierta en un post duplicado silencioso.
  • Local primero. Los borradores y las credenciales viven en tu máquina (~/.local/share/makers-page-mcp, ~/.config/makers-page-mcp), escritos con permisos 0600, no en la nube de otra persona.
  • Cero dependencia de proveedor. Es un servidor MCP stdio distribuido en npm bajo licencia MIT. Lee el código fuente, haz un fork, haz self-hosting.

Cómo se compara

Manual / saltando entre navegadoresUn MCP por herramientaZapier / MakeMakers Page MCP
Vive dentro de tu agente de códigoNoSíNoSí
Una conexión para el stack indieNoNo (N configs)Parcial (N apps)Sí (agrega)
Contexto compartido entre redes, dinero, código, datosNoNoSolo con pegamentoSí (destino)
Aprobación humana antes de publicar o gastarDepende de tiDepende de cada servidorNo (auto-triggered)Sí, por defecto
Código abierto / self-hostable(n/d)VaríaNoSí (MIT)
Dónde viven los datosEn tiMixtoSus servidoresTu máquina

La v1 cubre la publicación en X hoy; las columnas del agregador describen hacia dónde se dirige este MCP del stack indie.

Costo por post

A partir de 2026, la API de X es de pago por uso para cuentas de desarrollador de autoservicio: crear un post cuesta $0.015 (texto plano) o $0.20 (si el post contiene una URL), cargado contra créditos que preparas en la consola de desarrollador de X. Ya no hay nivel de escritura gratuito. Cada llamada a publish_draft es un cargo real: trátala como tal (aprueba deliberadamente, no automatices publicaciones de prueba en masa).

Inicio rápido

1. Crea una app de desarrollador de X

  1. Ve al portal de desarrolladores de X y crea (o abre) un proyecto + app.
  2. En User authentication settings, habilita OAuth 2.0.
  3. Configura App permissions a Read and write.
  4. Configura el Type of App a Web App, Automated App or Bot (esto te da un Client ID, y un Client Secret si es confidencial).
  5. Añade un Callback URI / Redirect URL de coincidencia exacta: http://127.0.0.1:8879/callback (debe ser un host loopback: 127.0.0.1, localhost o ::1 — los URI que no sean loopback se rechazan en el momento de la autenticación).
  6. Copia el Client ID (y el Client Secret, si se muestra).

2. Instalación

Elige una:

Opción A: npm (recomendada, sin necesidad de clonar)

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

npx/bunx descargan y almacenan en caché el paquete en la primera ejecución; no hay nada que compilar tú mismo.

Opción B: desde el código fuente

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

3. Configura credenciales y autoriza

Configura estas variables de entorno (de tu app de desarrollador de X, paso 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

Si estás compilando desde el código fuente, puedes copiar .env.example a .env y completar los mismos valores. Bun carga .env automáticamente para cualquier cosa ejecutada con bun (bun run auth, bun run dev, bun dist/index.js). .env está en gitignore, así que tus claves nunca se commitean.

Ejecuta el flujo de autorización de una sola vez:

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

Esto imprime una URL de autorización: ábrela, inicia sesión con la cuenta de X desde la que quieres publicar y aprueba. El servidor captura la redirección localmente y almacena un token de acceso + actualización en ~/.config/makers-page-mcp/credentials.json. Los tokens se renuevan automáticamente en usos futuros; vuelve a ejecutar la autenticación si revocas el acceso, o después de actualizar a una versión que añada scopes (p. ej. media.write para subidas de imágenes/GIFs/videos).

4. Conéctalo a tu agente de código

Añádelo a tu mcp.json de Cursor (Settings → MCP, o ~/.cursor/mcp.json). La misma forma funciona con Claude Desktop/Code, Codex, GitHub Copilot y otros clientes MCP, solo que en el archivo de configuración propio de cada herramienta:

Si lo instalaste vía 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 funciona igual si prefieres usar Bun: "command": "bunx", "args": ["-y", "makers-page-mcp"].)

Si lo compilaste desde el código fuente:

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

La carga automática de .env de Bun es relativa al directorio de trabajo del proceso, que la mayoría de los clientes MCP no garantizan que sea mcp/. La bandera explícita --env-file de arriba apunta directamente a tu .env sin importar desde dónde se lance el servidor, para que no tengas que duplicar credenciales dentro de mcp.json.

Funciona con cualquier cliente MCP

Este servidor solo usa el transporte estándar MCP stdio: sin extensiones específicas de cliente, sin requisito remoto/HTTP. Eso significa que el mismo bloque command/args/env de arriba funciona en todas partes, solo que en el archivo de configuración propio de cada cliente:

ClienteArchivo de configuración
Cursor~/.cursor/mcp.json (o Settings → MCP)
Claude Desktopclaude_desktop_config.json
Claude Code.mcp.json (proyecto) o ~/.claude.json (usuario)
OpenAI Codex (CLI, Desktop, extensión IDE)~/.codex/config.toml, o ejecuta codex mcp add makers-page -- npx -y makers-page-mcp
Google Gemini CLI~/.gemini/settings.json (global) o .gemini/settings.json (proyecto), o gemini mcp add
GitHub Copilot (VS Code, Copilot SDK).vscode/mcp.json o mcp.json
Windsurf (Cascade)~/.codeium/windsurf/mcp_config.json, misma forma command/args que Cursor
Cline (extensión VS Code / JetBrains)su panel de configuración de MCP, o el cline_mcp_settings.json subyacente
Zedsettings.json → context_servers
JetBrains AI Assistant (IntelliJ, PyCharm, WebStorm, ...)Settings → Tools → AI Assistant → MCP Servers → Add (stdio)

Todos estos leen el mismo JSON de estilo mcpServers (Gemini CLI y JetBrains usan claves de nivel superior ligeramente diferentes, mcpServers y un formulario de UI respectivamente, pero los mismos campos command/args/env debajo). Si tu herramienta de preferencia no está en la lista pero soporta MCP sobre stdio, la configuración de arriba debería funcionar sin cambios.

Herramientas

HerramientaQué hace
create_draftGuardar una nueva publicación en borrador para X. Obligatorio: { channel: "x", text }. Opcional: parts (hilo), poll, mediaPaths (rutas locales absolutas, máx. 4), quoteTweetId, communityId, shareWithFollowers, paidPartnership, allowLinksInMainPost. No se permiten enlaces http(s) en la publicación principal — coloca las URLs en parts[1+] a menos que el usuario fuerce explícitamente allowLinksInMainPost.
list_draftsListar borradores, opcionalmente filtrados por estado (draft, approved, rejected, publishing, published, deleted).
get_draftObtener un borrador individual por id.
update_draftEditar el contenido de un borrador (mismos campos que en crear; pasa null para limpiar un campo opcional). Restablece un borrador aprobado o rechazado a draft para que pueda volver a aprobarse.
approve_draftMarcar un borrador como aprobado. Obligatorio antes de publicar (salvo que las aprobaciones estén desactivadas).
reject_draftMarcar un borrador como rechazado. También reconcilia un borrador atascado en publishing cuando no se publicó nada (sin ids en vivo registrados). Si se registraron ids en vivo, usa delete_published_draft en su lugar.
publish_draftPublicar un borrador aprobado en X mediante POST /2/tweets (sube los medios primero cuando sea necesario; los hilos responden a la parte anterior). Devuelve la(s) URL en vivo. Si la solicitud falla de forma ambigua (p. ej., un timeout) o un hilo falla a mitad de camino, el borrador queda en publishing en lugar de reintentarse automáticamente.
edit_published_draftEditar la publicación raíz de un borrador publicado (edit_options.previous_post_id). Vuelve a adjuntar medios/cita cuando estén presentes. Cada edición crea un nuevo id de publicación, que se almacena localmente. Rechaza encuestas y publicaciones de comunidades.
delete_published_draftEliminar cada id de publicación almacenado en X siempre que haya ids en vivo registrados (publicados, publishing parcial o registros heredados/corruptos), y luego marcar el borrador local como deleted.
get_x_accountComprobar el estado de la conexión y mostrar el @handle conectado.
lookup_x_userResolver un @handle a un id de usuario (y elegibilidad para MD).
get_dm_rate_limitMostrar los límites locales de envío de MD y el uso actual.
create_dm_draftGuardar un borrador de MD. Obligatorio: text más un destinatario: recipientId/recipientUsername (1:1), participantIds/participantUsernames con conversationType: "group" (grupo nuevo) o conversationId (respuesta). Opcional: una entrada de mediaPaths.
list_dm_draftsListar borradores de MD, opcionalmente filtrados por estado (draft, approved, rejected, sending, sent, deleted).
get_dm_draftObtener un borrador de MD individual por id.
update_dm_draftEditar un borrador de MD (pasa null para limpiar campos opcionales). Restablece los borradores aprobados a draft.
approve_dm_draftMarcar un borrador de MD como aprobado. Obligatorio antes de enviar (salvo que las aprobaciones estén desactivadas).
reject_dm_draftMarcar un borrador de MD como rechazado, o reconciliar uno atascado en sending.
send_dm_draftEnviar un MD aprobado mediante la API de X. Aplica los límites locales de tasa.
list_dm_eventsLeer eventos recientes en un hilo de MD 1:1 (participantId o username).
list_dm_inboxLeer eventos de MD recientes en todas las conversaciones (vista de bandeja de entrada para el contexto del agente).
list_dm_conversation_eventsLeer eventos recientes en una conversación por conversationId (hilo 1:1 o de grupo).
get_x_post_metricsObtener impresiones, me gusta, reposts, respuestas, citas y marcadores de hasta 100 ids de publicación.
get_x_account_summaryImpresiones y participación por día calendario mediante GET /2/tweets/analytics (alineado con la analítica de la cuenta x.com). Totales del período y publicaciones principales de la ventana.
analyze_x_posting_timesAnálisis por hora del día: impresiones promedio y tasa de participación según cuándo publicaste.
get_top_engagersClasificar quién comentó más en tus publicaciones X de nivel superior para un día calendario determinado (por defecto ayer, con reconocimiento de zona horaria). Encuentra las publicaciones de nivel superior que iniciaste ese día mediante GET /2/users/:id/tweets y, para cada una, extrae cada respuesta en la conversación de esa publicación mediante GET /2/tweets/search/recent (barre todas las respuestas en cualquier parte de un hilo, no solo la raíz), excluyéndote a ti mismo. Clasifica a los comentaristas por número de comentarios y luego por me gusta en sus comentarios. Solo lectura; sin borradores. Se aplica el mismo límite de Búsqueda Reciente de 7 días que en be_trendy para fechas más antiguas.
be_trendyDescubrir qué está en tendencia ahora mismo en X dentro de un nicho de producto específico, mediante Búsqueda Reciente de X limitada al nicho/palabras clave, no a la lista global genérica de tendencias de X. Obligatorio: productName, productDescription, niche, targetAudience. Opcional: keywords, language. Filtra spam y casi duplicados, y luego devuelve trendingTopics puntuados (con tweets de muestra y cifras de participación), painPointSignals (publicaciones con señales de demanda que piden recomendaciones/alternativas) y un recommendation de sincronización de publicación. No genera contenido por sí mismo: usa los datos devueltos más el contexto del producto para redactar la publicación real.
create_retweet_draftGuardar un borrador de retweet o deshacer-retweet para un id de publicación. No se ejecuta hasta que se apruebe.
list_retweet_draftsListar borradores de retweet/deshacer, opcionalmente filtrados por estado.
get_retweet_draftObtener un borrador individual de retweet/deshacer por id.
approve_retweet_draftMarcar un borrador de retweet/deshacer como aprobado (obligatorio antes de la ejecución salvo que las aprobaciones estén desactivadas).
reject_retweet_draftMarcar un borrador de retweet/deshacer como rechazado; también reconcilia borradores atascados en ejecución.
retweet_postRetweetear un borrador aprobado inmediatamente mediante POST /2/users/:id/retweets.
undo_retweetDeshacer un borrador de retweet aprobado mediante DELETE /2/users/:id/retweets/:tweet_id.
Flujo típico del agente: create_draft → mostrar el borrador al usuario → el usuario dice "aprobar" → approve_draft → publish_draft.

Flujo típico de retweet: create_retweet_draft → el usuario aprueba → approve_retweet_draft → retweet_post (o undo_retweet para borradores de deshacer).

Flujo típico de MD: lookup_x_user (opcional) → create_dm_draft → el usuario aprueba → approve_dm_draft → send_dm_draft.

Para responder en contexto: list_dm_inbox o list_dm_conversation_events → redactar con conversationId → aprobar → enviar.

Flujo típico de descubrimiento de tendencias: be_trendy → el agente redacta una publicación a partir de los trendingTopics/painPointSignals devueltos → create_draft → el usuario aprueba → publish_draft.

Campos de creación/actualización de X

CampoNotas
textTexto principal de la publicación. Debe ser igual a parts[0] cuando parts está definido. En update_draft, si se envían tanto text como parts y discrepan, text gana y se convierte en parts[0]. Sin URLs http(s) a menos que allowLinksInMainPost sea verdadero.
partsHilo de 2 o más publicaciones. Cada parte posterior a la primera responde a la anterior (cadena de hilo estándar de X). Coloca todos los enlaces en parts[1+], nunca en la publicación principal. No se permiten encuestas en los hilos.
poll{ options: string[2..4], durationMinutes: 5..10080 }. Mutuamente excluyente con mediaPaths y quoteTweetId.
mediaPathsRutas locales absolutas (.jpg/.jpeg/.png/.webp/.gif/.mp4), 1–4 archivos. Hasta 4 imágenes, o un GIF, o un video (sin mezclar). Los enlaces simbólicos se rechazan; el MIME/categoría se elige según la extensión del archivo y se verifica con detección de bytes mágicos antes de subir. Requiere reautenticación con media.write (ver más abajo).
quoteTweetIdCitar otra publicación. Solo para empresas en los niveles de API de X de autoservicio / pago por uso; la herramienta igual lo envía; X puede rechazarlo.
communityId / shareWithFollowersPublicar en una Comunidad; shareWithFollowers requiere communityId.
paidPartnershipDefine paid_partnership: true al crear (y al editar si se proporciona).
allowLinksInMainPostOptar por no aplicar la prohibición predeterminada de enlaces en la publicación principal. Solo cuando el usuario lo exige explícitamente.

Advertencias (límites del producto X)

  • Enlaces en comentarios, no en la publicación principal: Por defecto, create_draft / update_draft / edit_published_draft rechazan URLs de http:// o https:// en text / parts[0]. Coloca los enlaces en partes posteriores del hilo (parts[1], parts[2], …). Anula solo con allowLinksInMainPost: true cuando el usuario lo fuerce.
  • Reautenticación para medios: Los alcances de OAuth ahora incluyen media.write. Si autorizaste antes de este cambio, ejecuta makers-page-mcp-auth / bun run auth una vez más.
  • Reautenticación para MD: Los alcances de OAuth ahora incluyen dm.read y dm.write. Vuelve a ejecutar la autenticación después de actualizar para enviar o leer MD.
  • Citas: Los documentos de OpenAPI describen las citas como solo para empresas en autoservicio; espera errores de API en niveles inferiores.
  • Edición: Requiere X Premium, aproximadamente una ventana de 30 minutos y hasta 5 ediciones desde la publicación original. Cada edición devuelve un nuevo id de publicación (actualizamos el borrador local). Las encuestas y las publicaciones de comunidades no se pueden editar.
  • Respuestas: Las aplicaciones de autoservicio pueden crear auto-hilos (responder a su propia parte anterior). Las respuestas a cuentas de otros están bloqueadas salvo invocación explícita.
  • Cashtags: El autoservicio permite como máximo un cashtag ($TICKER) por publicación.
  • be_trendy requiere un nivel de API de pago: llama al endpoint de Búsqueda Reciente de X, que necesita al menos un nivel de acceso de API de X Basic de pago. Una aplicación de nivel gratuito recibirá errores 403/429.
  • get_top_engagers también usa Búsqueda Reciente, por lo que necesita el mismo nivel de pago y solo ve comentarios de los últimos 7 días, sin importar la antigüedad de la publicación que se esté revisando.

Si un intento de publicación falla de forma ambigua

publish_draft marca un borrador como publishing antes de llamar a la API de X, y solo lo limpia si la API da una respuesta definitiva (una respuesta HTTP real o un error claro de "no autenticado"). Si la solicitud falla de una manera que podría significar que X la recibió de todos modos (un timeout o una caída de red), el borrador se deja deliberadamente en publishing y no se revierte automáticamente, para que un agente no pueda reintentar y arriesgar una segunda publicación real de pago.

Reconciliación:

  • No se publicó nada (sin ids en vivo registrados): llama a reject_draft o update_draft para restablecer.
  • Hilo parcial (algunos ids registrados): no reintentes publish_draft. Llama a delete_published_draft para eliminar las publicaciones en vivo, o completa el resto manualmente en X.
  • Publicación única ambigua (pudo haberse publicado o no, sin ids registrados): verifica en X tú mismo; si no se publicó, restablece con reject_draft / update_draft; si se publicó, deja el borrador tal cual y anota la URL.

Configuración

Variables de entorno:

VariablePredeterminadoPropósito
TWITTER_CLIENT_ID(ninguno)Obligatorio. ID de Cliente OAuth 2.0 de X/Twitter.
TWITTER_CLIENT_SECRET(ninguno)Se define si tu aplicación de X es un cliente confidencial.
TWITTER_REDIRECT_URIhttp://127.0.0.1:8879/callbackDebe coincidir con el callback registrado en el portal de desarrolladores de X y usar un host de loopback (127.0.0.1, localhost o ::1).
MAKERS_PAGE_CONFIG_DIR~/.config/makers-page-mcpDónde se almacenan las credenciales.
MAKERS_PAGE_DATA_DIR~/.local/share/makers-page-mcpDónde se almacenan los borradores.
MAKERS_PAGE_REQUIRE_APPROVALtrueSe establece en false para permitir que los agentes publiquen borradores sin un paso de aprobación separado.
MAKERS_PAGE_MAX_POST_LENGTH280Máximo de caracteres por publicación (recuento ponderado de X: las URLs cuentan como 23, los emojis cuentan una vez); auméntalo si estás en X Premium.
MAKERS_PAGE_MAX_DM_LENGTH10000Máximo de caracteres por MD.
MAKERS_PAGE_DM_MAX_PER_HOUR10Límite local de envíos de MD por hora móvil (antes de llamar a X).
MAKERS_PAGE_DM_MAX_PER_DAY50Límite local de envíos de MD por 24 horas móviles.
MAKERS_PAGE_DM_MIN_INTERVAL_MS3000Mínimo de milisegundos entre envíos consecutivos de MD.

Hoja de ruta

Destino: un MCP local de stack indie que ya conoce las herramientas del fundador — redes sociales, pagos, analíticas, GitHub, bases de datos — para que no mantengas cien conexiones separadas. v1 incluye solo X, a propósito: probar el bucle de escritura con aprobación antes de añadir más superficies que gasten dinero o publiquen públicamente.

Lanzado

  • X gestionar publicaciones: texto, hilos, encuestas, medios (subida por partes), cita, comunidad + share_with_followers, asociación de pago, editar y eliminar — aún detrás de borrador → aprobar → publicar con semántica segura ante fallos / sin reintento automático.
  • X mensajes directos: borrador → aprobar → enviar (texto 1:1, adjunto multimedia, conversaciones de grupo) con límites de velocidad locales; leer bandeja de entrada y eventos de hilo; búsqueda de @handle.
  • X analíticas (solo lectura): métricas de publicaciones, resumen de cuenta (hoy + publicaciones principales), análisis de tiempo de publicación. Sin base de datos local; obtiene datos de la API de X bajo demanda.
  • X retweets: borrador → aprobar → retweet_post / undo_retweet (inmediato; sin programar).
  • be_trendy: descubrimiento de tendencias de X por nicho mediante Recent Search, filtrado de spam/duplicados, y temas de tendencia puntuados + señales de demanda para fundamentar el contenido que escribe el agente (sin llamada LLM dentro de la propia herramienta).

Siguiente

  1. Más redes sociales — LinkedIn, Reddit, Threads, Bluesky; mismo borrador adaptado al tono y longitud nativos del canal.
  2. Pagos y código — Stripe (Lemon Squeezy como vía secundaria), GitHub.
  3. Analíticas y datos — PostHog / Plausible, Postgres vía Supabase / Neon.
  4. Extras operativos — Resend, Sentry, a medida que se estabiliza el conjunto central.
  5. Directorios de lanzamiento — investigar lanzamientos y redactar copia de listados donde sea útil; enviar solo donde exista una API estable o una ruta de escritura MCP de primera clase. Hoy eso es escaso: los MCP comunitarios de Product Hunt son de solo lectura (la API de PH no tiene mutación de crear publicación), los MCP de escritura de Hacker News hacen scraping del inicio de sesión del navegador (sin API de escritura pública), y Peerlist / BetaList / Uneed / Fazier / Microlaunch / Dev Hunt / Tiny Launch no tienen MCP para envíos. Los registros de MCP (registro oficial, Smithery, PulseMCP, Glama, mcp.so) sirven para listar este servidor, no para enviar tu producto a plataformas de lanzamiento.

Siempre

  • Borradores y credenciales solo locales, sin importar qué conectores lleguen.
  • Puertas de aprobación para cualquier cosa que publique públicamente o gaste dinero.

¿Quieres que un conector tenga prioridad? Abre un issue.

Desarrollo

bun test        # run the unit test suite
bun run typecheck

FAQ

¿Esto publica automáticamente, sin que yo lo vea primero?

No, no por defecto. Cada borrador comienza en estado draft, y publish_draft se niega a ejecutarse a menos que el borrador haya pasado por approve_draft primero. Puedes desactivar esa puerta con MAKERS_PAGE_REQUIRE_APPROVAL=false si confías completamente en el flujo, pero es optativo.

¿Es un servicio alojado? ¿A dónde van mis datos?

Es un proceso local. Los borradores, borradores de DM, borradores de retweet y el estado de límite de velocidad se almacenan como archivos bajo MAKERS_PAGE_DATA_DIR (por defecto ~/.local/share/makers-page-mcp); tus tokens OAuth de X viven bajo MAKERS_PAGE_CONFIG_DIR (por defecto ~/.config/makers-page-mcp/credentials.json). Todos estos archivos se escriben con permisos 0600. Nada pasa por un servidor de terceros; el servidor habla directamente con api.x.com.

¿Por qué crear una publicación cuesta dinero?

Es una decisión de precios de la API de X, no de este proyecto. Desde 2026 no hay un nivel de escritura gratuito para la API de X; consulta Costo por publicación arriba para las tarifas actuales. La puerta de aprobación existe precisamente para que un agente no pueda acumular una factura por accidente.

¿Qué pasa si la publicación falla a mitad de camino?

Consulta Si un intento de publicación falla de forma ambigua. Versión corta: los fallos definitivos revierten el borrador automáticamente; cualquier cosa ambigua (tiempos de espera, conexiones caídas) se deja en publishing para que la revises y reconcilies manualmente, así nunca obtienes una doble publicación silenciosa.

¿Esto funciona con agentes distintos de Cursor?

Sí. Es un servidor MCP stdio estándar sin extensiones específicas de cliente, así que funciona en cualquier lugar donde se soporte MCP: Claude Desktop/Code, OpenAI Codex, Gemini CLI, GitHub Copilot, Windsurf, Cline, Zed, JetBrains AI Assistant y más. Consulta Funciona con cualquier cliente MCP.

¿Puedo autoalojar o bifurcar esto en lugar de usar el paquete npm?

Sí, tiene licencia MIT. Consulta Opción B: desde el código fuente para compilarlo tú mismo, y CONTRIBUTING.md si quieres enviar cambios de vuelta al proyecto original.

Contribuciones

Las contribuciones son bienvenidas. Consulta CONTRIBUTING.md para la configuración, pruebas y pautas de PR.

Seguridad

¿Encontraste una vulnerabilidad? Por favor no abras un issue público: consulta SECURITY.md para saber cómo reportarla de forma privada.

Licencia

MIT. Consulta el changelog para notas de versión.

Construido por @alexcloudstar para makers.page — el MCP de stack indie.