¿Puedo vibecodear Composio?

PARCIAL · un fin de semana

precio $29/mesahorrarías $348/añotiempo de build una sentadacategoría 🛠️ herramientas de desarrolloreemplazada por 0 personas

If you personally use four apps, not four hundred, most of Composio evaporates. An agent can write you a local MCP server that wraps Gmail, Slack, GitHub and Notion with your own personal access tokens in about a session, and the tool-calling loop works fine. What you are actually buying from Composio is the part nobody enjoys: OAuth app registration per provider, token refresh, per-user credential storage, rate limit handling, and schemas for tools you have not thought of yet. That gets ugly the moment you want more than a handful of integrations, or multiple users, or an OAuth flow instead of a static token you pasted in. Solo and token-based: build it. Multi-tenant or breadth-hungry: pay.

el prompt

Build a local MCP (Model Context Protocol) server in TypeScript that gives an AI agent working tools for my own SaaS accounts, using personal access tokens. No hosted service, no accounts, no telemetry.

Stack, non-negotiable:
- Node 20+, TypeScript, pnpm
- @modelcontextprotocol/sdk over stdio transport
- zod for tool input schemas
- undici fetch for HTTP, no per-provider SDKs

Structure:
- src/index.ts: server bootstrap, registers every tool module
- src/providers/gmail.ts, slack.ts, github.ts, notion.ts
- src/http.ts: one shared request helper with timeout, retry on 429 and 5xx with exponential backoff, and error normalization
- .env.example listing every token var, .env gitignored, fail loudly at startup if a token for an enabled provider is missing

Tools to implement, keep them small and honest:
- gmail_search_messages, gmail_get_message, gmail_send_message
- slack_list_channels, slack_post_message, slack_search_messages
- github_list_issues, github_create_issue, github_comment_issue
- notion_search, notion_get_page, notion_append_block
Each tool: zod-validated input, a one-line description an LLM can act on, and output trimmed to useful fields only, never raw API dumps.

In scope: static token auth, a PROVIDERS env var to enable a subset, structured logging to stderr only (stdout is the MCP channel), a vitest suite that mocks HTTP and covers happy path plus 401 and 429 handling.
Out of scope: OAuth flows, multi-user credential storage, a web UI, a database. Say so in the README.

Deliver a README with setup steps, token scope requirements per provider, and the exact JSON block to paste into a Claude Desktop or Cursor MCP config.

$ ábrelo en tu agente (prompt listo, tú das enter) o cópialo crudo

Se puede en parte

Ahorro de referencia: US$348/año si dejas de pagar Composio.

Quiero que lo armen →

por qué la gente sigue pagando

Because integrations are boring, endless maintenance work with a long tail nobody can pre-plan. Writing one tool wrapper is trivial; writing eighty and keeping them alive through provider changes is a team. The real unlock is managed OAuth for other people's accounts: the second your agent has users, you are storing and refreshing third-party credentials, and that is a security and support problem you can rent your way out of.

qué pierdes

xHundreds of pre-built, pre-tested tool schemas you did not have to read API docs for

xManaged OAuth: app registration, consent screens, refresh tokens, revocation

xPer-end-user credential storage, which is the whole game if your agent serves anyone but you

xSomeone else fixing your integration when a provider ships a breaking API change

xUsage observability, retries and rate limit smoothing across providers

arte previo · úsalo en vez de construir, si prefieres

Nada que valga la pena señalar. Por eso existe el prompt.

compartir en X ↗"Acabo de reemplazar Composio ($29/mes) con un prompt"