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) and lists them as "model-controlled", where prompts are user-controlled (server features) — 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), 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 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:
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_templatesbeforerender_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.
- Working in Claude, ChatGPT or a coding agent and want it to make images for you: the 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). The AI host's own subscription is separate.
