Can I vibecode Composio?

KINDA · weekend project

price $29/moyou'd save $348/yrbuild time one sittingcategory 🛠️ dev toolsreplaced by 0 people

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.

the 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.

$ open in your agent (prompt prefilled, you press enter) or copy it raw · this prompt is generated from the build plan · improve it via PR

why people still pay

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.

what you lose

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

prior art · use these instead of building, if you'd rather

Nothing worth pointing at. That's why the prompt exists.

share on X ↗"I just replaced Composio ($29/mo) with one prompt"