Your REST API is Already an MCP Server

The wrapper problem

If you have a REST API and you want AI agents to use it, the standard advice right now is to build an MCP server that wraps it. In practice that means writing a tool definition for every endpoint, mapping parameters to HTTP requests, re-implementing auth you already solved once, and then keeping all of it in sync as the API changes.

That's a lot of work to re-describe something you've already described. If your API has an OpenAPI spec, the tool names, parameters, types, and descriptions all exist — they're just in a format MCP clients don't read.

So we made Gatana read it.

How it works

Paste an OpenAPI 3.x or Swagger 2.0 spec into Gatana, or point it at a URL where one is hosted. Each operation in the spec becomes an MCP tool, using the schemas and descriptions you already wrote:

# Your existing spec:
/github/pulls/{owner}/{repo}/{pull_number}:
  get:
    operationId: getPullRequest
    summary: Get details of a pull request
    parameters:
      - name: owner
        in: path
        required: true
        schema: { type: string }
      - name: repo
        in: path
        required: true
        schema: { type: string }
      - name: pull_number
        in: path
        required: true
        schema: { type: integer }

# Gatana turns this into a `getPullRequest` MCP tool with
# typed parameters and live execution against your API.

# Your existing spec:
/github/pulls/{owner}/{repo}/{pull_number}:
  get:
    operationId: getPullRequest
    summary: Get details of a pull request
    parameters:
      - name: owner
        in: path
        required: true
        schema: { type: string }
      - name: repo
        in: path
        required: true
        schema: { type: string }
      - name: pull_number
        in: path
        required: true
        schema: { type: integer }

# Gatana turns this into a `getPullRequest` MCP tool with
# typed parameters and live execution against your API.

# Your existing spec:
/github/pulls/{owner}/{repo}/{pull_number}:
  get:
    operationId: getPullRequest
    summary: Get details of a pull request
    parameters:
      - name: owner
        in: path
        required: true
        schema: { type: string }
      - name: repo
        in: path
        required: true
        schema: { type: string }
      - name: pull_number
        in: path
        required: true
        schema: { type: integer }

# Gatana turns this into a `getPullRequest` MCP tool with
# typed parameters and live execution against your API.

Agents call getPullRequest(owner, repo, pull_number) like any other MCP tool. The fact that there's a REST API behind it is an implementation detail they never see.

A few things happen under the hood that you'd otherwise have to build yourself:

• Schema extraction — path parameters, query strings, headers, and request bodies are pulled from the spec, with nested $refs resolved, so each tool has a complete self-contained schema.

• HTTP translation — Gatana handles path substitution, query assembly, headers, body serialization, and response parsing. Errors come back as readable messages rather than raw HTTP failures.

• Sync — if you point at a hosted spec URL, the tools update as your API evolves, so there's no second source of truth to maintain.

Both Swagger 2.0 and OpenAPI 3.x are supported.

Pointing it at your environments

Two settings cover most real-world setups:

• Base URL override lets you use the same spec against dev, staging, or production without editing the spec itself.

• Custom headers let you attach an Authorization header, API key, or tenant identifier to every call. These work with Gatana's Credentials system, so secrets stay managed and rotatable instead of living in your config.

There's also a test button that validates the spec before you save — it shows the API title, version, operation count, and resolved endpoints, so you can catch problems before an agent does.

Beyond a single API

Once an API is in Gatana, it plugs into everything else: bundle it with other servers into Profiles so agents get a curated toolset, control who can use it with Teams, and combine it with Code Mode to let agents orchestrate many endpoints in one sandboxed execution instead of making a round trip per call.

The point isn't just skipping some boilerplate. It's that the API your team already built — documented, secured, in production — becomes usable by agents without anyone writing or maintaining a wrapper for it.

Setting up an OpenAPI server takes a couple of minutes. The OpenAPI/Swagger documentation has the full walkthrough.

What is Gatana?

Gatana is the market-leading AI/agent connectivity platform. It is flexible, configurable, powerful and useful for anyone from an individual to a large organization. It allows each team to centralize and manage all their agentic connectivity needs, be it MCP or HTTP or any other protocol, across any number of teams, contexts and separate departments.