Gemini does not have a one-click "connector" product for an arbitrary OpenAPI API, as of September 2026. There are two real paths instead: turn your spec's operations into function declarations the Gemini API can call directly, or generate an MCP server and add it to Gemini CLI's settings.json. Which one you want depends on whether you're building an app (function calling) or working in an agentic dev tool (MCP). This post covers both, verified against Google's own docs.
Does Gemini have a "connector" like Claude or ChatGPT?
No — not for a generic third-party OpenAPI API. If you've seen Vertex AI Extensions mentioned as a way to register an OpenAPI spec directly with a Gemini model, skip it: Google has deprecated Vertex AI Extensions and is shutting it down after November 26, 2026, pointing existing users to Vertex AI's Agent Builder / Agent Platform tooling instead. Don't build new integrations on a product that's mid-sunset.
What Gemini does have, verified from ai.google.dev and Google Cloud's Vertex AI docs, is function calling: you describe your API's operations as JSON function declarations, the model decides when to call one and with what arguments, and your code executes the actual HTTP request. That's the durable mechanism. Everything else — the tooling that helps you generate the declarations, or MCP support in specific Gemini surfaces — sits on top of it.
Path 1: function declarations from your OpenAPI spec
Gemini's function declarations use a subset of the OpenAPI Schema Object, not a full OpenAPI document upload. Per Google's docs, the supported schema attributes are type, nullable, required, format, description, properties, items, enum, anyOf, $ref, and $defs — other JSON Schema/OpenAPI keywords are not read. There's no "upload your spec" button in the Gemini API; you (or a generator) translate operations into this shape.
A generated declaration for one OpenAPI operation looks like this:
{
"name": "send_message",
"description": "Send an SMS message to a phone number.",
"parameters": {
"type": "object",
"properties": {
"number": { "type": "string", "description": "E.164 phone number." },
"content": { "type": "string", "description": "Message body." }
},
"required": ["number", "content"]
}
}
The model doesn't execute anything — per Google's docs, "the model doesn't execute the function itself." It returns a functionCall with a name and arguments; your application matches that to the real OpenAPI operation, makes the HTTP request with your stored credentials, and sends the result back to the model as a functionResponse. Auth, rate limits, and error handling stay entirely on your side, same as any REST integration — Gemini just decides when to call.
This is mechanical work if you already have a clean OpenAPI spec: operationId becomes the function name, summary/description becomes the function description, and the request schema becomes parameters (narrowed to the supported subset above — nullable: true instead of a type array, no oneOf/allOf, no unsupported formats). It's the same translation an MCP server generator does; Gemini's version is just a narrower target schema.
Path 2: MCP in Gemini CLI
If you're working in Google's agentic CLI rather than calling the Gemini API from your own backend, Gemini CLI supports MCP servers directly. Per the Gemini CLI docs and its GitHub repo, you add servers to ~/.gemini/settings.json:
{
"mcpServers": {
"your-api": {
"command": "node",
"args": ["/absolute/path/to/dist/index.js"],
"env": {
"YOUR_API_API_KEY": "$YOUR_API_API_KEY"
}
}
}
}
Gemini CLI connects to every configured server at startup and makes their tools available in the session, the same shape as Claude Code's or Cursor's MCP config. This is the path to use if you already have (or generate) an MCP server from your OpenAPI spec and want it available inside Gemini CLI specifically — you're not hand-writing Gemini-flavored function declarations at all, you're pointing Gemini CLI at a standard MCP server.
Function calling vs MCP vs Vertex AI Extensions
| Gemini API function calling | MCP in Gemini CLI | Vertex AI Extensions | |
|---|---|---|---|
| Where it works | Any app calling the Gemini API or Vertex AI | Gemini CLI sessions | Vertex AI (deprecated) |
| What you generate | Function declarations (OpenAPI schema subset) | A standard MCP server | An OpenAPI-based extension registration |
| Status, Sept 2026 | Current, documented | Current, documented | Shutting down after Nov 26, 2026 |
| Best for | Production apps with a tight, reviewed tool surface | Local agentic dev work in Gemini CLI | Nothing new — don't start here |
Honest scope: when to skip both
If you only need Gemini to call one or two endpoints and you control the calling code, hand-writing two or three function declarations is faster than generating and hosting an MCP server — MCP's win is reuse across multiple agent hosts (Claude, Cursor, Copilot, Gemini CLI) from one server, not a better calling convention for a single integration. And if your "integration" is really "fetch this one public JSON endpoint," Gemini's built-in Google Search grounding or a plain server-side fetch in your own code beats standing up a tool definition at all.
Where Sourced fits
Sourced generates a TypeScript MCP server, host connector files, an agent readiness report, and default-enabled tool lists from one OpenAPI spec with the OpenAPI-to-MCP generator and managed host. You can point Gemini CLI's settings.json at the managed remote endpoint, or download the server and run it yourself. The same endpoint can serve Claude Code, Cursor, ChatGPT, or Grok without regeneration. Sourced's output here is the MCP server and OpenAPI-shaped types, not Gemini's narrower function-declaration JSON directly — if you're calling the Gemini API from your own backend rather than working in Gemini CLI, use the MCP server's schemas as your source of truth and narrow them to Gemini's supported subset by hand, or start a free docs and SDK preview and use the generated OpenAPI-shaped types as the basis for your declarations.
FAQ
Does Gemini support OpenAPI directly?
Not as a file upload. Gemini's function calling reads a subset of the OpenAPI Schema Object (type, nullable, required, format, description, properties, items, enum, anyOf, $ref, $defs) inside individual function declarations, not a full spec. You or a generator translate operations into that shape.
Is there a Gemini "connector" product like Claude or ChatGPT connectors?
No, not for arbitrary third-party OpenAPI APIs as of September 2026. Vertex AI Extensions came closest but is deprecated and shutting down after November 26, 2026. Function calling and MCP (in Gemini CLI) are the supported paths.
Does Gemini support MCP?
Gemini CLI does, via mcpServers entries in ~/.gemini/settings.json. The core Gemini API's function-calling interface is a separate mechanism and does not itself speak MCP — you'd bridge an MCP server to function-call format if you needed both in one app.
What happens if I pass MCP-shaped JSON Schema straight to Gemini function calling?
It often breaks. MCP tool schemas can use JSON Schema features Gemini's subset rejects, such as type arrays for nullability (["string", "null"]). Use anyOf with a null branch, or nullable: true, instead.
Should I use Vertex AI Extensions to connect my API?
No. It's deprecated and scheduled to shut down after November 26, 2026. Use function calling for direct Gemini API integration, or Google's current Agent Builder / Agent Platform tooling if you need a managed agent product.
Can I reuse the same MCP server across Gemini CLI, Claude Code, and Cursor?
Yes — that's the point of MCP. A server generated once from your OpenAPI spec is the same process definition whether Gemini CLI, Claude Code, or Cursor is the client asking it for tools.
If you want the MCP path, generate the server from your OpenAPI spec and add it to whichever host you're working in. If you want typed SDKs and hosted docs from the same spec, create hosted docs from your repo or start free.