A product manager asks whether ChatGPT can “just call our API” the way a deploy script does. The honest answer is usually no. A REST endpoint returns JSON when something supplies the right path, headers, and body. An assistant needs a named capability, a short description of when to use it, a schema for arguments, and a permission boundary that survives a multi-turn chat. Those pieces are what Model Context Protocol (MCP) is designed to expose. Your existing API can still power the work; MCP is the contract the assistant reads first.
We wrote the companion piece on MCP for SaaS and secure assistant access from the security and tenant-isolation side: CSV paste, scopes, revocation. Here the question is narrower and more developer-shaped: what REST already gives deterministic callers, what MCP adds for ChatGPT and Claude, and why “ship MCP instead of REST” is the wrong fork. In our own product thinking we keep HTTP for automation and CI, and treat assistant-facing tools as a separate surface. Layer both. Do not rip and replace OpenAPI.
What REST APIs give scripts that assistants still lack
A conventional SaaS API is built for deterministic callers. A pipeline knows the route. A webhook knows the event. A customer script knows which query parameters to send. OpenAPI (or your internal docs) describe status codes and payloads for humans and code generators. That is enough for CI, cron, and partner integrations.
