Forem: Levi

I converted 10 popular APIs to MCP tools. 7 would let an agent delete your data with zero guardrails.

Levi — Sat, 11 Apr 2026 14:16:53 +0000

Stripe. GitHub. Twilio. Slack. Notion. Shopify. Discord. SendGrid. Linear. PagerDuty.

None of them ship MCP tool definitions. Every agent developer connecting to these APIs is hand-wiring tools, writing custom auth, and — most dangerously — giving agents full CRUD access with zero risk classification.

These are the APIs that run production systems. If you're connecting them to AI agents without knowing which endpoints are destructive, you're one hallucination away from a very bad day.

The problem is worse than "no MCP support"

I took the public OpenAPI specs for 10 of the most commonly used APIs and converted them to MCP tool definitions. Then I counted how many destructive operations each one exposes — endpoints that delete data, cancel subscriptions, revoke access, or mutate state irreversibly.

Here's what I found:

API	Total Endpoints	Safe (GET)	Moderate (POST/PATCH)	Destructive (DELETE)	Official MCP server?
Stripe	314	104	163	47	No
GitHub	347	189	111	47	Community only
Twilio	215	72	108	35	No
Slack	168	43	112	13	No
Notion	47	18	22	7	Community only
Shopify Admin	280+	95	130	55+	No
Discord	190+	65	89	36	No
SendGrid	120+	40	55	25	No
Linear	50+ (GraphQL)	15	28	7	Community only
PagerDuty	180+	78	72	30	No

That's 300+ destructive endpoints across 10 APIs.

When you convert an API spec to MCP tools and hand them all to an agent, those destructive endpoints are mixed in with everything else. The agent doesn't know that delete_customer is fundamentally different from get_customer. They're both just tools.

What actually goes wrong

Stripe: 47 DELETE endpoints include delete_customer, void_invoice, cancel_subscription, and refund_charge. An agent trying to "clean up test data" could cancel live subscriptions.

GitHub: delete_repository, remove_collaborator, transfer_repository, delete_org. An agent asked to "reorganize the GitHub org" has the tools to do irreversible damage.

Shopify: The admin API lets you delete products, cancel orders, and remove customer data. An agent doing "inventory management" has access to endpoints that can wipe your catalog.

Twilio: delete_message, release_phone_number, delete_recording. An agent optimizing your Twilio usage could release production phone numbers.

The pattern is always the same: the API spec doesn't distinguish between "safe to call freely" and "requires human approval." That distinction only exists if you add it.

What I'm doing about it

I built ruah conv to automate this entire pipeline — and to add the safety layer that API specs don't have.

npm i -g @ruah-dev/cli

Point it at any API spec, get MCP tools with automatic risk classification:

ruah conv generate stripe-openapi.yaml --target mcp-ts-server

→ 314 tools generated from stripe-openapi.yaml
→ Risk breakdown: 104 safe, 163 moderate, 47 destructive
→ Destructive: delete_customer, cancel_subscription, 
   refund_charge, void_invoice... (+43 more)

Every tool gets tagged safe, moderate, or destructive based on:

HTTP method (GET = safe, DELETE = destructive)
Endpoint patterns (/cancel, /revoke, /destroy, /remove)
Mutation semantics (state changes that can't be undone)

Then you filter before loading:

# Only generate safe + moderate tools. No destructive.
ruah conv generate stripe-openapi.yaml \
  --target mcp-ts-server \
  --max-risk moderate

Now your agent has 267 tools instead of 314, and none of them can delete anything.

The context window problem (bonus finding)

Here's the other thing nobody warned me about:

Each MCP tool definition is 200–500 tokens. Stripe's 314 endpoints = 60,000–150,000 tokens just for tool metadata.

Perplexity's CTO flagged this at Ask 2026 — MCP tool descriptions eat 40–50% of available context windows before agents do any actual work.

The fix is the same: filter before you load.

# Only payment-related tools, nothing destructive
ruah conv generate stripe-openapi.yaml \
  --target mcp-ts-server \
  --include-tags payments,charges \
  --max-risk moderate

25 tools instead of 314. Your agent is safer AND faster.

Input formats → Output targets

ruah conv doesn't just handle OpenAPI. These are all the specs I tested with:

Inputs:

OpenAPI 3.x / Swagger 2.0
Postman Collection v2.1
GraphQL SDL (Linear, Shopify Storefront)
HAR files (recorded browser traffic)

Outputs:

Target	What you get
`mcp-ts-server`	Full TypeScript MCP server scaffold
`mcp-py-server`	Full Python MCP server scaffold
`mcp-tools`	Just the tool definitions (JSON)
`openai`	OpenAI function-calling schema
`anthropic`	Anthropic tool schema
`a2a`	Agent-to-Agent service wrapper

Auth normalization, pagination wrappers, retry logic, and dry-run mode included in every output.

Try it

npm i -g @ruah-dev/cli
ruah conv generate your-spec.yaml --target mcp-ts-server

Node.js 18+. One dependency. MIT licensed.

GitHub: github.com/ruah-dev
Docs: ruah.sh

The converter is part of a larger toolchain (orchestrator for parallel agents, optimizer for cost tracking), but it works completely standalone. No lock-in, no account, no cloud dependency.

I got tired of hand-wiring agent tools, so I built an OpenAPI MCP converter

Levi — Sat, 11 Apr 2026 10:30:08 +0000

You know that moment where you find the perfect API for your agent, and then you spend the next 45 minutes manually writing tool definitions for it?

Mapping every parameter. Copying descriptions from the docs. Realizing you forgot the request body schema. Debugging why the agent keeps hallucinating a parameter that doesn't exist.

I kept doing this. Over and over. For every API. And at some point I thought — the machine-readable spec is right there. Why am I doing this by hand?

So I built Ruah Convert.

What it does

Feed it an OpenAPI spec. Get MCP tool definitions out.

npx @ruah-dev/conv generate petstore.yaml --json

That's it. One command. You get a JSON array of MCP-compatible tools with names, descriptions, and input schemas — ready to drop into any agent framework.

But first, let me inspect

Before generating anything, you probably want to know what's in the spec. The inspect command gives you a quick summary:

npx @ruah-dev/conv inspect petstore.yaml

API Spec Summary
──────────────────────────────────────────────────
  Title:    Petstore API
  Version:  1.0.0
  Format:   openapi-3.0
  Base URL: https://api.petstore.example.com/v1

Auth Schemes (1)
  • apiKeyAuth: apiKey (X-API-Key)

Tools (4)
  • listPets    GET    /pets           (2 params)
  • createPet   POST   /pets           (0 params +body)  [moderate]
  • getPet      GET    /pets/{petId}   (1 params)
  • deletePet   DELETE /pets/{petId}   (1 params)         [destructive]

Types (3)
  Pet, NewPet, Error

Every endpoint becomes a tool. Every parameter maps into the input schema. And notice the [moderate] and [destructive] tags — more on that in a second.

Risk classification

This is my favorite part. Every generated tool gets a risk level based on its HTTP method:

Method	Risk	Why
GET, HEAD, OPTIONS	`safe`	Read-only, no side effects
POST	`moderate`	Creates resources
PUT, PATCH	`moderate`	Modifies resources
DELETE	`destructive`	Removes resources

Your agent knows which tools are dangerous before it calls them. If you're building guardrails or approval workflows, this gives you the classification for free.

Validation catches problems early

npx @ruah-dev/conv validate petstore.yaml

This checks your spec for things that will trip up LLMs:

Missing descriptions — LLMs need these to understand what a tool does
Unresolved $ref — broken references mean broken schemas
Duplicate tool names — two operations with the same name = confusion
No operations — a spec with no paths has nothing to convert

Warnings are advisory. The tool still generates output, but you know what to fix.

How it works under the hood

Most converters are one-to-one: OpenAPI in, one specific format out. That works until you need to support Postman collections, or GraphQL, or output in OpenAI's function calling format instead of MCP.

Ruah Convert uses an intermediate representation called the Ruah Tool Schema:

 Input Parsers              IR                Output Generators
 ─────────────        ──────────────        ─────────────────────
 OpenAPI 3.x  ──┐                        ┌── MCP Tool Definitions ✓
 Swagger 2.0  ──┤                        ├── MCP Server (TS)
 Postman v2.1 ──┼──→  Ruah Tool Schema ──┼── Function Calling (OpenAI)
 GraphQL SDL  ──┤     (canonical IR)     ├── Function Calling (Anthropic)
 HAR files    ──┘                        └── A2A service wrapper

Every input parser normalizes to the IR. Every output generator reads from it. Adding a new input format means writing one parser. Adding a new output format means writing one generator. Never N×M.

The IR is fully inspectable — ruah conv inspect ./spec.yaml --json dumps the whole thing as JSON, so you can pipe it into whatever you want.

Programmatic API

Not just a CLI. You can use it in your own code:

import { parse, validateIR, generate } from "@ruah-dev/conv";

const ir = parse("./petstore.yaml");
const warnings = validateIR(ir);
const result = generate("mcp-tool-defs", ir);

console.log(result.files[0].content);

What ships today (v0.1)

OpenAPI 3.0 / 3.1 parser (YAML and JSON)
Ruah Tool Schema intermediate representation
MCP tool definitions output (JSON)
Risk classification per tool
IR validation with warnings
CLI: generate, inspect, validate, targets
Programmatic API

What's next

v0.2: Full MCP TypeScript server scaffold, Swagger 2.0 auto-upgrade, Postman collection parser
v0.3: MCP Python server (FastMCP), OpenAI + Anthropic function calling schemas, GraphQL SDL parser

Try it

# Run without installing
npx @ruah-dev/conv inspect your-api-spec.yaml

# Or install globally
npm install -g @ruah-dev/conv

One runtime dependency (yaml). Node 18+. MIT licensed.

GitHub: github.com/ruah-dev/ruah-conv
npm: @ruah-dev/conv

This is the first tool in the Ruah ecosystem — an open-source toolchain for building, running, and managing agentic AI systems. Orchestration, planning, safety, observability — all composable, all standalone.

If you're building with agents, I'd love to hear what you think. What APIs are you wiring up? What output formats do you need? Drop a comment or open an issue.

I Let 5 AI Agents Loose on One Repo. It Was a Disaster. So I Built This.

Levi — Fri, 10 Apr 2026 19:46:48 +0000

Last month I tried something ambitious: split a feature across five AI coding agents running in parallel. Claude Code on auth. Aider on the API. Codex on tests. Two more on frontend components.

Within 90 seconds, three of them had edited src/index.ts. Two had conflicting changes to the same utility function. One had deleted a file another was importing.

The merge was unfixable. I lost an hour untangling it, then threw everything away and did it sequentially. One agent at a time. Like it's 2024.

That experience broke something in my brain. AI agents are fast enough to work in parallel — but our tooling assumes they work alone. So I built the missing piece.

The Problem Nobody Talks About

Every AI coding tool — Claude Code, Cursor, Aider, Codex, Windsurf — operates with a mental model of "one agent, one repo." And that's fine for solo tasks.

But the moment you want parallelism — the thing that should make AI 5x faster — you hit the wall:

No workspace isolation. Agents share a checkout. One agent's git stash nukes another's work.
No file ownership. Two agents rewrite the same module with zero awareness of each other.
No merge strategy. You're the merge strategy. At 2am. With conflicting diffs you didn't write.
No dependency ordering. The frontend agent starts before the API it depends on exists.

Git branches help with history isolation. But branches don't prevent two agents from touching the same files. They just defer the pain to merge time.

Ruah Orch: Parallel Agents That Don't Collide

Ruah Orch is an open-source orchestration engine that coordinates multiple AI agents working on the same repository. Each task gets:

1. An isolated workspace (Git worktree — a real checkout, not a branch)

ruah task create auth --files "src/auth/**" --executor claude-code
ruah task create api  --files "src/api/**"  --executor aider
ruah task create ui   --files "src/ui/**"   --executor claude-code

2. File locks checked before agents start

ruah task create utils --files "src/utils/**"
# ERROR: Lock conflict with task 'auth' on src/utils/helpers.ts

No more discovering conflicts after an agent has been running for 10 minutes. Ruah rejects overlapping file claims at creation time.

3. Smart parallel execution with dependency ordering

# workflow.md

backend:
  files: src/api/**
  executor: claude-code
  prompt: "Build REST endpoints for user management"

frontend:
  files: src/ui/**
  executor: claude-code
  parallel: true
  prompt: "Build user profile components"

integration-tests:
  files: tests/**
  depends: [backend, frontend]
  executor: aider
  prompt: "Write integration tests for the user flow"

ruah workflow run workflow.md

Ruah builds a DAG, validates there are no cycles, checks for file conflicts, then runs backend and frontend in parallel. integration-tests waits until both are done.

4. Contract enforcement before merge

Tasks can declare modification contracts:

owned — only this task touches these files
shared-append — append only, no deletions
read-only — hands off

Violations are caught before merge, not after.

It Works With Everything

Ruah isn't tied to one AI tool. It ships with executor adapters for:

Executor	Tool
`claude-code`	Claude Code CLI
`aider`	Aider
`codex`	OpenAI Codex CLI
`script`	Any shell command

Mix and match. Use Claude Code for complex architecture and Aider for quick edits. Ruah doesn't care — it manages workspaces, not agents.

ruah task create backend --executor claude-code --prompt "Design the auth system"
ruah task create docs    --executor aider        --prompt "Write API documentation"
ruah task create tests   --executor codex        --prompt "Add unit test coverage"

The 5-Minute Version

# Install
npm install -g @ruah-dev/orch

# Initialize in your repo
cd your-project
ruah init

# Create parallel tasks with file isolation
ruah task create auth    --files "src/auth/**"    --executor claude-code
ruah task create payments --files "src/payments/**" --executor claude-code

# Start them (each gets its own worktree)
ruah task start auth
ruah task start payments

# When done, merge cleanly
ruah task done auth
ruah task merge auth

ruah task done payments
ruah task merge payments

That's it. Two agents, working in parallel, zero collisions, clean merges.

What Happens Under the Hood

When you run ruah task start auth:

Worktree created — A real Git worktree at .ruah/worktrees/auth/, branched from your current HEAD
Locks acquired — src/auth/** is claimed. No other task can touch these files
Environment injected — The agent receives RUAH_TASK, RUAH_WORKTREE, RUAH_FILES, RUAH_ROOT
Executor launched — Claude Code (or Aider, or your script) starts in the isolated worktree
Artifacts captured — Changed files, patches, and commit metadata are persisted to .ruah/state.json

When you ruah task merge auth:

Contracts validated — Did the agent stay within its file boundaries?
Governance gates run — If you have quality gates (linting, tests, type checking), they run automatically
Clean merge — Changes merge into your base branch. No surprises.

Subtasks: Agents Spawning Agents

Here's where it gets interesting. A parent task can spawn child tasks:

ruah task create auth-api --parent auth --files "src/auth/api/**"
ruah task create auth-ui  --parent auth --files "src/auth/ui/**"

Children branch from the parent (not main), inherit its context, and merge back into the parent. The parent then merges into main. It's turtles all the way down — but organized turtles.

Zero Dependencies. Zero Network. Zero Risk.

Ruah has zero runtime dependencies. The node_modules after install? Just dev tools. The binary is pure TypeScript compiled to ESM.

No network calls (unless you explicitly opt into update checks)
No secrets stored
No shell injection risk (array-form process spawning)
MIT licensed

Your code never leaves your machine. Ruah just manages workspaces and state.

Built-in Safety Net

# Health check everything
ruah doctor

# See what's running
ruah status

# Clean up stale tasks and orphaned worktrees
ruah clean

# Preview a workflow without executing
ruah workflow run plan.md --dry-run

When Should You Use This?

Use Ruah when:

You're splitting features across multiple AI agents
You want parallelism without merge hell
You use more than one AI coding tool
Your team has AI agents running on shared repos
You're building agentic workflows that decompose tasks

Don't use Ruah when:

You're running a single agent on a single task (just use the agent directly)
Your changes are all in one file (no isolation needed)

What's Next

Ruah Orch is Phase 1. The orchestration layer. Coming next:

Ruah Architect — Feed it a PRD or GitHub issue, get a parallelized workflow back
Ruah Guard — Policy engine for what agents can and can't do
Ruah Observe — Tracing and observability for multi-agent runs
Ruah Studio — Visual UI for watching agents work in real-time

But Orch is shipping now, it's stable, and it solves the #1 pain point: agents that don't step on each other.

npm install -g @ruah-dev/orch

GitHub | npm

If you've felt the pain of merging parallel AI agent work, give it a try. Stars welcome. Issues more welcome. PRs most welcome.

Have you tried running multiple AI agents in parallel? What was your experience? Drop a comment — I'd love to hear your war stories.