# MCP vs API: when an AI agent needs which

> MCP and REST APIs solve different problems: who decides what to call, how it is described, how it signs in. A side-by-side with one service offering both.

Published 2026-11-06 · https://shareglint.com/en/guides/mcp-vs-api

**MCP and an API are not competitors; they answer different questions.** An API is a contract between your code and a service: a developer reads the documentation, writes the calls and decides when they run. The Model Context Protocol is a contract between an AI application and a service: the service describes a few tools, and a **model** decides at run time which one to call and with what arguments. Most useful MCP servers sit in front of an API — ours is a thin layer over the same `/v1` endpoints your code would call — so the real question is who is making the call: your program, or an AI acting for a person.

## Side by side

Using one service that offers both — Shareglint's image API and its MCP server — as the example:

| | REST API | MCP server |
|---|---|---|
| Who calls | your code | an AI host (Claude, ChatGPT, Cursor, Codex…) |
| Who decides what to call | the developer, in advance | the model, from tool descriptions, at run time |
| How it is described | docs and an OpenAPI file, for humans and code generators | tool names, descriptions and JSON schemas, for models |
| Shape | resources and endpoints (`POST /v1/images`, `GET /v1/batches/{id}`) | a few task-shaped tools (`render_image`, `get_image`, `list_templates`, `get_template`, `create_signed_url`, `get_usage`, `generate_template`, `take_screenshot`, `auto_og_url`, `create_batch`, `get_batch`) |
| Sign-in | an API key in a header | OAuth for chat apps; an API key for coding tools |
| Typical use | apps, batch jobs, webhooks, CI | "make an OG image for this post", "screenshot these five pages" |
| Cost per call | the call | the call, plus the model's time and tokens |

## What MCP adds on top of an API

**Discovery at run time.** A host asks the server for its tools when it connects. Each tool comes with a description and an input schema, which the model reads to decide when a tool fits. MCP's specification calls tools "functions for the AI model to execute" ([MCP specification](https://modelcontextprotocol.io/specification/latest)) and lists them as "model-controlled", where prompts are user-controlled ([server features](https://modelcontextprotocol.io/specification/2026-07-28/server)) — that is the core difference: nobody wires "make an OG image" to `render_image`; the model does.

**One integration for many apps.** A service that implements MCP once works in every host that speaks it. Without MCP, each AI app would need its own plugin format.

**User sign-in for chat apps.** For remote servers the protocol's authorization is based on OAuth 2.1 ([MCP authorization](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization)), so a person can connect their own account to Claude or ChatGPT without handling an API key at all.

## What the API keeps doing better

**Predictability.** Your code calls exactly the endpoint you wrote, every time. A model chooses tools from descriptions and may choose differently on a different day; that is fine in a conversation and wrong in a nightly job.

**Cost and speed.** An API call is the call. A tool call also costs the model's reasoning and the tokens of every tool description and result. Rendering ten thousand product images is a batch request, not ten thousand conversations.

**Everything without a person in the loop.** Webhooks, scheduled jobs, build steps, server-side rendering of `og:image` — none of it has a model to choose tools, and none needs one. For pages you control, a [signed image URL](https://shareglint.com/en/guides/signed-image-urls) does not even need an API call.

## The same task, both ways

Task: an Open Graph image for a new blog post.

**Through the API**, your code sends one request and stores the result:

```bash
curl -X POST "https://shareglint.com/v1/images?wait=true" \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{ "template": "blog-og", "modifications": { "title": "Ten things that ruin your sleep" } }'
```

It runs the same way every time, in your deploy script or CMS hook, with no model involved.

**Through MCP**, a person asks in Claude or Cursor: *"Make an OG image for my post 'Ten things that ruin your sleep' and add the meta tags to the page."* The model calls `list_templates`, picks `blog-og`, calls `render_image` with the title, and edits the page with the returned URL. Nobody wrote the glue — and nobody would want this path for the next thousand posts, which belong in code.

## Designing MCP tools from an API

If you build a server for your own API, a few lessons from building ours:

- **Fewer, task-shaped tools.** We expose `render_image`, `get_image`, `list_templates`, `get_template`, `create_signed_url`, `get_usage`, `generate_template`, `take_screenshot`, `auto_og_url`, `create_batch`, `get_batch`, not one tool per endpoint. A model chooses better from a short list of things a person would ask for.
- **Descriptions are the interface.** The model reads them; write them like documentation for a new colleague: what the tool does, what it costs, which tool to call first (`list_templates` before `render_image`).
- **Return what the next step needs.** A render returns the public image URL and its size, so the model can write `<meta>` tags or answer without another call.
- **Same account, same limits.** Tool calls use the same quota, rate limits and error codes as the API (`402 quota_exceeded`, `429`), so behaviour does not depend on the path a request took.
- **Safe defaults.** Tools that only create artefacts on the user's account are low risk; tools that delete or publish deserve confirmation in the host.

## Which one to use

- **Building a product feature, a backend job or an integration:** the [API](https://shareglint.com/en/docs).
- **Working in Claude, ChatGPT or a coding agent and want it to make images for you:** the [MCP server](https://shareglint.com/en/mcp-server) — setup for each app is linked there.
- **Both:** common. Developers often prototype with the assistant ("render this template with these values, try three titles"), then put the final call into code.

## Cost

Both paths use the same quota: one render per image, repeats free, 100 renders a month on the Free plan with a watermark, Starter $9 a month for 2,000 renders ([pricing](https://shareglint.com/en/pricing)). The AI host's own subscription is separate.

## FAQ

### What is the difference between MCP and an API?

An API is a contract for code: a developer reads the docs and writes the calls. MCP is a contract for AI applications: a server describes its tools, and a model decides at run time which to call and with what arguments. An MCP server often calls an API underneath.

### Does MCP replace REST APIs?

No. Your backend, cron jobs and integrations should keep calling the API directly: it is cheaper, faster and predictable. MCP adds a way for AI assistants and agents to use the same service when a person asks them to.

### Should I build an MCP server for my API?

If people use AI assistants or coding agents to work with your service, yes: a small set of well-described tools lets them do it without glue code. Keep the tools few and task-shaped rather than mirroring every endpoint.

### Is MCP slower than calling the API?

The tool call itself adds little, but a model choosing and reading tools takes seconds and model tokens. For a fixed job that runs a thousand times, call the API; for one-off requests in conversation, MCP is the convenient path.