How I Turned 1,079 GitHub API Endpoints into 25 AI-Ready Tools

Source: Dev.to

The Problem

MCP is blowing up. Claude Desktop, Cursor, and a growing list of AI tools support it. But if you want to connect one of these tools to a REST API, you have two options:

Option 1: Write an MCP server by hand.
Define every tool, write HTTP handlers, wire up auth, handle errors, write a README. Hours of boilerplate per API.

Option 2: Auto‑generate from the OpenAPI spec.
Tools like FastMCP and Stainless can do this, but the output is a 1:1 mapping of endpoints to tools. A big API like GitHub has over 1,000 endpoints. Dumping that many tools on an LLM fills the context window, confuses tool selection, and yields poor results.

Even FastMCP’s own documentation says auto‑generated servers are better for prototyping than production use with LLMs.

The Fix: AI‑Powered Tool Curation

MCPForge adds an intelligence layer between parsing and generation. After reading the OpenAPI spec, it sends the parsed endpoints to Claude and asks it to curate them like a senior API designer would.

The optimizer:

• Picks the 25 most useful endpoints for typical use cases
• Rewrites descriptions to be concise and action‑oriented
• Drops noise such as health checks, admin routes, and deprecated endpoints
• Groups related operations when it makes sense

Results

Strict mode (the default) targets 25 or fewer tools. If you need broader coverage, there’s a standard mode that caps at 80, or you can set a custom limit with --max-tools.

How It Works

The whole flow is one command:

npx mcpforge init --optimize https://api.example.com/openapi.json

It parses the spec, runs the optimizer, and generates a complete TypeScript MCP server project with:

• Auth handling
• Error handling
• A README that includes copy‑paste config for Claude Desktop and Cursor

No OpenAPI Spec? No Problem.

Many APIs don’t publish an OpenAPI spec. MCPForge’s --from-url mode scrapes API documentation pages and uses Claude to infer the endpoint structure:

npx mcpforge init --from-url https://docs.some-api.com/reference

It isn’t as accurate as working from a spec, but it gets you about 80 % of the way there without manual effort.

Detecting Breaking Changes

What happens when the upstream API changes its spec after you’ve generated a server? MCPForge provides a diff command that compares the current spec against the one used during generation and flags changes with risk scoring:

• High risk – removed endpoints, parameter type changes, new required fields
• Medium risk – response schema changes, deprecations
• Low risk – new endpoints added, description updates

mcpforge diff

What I Learned Building This

• Feedback‑driven development works. Posting on Reddit yielded concrete feedback within hours. “100 tools is still too many” led to strict mode; “What happens when specs change?” inspired the diff command. Building in public with fast iteration beats planning in isolation.
• The moat isn’t the code, it’s the curation. Code generation is straightforward; the hard part is making the AI optimizer produce genuinely useful tool sets. Most iteration went into prompt engineering.
• LLMs have strong opinions about tool count. Testing shows 20‑30 tools is the sweet spot for most MCP clients. Below 15 you miss useful functionality; above 50 tool selection degrades noticeably.

Try It

# From an OpenAPI spec
npx mcpforge init --optimize https://petstore3.swagger.io/api/v3/openapi.json

# From a docs page
npx mcpforge init --from-url https://jsonplaceholder.typicode.com/

# Inspect a spec before generating
npx mcpforge inspect https://api.example.com/openapi.json

MCPForge is open source and MIT‑licensed:

If you try it on an API and something breaks, open an issue. The project is only a few days old and there are definitely rough edges, especially on large or unusual specs.