MCPCloud.sh — Product and API reference
All concepts

What is an MCP server?

An MCP server is a program that exposes capabilities to AI models over the Model Context Protocol: tools the model can call, resources it can read, and prompts it can reuse. Every tool carries a typed schema and a description the model reads at runtime, so any MCP client — Claude, ChatGPT, Cursor, VS Code — can use your service without custom integration code being written for each client.

What an MCP server contains

The core of a server is its tools: named functions with JSON Schema argument definitions and natural-language descriptions. The descriptions are load-bearing — they are what the model reasons over when deciding which tool to call and how, so a production server treats them as an interface written for agents, not doc-strings written for humans.

Servers can also ship resources (data the client reads into context) and prompts (reusable templates), but most real-world servers earn their keep through a well-curated tool set.

Local vs. remote servers

A local server runs as a child process on the user’s machine and speaks stdio — right for tools that need the local filesystem or environment. A remote server lives at an HTTPS URL and speaks the streamable HTTP transport — right for anything backed by a service or API.

Remote is what makes a server shareable: one URL serves a whole team or customer base, updates land server-side without anyone editing config files, and credentials stay on the server instead of being scattered across laptops.

What production-grade means

Writing an MCP server is the easy half; operating one is where the real requirements live. A server exposed to real users needs authentication (OAuth 2.1 or API keys), somewhere safe to hold upstream credentials, rate limits, request observability, and versioned releases so tool changes don’t silently break the agents that depend on them.

That operational layer is exactly what a hosting platform provides — MCPCloud deploys servers to a global edge runtime with auth, secret custody, rate limits, and per-call tracing built in.

How to get one

You can write a server by hand with the official SDKs (TypeScript and Python are the most common), or generate one from an interface you already maintain: an OpenAPI or GraphQL spec mechanically defines the tool set, and the generation step rewrites each description for agent comprehension — which is the difference between a server that exists and one that agents actually use correctly.

Common questions

What language are MCP servers written in?

Any language — the protocol is JSON-RPC over stdio or HTTP, and clients never see the implementation. Official SDKs exist for TypeScript and Python, with community SDKs for most other ecosystems.

How do remote MCP servers handle authentication?

The MCP specification uses OAuth 2.1 for user-facing authorization on remote servers, and API keys are common for machine access. Upstream credentials — the keys your server uses to call the API behind it — stay server-side and are injected at request time, never exposed to the model or the client.

Can one MCP server serve many users?

Yes. A remote server at a stable URL can be multi-tenant: each user or workspace authenticates separately, and policy — rate limits, tool availability, data scoping — is enforced per caller on the server side.

What happens when the API behind my server changes?

If the server was generated from a spec, regenerate it to pick up new or changed endpoints, then ship the update as a new version. Versioned releases let connected agents migrate deliberately instead of breaking mid-conversation.