MCP server development: connecting your app to Claude and ChatGPT

What an MCP server is, and is not

An MCP server describes what your product can do (its tools), what it can show (resources) and ready-made prompts, in a form any MCP client understands. Claude accepts remote MCP servers as custom connectors on its Free, Pro, Max, Team and Enterprise plans; ChatGPT's developer mode gives full MCP support on its Pro, Plus, Business, Enterprise and Education plans. It is not a chatbot inside your app: it lets the assistant your customers already use work with your product.

Decide what to expose

Start from the jobs your users want done, not from your API reference. A handful of clear tools beats a mirror of every endpoint. Give each tool a plain description written for the model, typed inputs and outputs, and examples. Ship read-only tools first; add tools that change data once the read-only ones behave. Return tools in a stable order: the 2026 revision of the protocol asks servers to do this so clients can cache them.

Local or remote

A local server runs on the user's computer (for example as a desktop extension) and suits access to local files and tools. A remote server runs on your infrastructure, speaks the protocol's Streamable HTTP transport, and suits a SaaS product: users connect by URL, and you control updates. The older HTTP-with-SSE transport is deprecated; build on Streamable HTTP.

Sign-in and permissions

Every user should sign in through OAuth with their own account, so the assistant can see and do exactly what that user could, and nothing more. Never ship a shared admin token. The 2026 revision prefers Client ID Metadata Documents for client registration and deprecates Dynamic Client Registration, which remains available for compatibility; Claude can use its published client identity, and ChatGPT supports both methods. Ask for the narrowest scopes that do the job.

The 2026 protocol revision

The revision dated 2026-07-28 is a large change. The protocol becomes stateless: the start-up handshake and protocol-level sessions are removed, every request carries its protocol version and the client's capabilities, and servers must answer a new server/discover request. A multi-round-trip pattern replaces requests that servers used to send to clients, and the Roots, Sampling and Logging features are deprecated. Build new servers on the current revision with an official SDK, and plan updates when the specification changes.

Safety: prompt injection and write actions

Anything your tools return can carry instructions aimed at the model, so treat tool output as untrusted. Mark read-only tools as read-only: ChatGPT treats every tool as a write action, needing the user's confirmation, unless it is annotated otherwise. Require confirmation for anything that changes or deletes data, rate-limit every tool, and log who did what. The OWASP Top 10 for LLM applications (2025) names the main risks, starting with prompt injection and excessive agency.

Test it like a feature

Write a set of real questions your users would ask, with the tool calls and answers you expect. Run it against Claude and ChatGPT before release and after every change, and check that the assistant picks the right tool, passes the right inputs and handles errors. Track latency and cost per question as you go. Our open-source MCP server, eol-check-mcp, ships with a 24-case evaluation set of this kind (github.com/mervenor/eol-check-mcp).

Publishing and listing

The official MCP Registry, still in preview, lists servers using a server.json file and the mcp-publisher command-line tool; publishers prove ownership of their namespace through GitHub or their own domain. The registry stores metadata only, so a server that runs locally is first published as a package (on npm or PyPI, for example) and the registry entry points to it. Claude has its own Connectors Directory, and ChatGPT has its own app listings. Publishing in the registry is a good way for developers to find a server; it is not a security review.

What drives the cost

• The number of tools and how much business logic each one needs.
• Sign-in: reusing an existing OAuth server is quicker than building one.
• Data boundaries: multi-tenant permissions and audit logging take careful work.
• Hosting and scale: how many users, how often, and how fast the answers must come.
• The evaluation set and the regression runs that keep it honest.
• Directory requirements, if you want to be listed.

Questions people ask

1. 01

   We already have an API. Do we need an MCP server?

   An MCP server usually sits on top of your API. It adds the descriptions, sign-in flow and safety rules an assistant needs, and lets every MCP client use your product without a custom integration each.

2. 02

   Will one server work with both Claude and ChatGPT?

   Yes, if it follows the specification; check sign-in on both, because clients register differently.

3. 03

   Is it safe to let an AI assistant change our data?

   With per-user sign-in, read-only annotations, confirmations for writes, rate limits and logs, it can be. Start read-only and widen access as the evaluation results allow.