Blog · 2026-05-04

What is an MCP connector?

An MCP connector is a hosted MCP server an AI assistant can install with OAuth. What that means, and how to run one without owning servers.

An MCP connector is an MCP server that lives at a public HTTPS URL, so an AI assistant like Claude or ChatGPT can connect to it, log in with OAuth, and call its tools. That is the whole idea. The Model Context Protocol (MCP) defines how the assistant discovers what your server offers, tools it can call, resources it can read, prompts it can reuse. The word "connector" is what the assistant vendors call a remote MCP server their users can install.

How is a connector different from a local MCP server?

Most MCP servers today run on the developer's own machine over stdio: the assistant starts the process, talks to it, and kills it. That works for one person. It does not work when you want your teammates, your customers, or an assistant in the browser to use the same tools.

A connector flips the model. The server runs somewhere always-on, speaks streamable HTTP at an endpoint like /mcp, and anyone the owner allows can install it by pasting one URL. The assistant handles login through OAuth, so there are no shared API keys to paste around.

What does a connector need to run in production?

Four things, and they are exactly the boring parts:

  • A process that stays up. MCP sessions assume the server is there for the next call, which rules out cold-starting functions.
  • A stable HTTPS URL the assistant can reach.
  • An OAuth flow: discovery metadata, client registration, a login and consent screen.
  • Some way to control who is allowed in, and to see what happened afterwards.

The tool logic itself is usually the easy part. On DenkOps you write only that part: a small file of tool definitions, deployed with one command into an always-on slot. Setting "connector": true in denkops.json turns on the hosted OAuth flow, so the login screen, client registration, and access control exist without you writing any auth code.

{ "name": "my-tools", "slug": "my-tools", "runtime": "bun", "connector": true }

Who is this for?

Two groups keep showing up. Developers who built an internal tool and want the company's assistant to use it, without running an auth server. And product teams who want their SaaS to be installable inside Claude or ChatGPT, the way integrations used to live in an app marketplace.

If you can write a function, you can ship a connector. The rest of this blog is mini tutorials doing exactly that, start with deploying your first MCP server.

FAQ

What is the difference between MCP and a REST API?

A REST API defines endpoints for programmers. MCP describes tools, resources, and prompts in a way an AI assistant can discover and call on its own, including input schemas the assistant validates against. A connector is an MCP server made installable over HTTPS with OAuth.

Do I need to build an OAuth server to publish a connector?

Not on DenkOps. Setting connector: true in denkops.json enables a hosted OAuth flow (discovery, client registration, login, consent). You choose who may connect: public, or a list of allowed emails.

Which assistants can use an MCP connector?

Any MCP client that supports remote servers: Claude (custom connectors), Claude Code, ChatGPT, OpenAI Codex, and a growing list of agent tools. They all take the same thing, your server's HTTPS URL.

Ship it yourself: bunx denkops deploy or say "deploy on DenkOps" from your coding agent.

Start on DenkOps →

Deploy your first MCP server in one command →