DEV Community

CorpusIQ
CorpusIQ

Posted on • Originally published at corpusiq.io

We Built a Single MCP Endpoint for 36 Business APIs - Here's What We Learned

#mcp #ai #api #devops

The Problem: API Sprawl Is Killing Operator Productivity

Every business operator we talked to had the same complaint: they spend 40% of their time just logging into different platforms to pull numbers. Stripe for revenue. HubSpot for pipeline. Google Analytics for traffic. QuickBooks for expenses. Slack for team activity. GitHub for engineering velocity.

We counted 36 different APIs that a typical SaaS operator needs to touch weekly. That's 36 different authentication mechanisms, 36 different data formats, 36 different pagination patterns, and 36 different rate limits.

When Anthropic released the Model Context Protocol (MCP) , we saw an opportunity: what if we could collapse all 36 APIs into a single endpoint that any AI agent could query?

What We Built

CorpusIQ is a single MCP endpoint that connects to 36 business APIs. Instead of writing 36 different integration clients, your AI agent talks to one endpoint using one protocol. The agent asks "What's our MRR this month?" and CorpusIQ handles the rest — routing the query to Stripe, normalizing the response, and returning clean, structured data.

Architecture Decisions That Mattered

1. Read-Only by Design

We made the deliberate choice to be read-only. No mutations, no webhooks, no write operations. This wasn't a limitation — it was a strategic decision. Operators need answers, not another tool that can accidentally change production data. Read-only means zero risk of an agent hallucinating a DELETE on your Stripe account.

2. Device Flow OAuth

Every API we connect to requires authentication, and we didn't want to be in the business of storing credentials. We implemented the OAuth 2.0 Device Authorization Grant — the same flow used by Apple TV and streaming devices. Users authorize once through their browser, and we get scoped, revocable tokens. No passwords stored. No shared API keys.

3. Single Endpoint Architecture

Instead of exposing 36 different MCP tools (one per API), we expose a single query tool with a unified schema. The agent doesn't need to know which API to call — it just asks a business question. Our normalization layer handles the routing, query construction, and response formatting.

4. Cross-Source Queries

This is where it gets interesting. "Compare our Google Ads spend with Stripe revenue by week" requires hitting two completely different APIs with different date formats, different aggregation semantics, and different error modes. Our query planner decomposes cross-source queries into parallel sub-queries, then merges and normalizes the results.

What We Learned About API Normalization

Normalizing 36 APIs is humbling. Here's what broke us:

  • Date formats are a nightmare. ISO 8601, Unix timestamps, "Q1 2026", fiscal calendars. We built a universal date parser that handles 14 different input formats.
  • Currency normalization requires context. Stripe returns USD as cents. QuickBooks returns it as dollars with 2 decimal places. Google Ads returns micros (millionths of a dollar). Getting this wrong means orders-of-magnitude errors.
  • Pagination is inconsistent. Some APIs use cursor-based pagination. Others use offset/limit. A few use page numbers. One API we won't name returns everything in a single response unless you pass a specific header — and then it paginates.
  • Error responses tell different stories. A 429 from Stripe means "back off for 2 seconds." A 429 from HubSpot means "you've hit your daily limit." Same status code, completely different remediation.

Why MCP Was the Right Protocol

We evaluated REST, GraphQL, and gRPC before settling on MCP. Here's why MCP won:

  1. Tool semantics match operator queries. MCP's tool concept maps cleanly to "give me data from Stripe" or "show me HubSpot pipeline."
  2. Streaming by default. Operators want answers fast. MCP's streaming responses mean partial results appear as they arrive.
  3. Structured output guarantees. Unlike REST where you parse whatever the server sends, MCP tools return typed, validated responses.
  4. Transport flexibility. MCP runs over stdio or HTTP. We chose HTTP for cloud deployment, but the stdio option means operators can run CorpusIQ locally.

What's Next

  • Natural language query layer: "How did our Black Friday campaign perform?" → automatic decomposition across Google Ads, Stripe, and Shopify.
  • Scheduled reports: Daily/weekly digests from all connected sources, delivered to Slack or email.
  • Custom connector SDK: Operators can build their own connectors for internal APIs using our normalization framework.

The Bottom Line

The API sprawl problem isn't going away — it's getting worse. Every SaaS tool adds another API to the pile. MCP gives us a way to present a unified interface to AI agents, and the read-only, device-flow, single-endpoint architecture we chose has held up well across 36 very different APIs.

If you're building something similar, our biggest advice: invest in your normalization layer early. The protocol decisions matter less than you think. The data normalization decisions matter more than you think.

CorpusIQ — One MCP endpoint for 36 business APIs. Connect your tools once, ask questions in plain English, get answers from everywhere.

Top comments (0)