Product 5 min read

MCP-native from day one

Seth March 15, 2026

Most APIs treat AI integration as a distribution channel. Build the REST API, ship the SDK, then — when someone asks — add an MCP wrapper. The result is an impedance mismatch: tool names that don’t match endpoint names, schemas that have to be translated, responses that need to be reformatted before they’re useful to a model.

We built Microwave the other way around.

What MCP is

Model Context Protocol is an open standard for exposing tools to AI models. An MCP server declares a set of tools — each with a name, a description, and an input schema — and a model can call those tools during inference. It’s how Claude, GPT-4, and other models can make API calls without custom integration code for each provider.

The protocol is simple, but the implementation details matter a lot. A tool that’s difficult to call correctly, or whose output requires post-processing to be useful, creates friction for the model and for the developer debugging why the model got it wrong.

The MCP-first design

Microwave endpoint names are MCP tool names. There is no translation layer.

address_parse, financial_fx_convert, time_convert, geo_distance — these are both the REST endpoint identifiers and the MCP tool identifiers. The input schema in the documentation is the schema the model receives. The response shape the model gets is the same shape you’d get making the call over HTTP.

When we designed each endpoint, we asked two questions simultaneously: “What does a developer want to call this?” and “What would a model call this to solve a problem?” Those questions have the same answer.

What this means in practice

Here’s what it looks like when Claude uses Microwave to answer a question about time zones:

Tool call: time_convert
Input: {
  "datetime": "2026-03-15T09:00:00",
  "from": "America/New_York",
  "to": "Asia/Tokyo"
}

Result: {
  "data": {
    "datetime": "2026-03-15T22:00:00+09:00",
    "offset": "+09:00",
    "abbreviation": "JST"
  },
  "meta": { "latency_ms": 4, "tokens_consumed": 1 }
}

The model doesn’t need to know anything about Microwave’s architecture. It doesn’t need a custom prompt explaining what the output means. The response is self-describing: the field names, the ISO 8601 format, the offset — these are all things a model has been trained on. It just works.

The `tool` field

Every Microwave response includes a tool field in the meta block when called via MCP:

"meta": {
  "tool": "time_convert",
  "request_id": "req_01jq4...",
  "latency_ms": 4,
  "tokens_consumed": 1
}

This lets you log, trace, and audit tool calls even after the fact. In agentic workflows where multiple tool calls chain together, knowing which tool produced which result is essential for debugging.

The broader bet

We believe the future of API integration for AI applications is tool-native, not REST-native. REST will stick around — developers still write code — but increasingly, the caller is a model, not a human writing fetch(). Designing APIs that work well for models from the start is better than retrofitting them.

The conventions that make APIs good for developers — predictable naming, consistent schemas, self-describing responses — turn out to be the same conventions that make them good for models. This isn’t a coincidence. It’s what good API design looks like, regardless of who’s calling.