/toolify

name: toolify
description: When you want to integrate an external tool, API, MCP server, or service into a project — the wizard walks you through auth, config, env vars, client wrapper code, example usage, and an optional smoke test. Scoped to Next.js and Rails projects. Interactive Q&A — starts with the tool name, asks structured questions until the integration is specified, then scaffolds files. Examples — Stripe, Kit, Sanity, Notion, Neon, Supabase, Resend, Postmark, Twilio, Anthropic, OpenAI, Vercel Blob, custom internal APIs. For MCP servers, also handles the .mcp.json wiring. Triggers on "/toolify," "integrate X," "add X to this project," "wire up X," "set up the X integration," "hook up X," "connect X," "add MCP for X." Part of the -ify trifecta (skillify / toolify / loopify). NOT for adding new SKILL.md files — that's skillify. NOT for cron/agent loops — that's loopify.
metadata:
  version: 0.1.2

/toolify — Wire up an integration or MCP server

Interactive wizard for adding an external tool / API / MCP into a project. Ends with working code + env vars set + a verification path.

Scope

• **Primary stacks**: Next.js (App Router + TypeScript) and Rails. Reason: those are the two stacks the user actually ships in; supporting every stack bloats the wizard.
• **What toolify handles**: auth pattern (API key, OAuth, JWT, session cookie), env var setup, official SDK vs raw fetch, client wrapper location, example usage, webhook handling (if applicable), MCP `.mcp.json` wiring (if MCP server).
• **What toolify does NOT handle**: writing business logic on top of the integration (that's for the human). It scaffolds the *plumbing*, not the *feature*.

Step 0 — Get the tool name

Ask if not provided: *"Which tool are we integrating?"*

Detect category from name:

| Category | Examples | Extra steps | |---|---|---| | **Payments** | Stripe, LemonSqueezy, Paddle | Webhook signature verification, customer model, event handlers | | **Auth** | NextAuth/Auth.js, Clerk, Supabase Auth, Devise | Session management, protected routes, callbacks | | **Email** | Resend, Postmark, SendGrid, Kit | From address, template setup, unsubscribe handling | | **CMS/DB** | Sanity, Prisma, Drizzle, Neon, Supabase | Schema location, migration path, client singleton pattern | | **AI/LLM** | Anthropic, OpenAI, Gemini, Vercel AI SDK | Model choice, streaming vs non-streaming, rate limits | | **Analytics** | Fathom, PostHog, Plausible | Script placement, event tracking API | | **Scheduling/Comms** | SavvyCal, Cal.com, Twilio, Riverside | Webhook events, embed patterns | | **Scraping** | ScrapeCreators, Apify, Playwright | Rate limits, response caching, retry policy | | **Affiliate/Referral** | Rewardful, PartnerStack | Cookie handling, webhook events, dashboard access | | **Storage** | Vercel Blob, S3, R2 | Bucket setup, signed URL pattern, presigned upload | | **MCP server** | Any MCP — Sanity, Stripe, GitHub, Kit, etc. | `.mcp.json` entry + env vars, no client wrapper | | **Custom / other** | Internal API, unknown tool | Ask more questions |

If category detection fails, ask 2 questions to place it: *"Is it an API you call, a webhook receiver, or both?"* / *"Does it have an official SDK?"*

Step 1 — Structural interview

Ask the following in order (skip questions that don't apply based on category):

1. **Which project?** (path — infer from cwd; ask if ambiguous) 2. **Which stack?** (Next.js / Rails — infer from `package.json` vs `Gemfile`; ask if both) 3. **Auth pattern?** (API key / OAuth / JWT / session cookie / signed webhooks — usually knowable from official docs) 4. **Official SDK exists?** (check the docs; prefer SDK when good; fall back to raw fetch when SDK is bloated/abandoned) 5. **Env var name convention?** (default: `SCREAMING_SNAKE_CASE` matching official convention — e.g., `STRIPE_SECRET_KEY`, `RESEND_API_KEY`) 6. **Environments?** (dev / preview / prod — different keys?) 7. **Webhook receiver needed?** (YES for Stripe/Rewardful/most payment+auth+CMS; NO for pure client-side or read-only APIs) 8. **Rate limits to respect?** (grep official docs) 9. **Where does the client wrapper live?** (default: `src/lib/<tool>.ts` for Next.js; `app/services/<tool>_client.rb` for Rails)

Show the user the answers as a summary before scaffolding — one chance to correct before writing files.

Step 2 — Fetch official setup docs

Pull the *current* official quickstart. Prefer context7 if your agent has it (fresher docs than training data); otherwise fetch the official quickstart URL with your agent's URL-fetch tool (`WebFetch` in Claude Code) or `curl`.

Read *once*, then work from cached content. Don't re-fetch mid-scaffold. Note the SDK version cited so `package.json` gets the right pin.

Step 3 — Scaffold files

For a **standard Next.js integration**, generate:

src/lib/<tool>.ts                    # client singleton + typed wrappers
src/app/api/webhooks/<tool>/route.ts # webhook handler (if applicable)
src/app/api/<tool>/example/route.ts  # one working example route
.env.local.example                    # env var template with placeholder values

For **Rails**:

config/initializers/<tool>.rb        # SDK config
app/services/<tool>_client.rb        # client wrapper
app/controllers/webhooks/<tool>_controller.rb  # webhook handler if applicable
config/routes.rb                      # webhook route
.env.example                          # env vars

For an **MCP server**, only:

.mcp.json                             # add or update with the new server entry
.env.local                            # add the env vars the MCP needs

Every scaffolded file should have a comment at the top like:

// Scaffolded by /toolify on 2026-06-30. Official docs: <url>. SDK version: <version>.
// The client wrapper is scoped to plumbing only — business logic lives elsewhere.

Step 4 — Auth pattern implementation

Apply the right auth pattern per tool category. Never invent — use