What Is MCP? A Model Context Protocol Guide: Architecture, Tools, and the Gateway Relationship

MCP (Model Context Protocol) is an open protocol that gives AI applications a standard way to connect to external tools, data sources, and prompt templates. Announced by Anthropic in November 2024, it removes the burden of writing a separate integration for every tool. MCP talks to tools, an LLM gateway talks to models — together they form a complete agent stack.

Before MCP, every application–tool pair needed its own bridge code: calendar access for the chat app, a database connection for the IDE, filesystem access for the agent framework... Each one bespoke, fragile, and repetitive. MCP collapses that integration explosion into a single contract: the application speaks the protocol once, the tool describes itself once.

This guide defines MCP plainly through its architecture (host, client, server) and its three core capabilities (tools, resources, prompts); it clears up the most-confused question — how MCP relates to an LLM gateway — and shows how an MCP-enabled application routes its model calls through one API, with working code, a real price table, and latency measured on production traffic.

What Is MCP and What Problem Does It Solve?

MCP (Model Context Protocol) is an open protocol that standardizes how large language model applications connect to external systems — files, databases, APIs, business tools. Anthropic announced it as open source in November 2024; through 2025 the rest of the industry's major players adopted it, making it the de facto standard for agent–tool connectivity.

The problem it solves is integration explosion. Before MCP, connecting N applications to M tools meant N×M separate integrations: a bridge for every chat app, every IDE, every agent framework; for every database, every project management tool, every filesystem. With MCP, each application implements the protocol once and each tool describes itself once as an MCP server — total work drops to N+M.

The most common analogy is USB-C: just as one standard port connects different devices the same way, MCP connects AI applications to external systems through one standard. The technical substance behind the analogy: MCP is a language-agnostic contract built on JSON-RPC 2.0 messaging, with official SDKs (Python and TypeScript first) and ready-made reference servers for things like the filesystem and Git. That is why "setting up MCP" is usually not writing code — it is pointing your host application at an existing server.

MCP Architecture: How Host, Client, and Server Work

The MCP architecture has three roles: the host the user interacts with, the client inside the host that manages each server connection, and the server that exposes an external system to the model.

• Host: The AI application the user actually uses — Claude Desktop, an IDE assistant, or the agent you build yourself. The host decides when the model sees which context.
• Client: The connection manager running inside the host; it holds a one-to-one session with each MCP server. Users never see this layer.
• Server: A small program that translates a specific external system (filesystem, database, CRM, payment stack) into the protocol. It can run locally or as a remote service.

Communication flows as JSON-RPC 2.0 messages over two transports: stdio for servers on the same machine, streamable HTTP for remote ones. At session start the two sides negotiate capabilities; then the client fetches the server's tool list. The critical detail: every tool describes itself with a name + description + JSON schema triple. The model reads those descriptions and decides on its own which tool to call, when, and with which parameters — this "self-describing tool" idea is what separates MCP from classic API integration.

Tools, Resources, and Prompts: What Does an MCP Server Offer the Model?

An MCP server offers three kinds of capability, and control over each sits with a different party: tools are model-controlled, resources are application-controlled, prompts are user-controlled.

Capability	Who controls it?	What it provides	Example
tools	Model	Action: functions the model calls at its own discretion	Run a database query, write a file, open a support ticket
resources	Application (host)	Read-only context: file-like data sources	Database schema, log file, product catalog
prompts	User	Reusable prompt templates	A "review this code against this checklist" template

The split is not arbitrary; it is the foundation of the security model. Because tools calls are initiated by the model and take action, host applications typically ask for user approval; resources are passive data the host chooses to add to context and cannot trigger actions on their own.

The protocol also defines lesser-known capabilities that live on the client side: with sampling a server can request a model completion through the host, and with elicitation it can ask the user for extra input mid-operation. Day to day, though, the trio in the table is what you will meet — MCP is often explained as just "tool calling", but without resources and prompts the picture is incomplete.

Are MCP and an LLM Gateway the Same Thing? One Talks to Tools, the Other to Models

No, they are not the same — and this is the most-confused topic around MCP: MCP standardizes your application's access to tools, while an LLM gateway standardizes its access to models. They are two doors facing opposite directions in the same architecture.

An agent application has two kinds of external dependency. First, tools: files, databases, third-party services — MCP is the standard on that side. Second, the models themselves: which LLM to call, with which key, invoice, and schema — that side is solved by an LLM gateway. MCP carries "here are the tools at your disposal" to the model; the gateway makes that model's call possible through one endpoint, one key, and one invoice.

That is why the two are complementary, not competing: an MCP-enabled application runs tool discovery and tool calls over MCP sessions, while every reasoning step that needs a model goes to the gateway endpoint. You can swap models without touching the tool layer, and add tools without touching the model layer — each standard preserves the other's independence.

Onysoft sits on both sides of this architecture. First, as the model layer: your MCP-enabled application's LLM calls flow through one API with a TRY balance and per-request cost tracking. Second, as of August 2026, Onysoft also runs its own remote MCP server at https://api.onysoft.com/mcp: any MCP host (Claude Code, Claude Desktop, Cursor...) that connects with your sk-ony key gains tools for querying the model catalog with current TRY prices, calculating token costs, checking balance and usage, and getting model recommendations from OnyRouter. Adding it to Claude Code is one command: claude mcp add --transport http onysoft https://api.onysoft.com/mcp --header "Authorization: Bearer sk-ony-..."

How It Works on Onysoft: an MCP App's Model Calls Through the Gateway

Wiring an MCP application to Onysoft is architecturally simple: an MCP session on the tool side, and on the model side a standard OpenAI client whose base_url is https://api.onysoft.com/v1. MCP tool definitions (name + description + JSON schema) map one-to-one onto the OpenAI tools format. The example below connects the reference filesystem server via the official MCP Python SDK and sends the model call through Onysoft:

import asyncio, json
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client
from openai import OpenAI

llm = OpenAI(
    base_url="https://api.onysoft.com/v1",  # model layer: Onysoft
    api_key="sk-ony-YOUR_KEY",
)

def mcp_tool_to_openai(tool):
    return {
        "type": "function",
        "function": {
            "name": tool.name,
            "description": tool.description or "",
            "parameters": tool.inputSchema,
        },
    }

async def run():
    server = StdioServerParameters(
        command="npx",
        args=["-y", "@modelcontextprotocol/server-filesystem", "./contracts"],
    )
    async with stdio_client(server) as (read, write):
        async with ClientSession(read, write) as session:
            await session.initialize()
            mcp_tools = (await session.list_tools()).tools
            tools = [mcp_tool_to_openai(t) for t in mcp_tools]

            messages = [{"role": "user", "content": "list the files in the contracts folder"}]
            raw = llm.chat.completions.with_raw_response.create(
                model="anthropic/claude-sonnet-5",
                messages=messages,
                tools=tools,
            )
            response = raw.http_response.json()["data"]  # Onysoft response envelope: {"success", "data"}
            call = response["choices"][0]["message"]["tool_calls"][0]
            result = await session.call_tool(
                call["function"]["name"], json.loads(call["function"]["arguments"])
            )
            # result goes back as a "tool" message; the loop runs until the model stops

asyncio.run(run())

An honest technical note: some examples in the MCP documentation use Anthropic's own /v1/messages protocol; the Onysoft endpoint speaks the OpenAI chat/completions schema, not that native protocol. In practice this is no obstacle — the conversion is the three-line function above, and most agent frameworks ship it built in. If you are migrating existing code, the OpenAI SDK migration guide walks through it; streaming (SSE) is supported on the same endpoint, and stream=true is all it takes to show intermediate agent steps live.

Three gateway features earn their keep specifically in agent workloads. First, every response carries a cost field next to the usage block: you read each loop step's cost straight out of the response instead of keeping separate accounting. Second, per-key spending limits: give the agent its own sk-ony key and cap it independently of the rest of your application. Third, the cost pre-check: before a request reaches the model, its estimated cost times a 1.2 safety factor is validated against your balance; if it does not fit, the request returns 402 without running — a runaway tool loop cannot drive your balance negative. Details in the API documentation.

What Does an MCP Agent Loop Cost? A Scenario with Real Prices

What sets an MCP agent's cost is not the number of tools but the tokens sent to the model per loop and the price of the model you choose — and tool definitions count as input tokens again on every step. Let us build a concrete scenario: a five-step support agent; each step carries roughly 3,000 input + 300 output tokens across tool definitions, conversation history, and tool results, so 15,000 input + 1,500 output tokens per task. Task cost at actual catalog sale prices:

Model	Input ($/1M)	Output ($/1M)	Per task (USD)	Per task (TRY)	1,000 tasks/mo (TRY)
deepseek/deepseek-v4-flash	$0.0735	$0.147	$0.0013	₺0.06	₺64.16
openai/gpt-5.6-luna	$0.30	$1.80	$0.0072	₺0.35	₺349.16
google/gemini-3.6-flash	$1.125	$5.625	$0.0253	₺1.23	₺1,227.51
anthropic/claude-sonnet-5	$3.00	$15.00	$0.0675	₺3.27	₺3,273.35
openai/gpt-5.6-terra	$3.00	$18.00	$0.0720	₺3.49	₺3,491.58
anthropic/claude-opus-5	$7.50	$37.50	$0.1688	₺8.18	₺8,183.38

Measured: September 13, 2026 — api.onysoft.com live catalog. Scenario: 15,000 input + 1,500 output tokens per task (5 steps × ~3,000/300). TRY equivalents calculated at the TCMB rate (1 USD = 48.4941 TRY; September 11, 2026). Prices are Onysoft sale prices as of September 13, 2026; see /models for current pricing.

The spread is roughly 128x. Hence the practical strategy is tiered: send routine tool-calling steps to the economy class and critical decision steps to the flagship class — or delegate the choice to OnyRouter (onysoft/auto). Limiting tool definitions to the subset each task needs also cuts every step's input cost directly; see the cost control guide for the broader playbook.

On the time axis, real data again: across 6,959 successful requests through the gateway in the 14 days to August 5, 2026, average end-to-end response was 3.8 seconds and the fastest 0.3 seconds. A five-step loop approaches 20 seconds on the average profile; with lightweight models a step drops below a second. Cutting steps therefore cuts latency at the same rate as cost. To experiment, open a free account and compare the 750+ models in the catalog side by side in the Playground.

Last updated: September 13, 2026 · Data: api.onysoft.com live catalog