An MCP server is a program that gives an AI assistant tools it can use: functions with a name, a description and typed inputs that the assistant can decide to call while it works on your request. MCP — the Model Context Protocol — is the open standard for that connection; its own documentation calls it "an open-source standard for connecting AI applications to external systems", and compares it to "a USB-C port for AI applications" (MCP introduction). This page explains the parts with one real server as the running example: Shareglint's, which lets an assistant render images and take screenshots.
The three roles: host, client, server
The MCP specification names three parts (MCP specification, current version 2026-07-28):
- Host — the AI application you use: Claude, ChatGPT, Cursor, VS Code, Codex.
- Client — the connector inside the host that talks to one server. A host with three servers configured runs three clients.
- Server — the program that "provides context and capabilities": it lists its tools and runs them.
In practice you see two of them. You open your host (say, Claude) and add a server by its address. The client is plumbing inside the host.
What a server offers: tools, resources, prompts
A server can expose three kinds of things (MCP architecture):
| What it is | Who decides to use it | |
|---|---|---|
| Tools | "Executable functions that AI applications can invoke to perform actions (e.g., file operations, API calls, database queries)" | the model |
| Resources | "Data sources that provide contextual information to AI applications" — file contents, records | the application |
| Prompts | "Reusable templates that help structure interactions with language models" | the user |
Tools are what most servers are about, and what makes MCP useful: the model reads each tool's description and decides on its own when calling it would help.
A real server, step by step
Shareglint's MCP server lives at https://shareglint.com/mcp and offers these 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. Here is what happens when you type, in Claude, "Make an OG image for my post 'Ten things that ruin your sleep' and give me the meta tags":
- Discovery. When you added the server, Claude's client asked it for its tools. Each comes with a name (
render_image), a description ("Render an image from a template…") and a JSON schema of its inputs (template,modifications,size…). - Choice. Reading your request, the model sees that
list_templatesandrender_imagematch. Nobody wrote code to connect "OG image" to that tool — the model picked it from the description. - Call. The model sends a tool call:
render_imagewith{"template": "blog-og", "modifications": {"title": "Ten things that ruin your sleep"}}. The host shows it to you and, depending on your settings, asks for approval. - Execution. Our server checks your account, renders the image in headless Chrome, and returns the result: the image URL and its size.
- Answer. The model reads the result and writes its reply: the image, and the
<meta property="og:image" …>tags with the URL filled in.
Underneath, the tool calls our ordinary HTTP API. The MCP server's job is to describe that API in a way a model can use, and to run it on the user's account.
How hosts reach a server: transports
The protocol defines two transports (MCP transports):
- stdio — the host starts the server as a subprocess on your computer and talks to it over standard input and output. Good for tools that touch local files. Credentials come from the environment.
- Streamable HTTP — every message is an HTTP POST to one endpoint of a server somewhere on the internet. This is how remote servers like ours work, and how chat apps such as Claude.ai and ChatGPT connect, since they cannot start programs on your machine.
The older HTTP+SSE transport is deprecated and "eligible for removal in a future revision"; new servers use Streamable HTTP. Our server speaks the current protocol version and the older ones clients still send (2026-07-28, 2025-11-25, 2025-06-18, 2025-03-26).
Signing in: OAuth or a key
For HTTP servers, the specification's authorization is based on OAuth 2.1, and it is optional — stdio servers "retrieve credentials from the environment" instead (MCP authorization). In practice remote servers offer one or both of:
- OAuth — you add the server's URL, the host opens a login page, you sign in to the service and approve the app. Chat apps (Claude, ChatGPT) work this way.
- An API key in a header —
Authorization: Bearer …in the host's config. Coding tools (Cursor, Claude Code, VS Code, Codex) usually work this way.
Ours takes both: chat apps sign in with OAuth, coding tools send an API key; either way it is the same account and quota. Setup per app is on the MCP server page, with pages for Claude, ChatGPT, Cursor, VS Code, Claude Code and Codex.
Finding servers
The official MCP Registry is "the official centralized metadata repository for publicly accessible MCP servers"; it is "currently in preview", so entries and data may still change. Most hosts also have their own directory of connectors. For servers that make or edit images, there is our list of MCP servers for images and design.
Safety in one paragraph
An MCP server acts with your permissions, chosen by a model. Add servers from publishers you trust, prefer read-only or narrowly scoped keys where a server offers them, keep approval prompts on for tools that change things, and remember that text a tool returns (a web page, a document) can contain instructions the model might follow. Our server's tools only render images and screenshots on your account; they cannot read your files or post anywhere.
Cost of our example
Tool calls cost what the same API calls cost: one render per image, repeats with the same values free, 100 renders a month on the Free plan with a watermark (pricing). The host's own subscription (Claude, ChatGPT, Cursor) is separate.
