How Anthropic MCP Servers Work

Anthropic MCP servers let AI applications use external tools and data through a shared client/server protocol. The MCP client connects to a server, loads the server’s available capabilities into the model’s context, sends tool calls when the model requests them, and returns each result to the model for its next step. The model does not independently open a network connection to the server; the client coordinates the interaction.

Anthropic compares MCP to a USB-C port for AI applications: one connection pattern can link an application to different tools and data sources. The analogy has limits. MCP standardizes how the connection is made, but each client and server can support different transports, capabilities, permissions and authentication methods. See Anthropic’s MCP announcement and the MCP introduction.

1. The MCP architecture

An MCP integration has three roles:

Host application: the AI product a person uses, such as Claude or another MCP-enabled application.
MCP client: the component inside the host that maintains a connection to one or more servers, discovers capabilities and orchestrates calls.
MCP server: a program that exposes capabilities such as tools, resources or prompts.

In Anthropic’s documented tool-use pattern, the client loads tool definitions into the model’s context. Those definitions describe what a tool does and the inputs it accepts. If the model decides a tool is needed, it emits a tool request. The client sends that request to the appropriate MCP server, receives the result and passes it back through the model interaction. The application then uses the result as context for its next response or action.

user request
     |
     v
host application ── MCP client ── MCP server
        |              |              |
        |       tool definitions       |
        |<─────────────┘              |
        |                              |
        |── model requests a tool ───>|
        |                              |
        |<────── tool result ──────────|
        v
final answer or next action

A server provides the external capability. The host and client remain responsible for deciding when to call it, presenting results to the model and enforcing the permissions granted to the connection.

2. What MCP servers expose

Tools

Tools are callable operations. A server might expose a search operation, a database query, a ticket creation action or a screenshot operation. A tool can read data or change it, so its name alone is not a security boundary. Review its implementation and granted permissions.

Resources

Resources provide external content for the application or model to read. Depending on the host and server, resources may be text or binary data. Resource support is product-specific; Anthropic’s current remote-server guidance describes text and binary resources but says resource subscriptions are not supported in that context.

Prompts

Prompts are reusable instructions exposed by a server. They can help an application start a task with a known structure, but the host still controls how the prompt is presented and used.

Do not assume every MCP client supports every capability. Check the target product’s current documentation before relying on tools, prompts, resources, image results, binary resources, subscriptions or sampling.

3. The request and response loop

The user asks the host application to perform a task.
The MCP client connects to configured servers and discovers their available capabilities.
The client makes relevant tool definitions available to the model.
The model selects a tool and supplies arguments when a tool call is appropriate.
The client validates and routes the request to the matching server.
The server performs the operation using its own code and permissions.
The client returns the server’s result to the model.
The model uses that result to answer, call another tool or request confirmation for a further action.

Anthropic describes this as a message loop in which tool calls and results pass through the model between operations. A tool result is context, not an instruction that must be obeyed. Treat content returned by tools as untrusted input because external pages, documents or records can contain prompt-injection attempts.

4. Local versus remote MCP servers

Concern	Local server	Remote server
Where it runs	On the user’s computer or controlled workstation	On infrastructure reached over a network
Installation	Install a package or desktop extension locally	Configure a hosted endpoint and its authentication
Updates	Usually tied to local package or extension updates	The operator can change behavior without a local package update
Authentication	May rely on local process access or local credentials	May use unauthenticated access or OAuth, depending on the host and server
Operational ownership	Your team controls the process and machine	The service operator controls deployment, availability and changes

Anthropic’s remote-server materials discuss SSE and Streamable HTTP, along with authless and OAuth-based connections for supported Claude products. Transport and feature support change over time, so check the current Anthropic documentation for the exact Claude product you are configuring. Anthropic’s directory policy recommends Streamable HTTP and requires secure OAuth 2.0 for authenticated remote servers submitted to its directory; that directory rule does not define every possible MCP connection.

5. How to choose and review a server

Identify the operator. Verify who maintains the code or hosted service. Inspect local source or packages when available.
Check the transport. Confirm that the target Claude product supports the server’s transport.
Review authentication and scopes. Grant only the OAuth scopes or credentials required for the task.
List every capability. Separate read-only tools from operations that create, delete or modify data.
Understand updates. A remote operator may change tool behavior after approval. Monitor release notes and connection changes.
Plan incident response. Know how to revoke connector access, rotate credentials and disable a server.

Use read-only access where it is sufficient. Anthropic’s guidance also recommends sandboxing, resource limits and monitoring when agent-generated code is involved.

6. Connecting Claude to an MCP server

The exact setup depends on whether you are using Claude, Claude Desktop, Claude Code or the Messages API. Anthropic documents MCP support across those products, but setup screens, configuration formats and feature coverage are product-specific.

Local connection checklist

Install the server from a source you trust.
Pin or review the package version when your workflow requires reproducibility.
Give the process only the environment variables, files and network access it needs.
Configure the server in the host product using that product’s current instructions.
Test a read-only operation before enabling write actions.

Remote connection checklist

Confirm the endpoint uses a transport supported by your Claude product.
Verify the hostname and operator before approving the connection.
Review OAuth scopes and redirect or consent details.
Use TLS and rotate credentials according to your organization’s policy.
Monitor server changes and revoke access if behavior or ownership changes unexpectedly.

7. Calling a screenshot server from an AI agent

A screenshot server is a concrete example of MCP’s client/server pattern: the agent discovers a screenshot tool, supplies a URL and capture options, receives an image or PDF, and uses that result in the next step.

ScreenshotNeo provides an MCP server with take_screenshot, get_page_info and capture_pdf tools for Claude, Cursor and other MCP clients. It also exposes a regular HTTP API when an agent does not need MCP.

8. Or skip the browser setup

If you only need a reliable page image, call ScreenshotNeo directly. The endpoint accepts one GET request and returns PNG, JPEG or WebP (or a PDF when configured). See the ScreenshotNeo API documentation for all options.

cURL

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://stripe.com \
  -o shot.webp

Python

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

Node.js

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://stripe.com'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`HTTP ${res.status}`);
const buffer = Buffer.from(await res.arrayBuffer());
require('node:fs').writeFileSync('shot.webp', buffer);

ScreenshotNeo removes cookie and consent banners, newsletter popups and chat widgets before capture. Bot checks, blank pages, timeouts, failed loads and cache hits are not billed; response headers identify the page verdict and whether the request was billed. Its MCP server lets AI agents take screenshots without you wiring a browser automation stack. The free plan includes 1,000 screenshots each month with no card, and paid plans start at $5 for 3,000 shots. Create a free ScreenshotNeo account.

9. Security and prompt-injection risks

An MCP connection expands what an AI application can read or do. Anthropic identifies two broad risk areas: software supply-chain or code-execution risk, and prompt injection in content the model reads.

Inspect local code. Pin dependencies and review packages where practical.
Trust remote servers carefully. A hosted operator can change behavior after approval.
Minimize permissions. Use narrow OAuth scopes and read-only credentials whenever possible.
Validate tool arguments. Apply allowlists, schema checks and confirmation steps for sensitive operations.
Treat results as data. Do not let text returned from a page or document silently override the agent’s policy.
Sandbox execution. Restrict filesystem, network and CPU access for agent-generated code.
Monitor and revoke. Log calls, watch for unusual activity and know how to disable the connector.

10. Troubleshooting MCP connections

Symptom	Likely cause	Fix
The server never appears	Incorrect host configuration, command path or package installation	Recheck the product-specific setup guide, executable path and server logs.
Connection works locally but not remotely	Unsupported transport, blocked network path or TLS problem	Confirm the Claude product supports the server transport and verify endpoint certificates and firewall rules.
OAuth approval fails	Invalid redirect, expired consent or excessive scopes	Restart authorization, verify the registered redirect and request only required scopes.
A tool is missing	The server did not advertise it or the client does not support that capability	Inspect the server’s advertised capabilities and the host product’s current MCP support.
Arguments are rejected	Tool input does not match the server’s schema	Use the discovered definition, include required fields and validate types before calling.
The model follows hostile text from a result	Prompt injection in external content	Treat results as untrusted, isolate instructions from data and require confirmation for consequential actions.
A remote tool changed behavior	Server operator deployed an update	Review change history, restrict permissions, pin a local implementation where appropriate or revoke access.

11. Performance, reliability and cost

MCP adds an orchestration hop: the client must discover capabilities, send a request to the server and return the result to the model. Keep tool descriptions focused, return only the data needed for the next decision and avoid sending large unfiltered documents into the context.

For reliability, set timeouts, handle server disconnects, retry only idempotent operations and record request identifiers where the host or server provides them. A retry around a write operation can create duplicates unless the server supports idempotency. Remote servers also introduce dependency on network availability and the operator’s deployment process.

Costs depend on the host model, the server and any external services the server calls. MCP itself is a connection protocol, not a universal pricing plan. For screenshot workloads, ScreenshotNeo bills only clean shots; failed loads, bot checks, blank pages, timeouts and cache hits cost nothing, and its headers report the verdict and billing result. Caching with a chosen TTL, bulk capture and asynchronous jobs can reduce repeated work for suitable workflows.

12. FAQ

Does Claude connect directly to an MCP server?

No. The MCP client in the host application coordinates discovery, tool calls and results between the model and server.

Are MCP servers always remote?

No. They can run locally on a user’s machine or remotely on hosted infrastructure. The choice changes installation, authentication, updates and operational ownership.

Can an MCP tool modify data?

Yes. A server can expose read or write operations. Review capabilities and grant the smallest practical permissions.

Is every MCP feature available in every Claude product?

No. Transport and capability support vary by product and can change. Check Anthropic’s current documentation before implementation.

MCP can expose a screenshot operation as a tool for an AI agent. A normal HTTP endpoint, such as ScreenshotNeo’s API, is useful when your application already has its own orchestration code.

13. Practical checklist

Map the host, MCP client and server before debugging.
Confirm the transport and capability support for the exact Claude product.
Review who operates the server and how it updates.
Grant narrow scopes and prefer read-only access.
Validate arguments and require confirmation for destructive actions.
Treat all tool output as untrusted external content.
Add timeouts, retry rules, logging and revocation procedures.
Use a direct API such as ScreenshotNeo when MCP is unnecessary for the workflow.