↓ Skip to main content
Le Site de François
  1. Index/

MCP (Model Context Protocol)

Ai Mcp Agents Llm Tools Integration Api

MCP (Model Context Protocol) is an open standard for how LLM applications discover and invoke tools, read structured resources, and exchange prompts with external systems through MCP servers and clients. The objective is interchangeable integrations: instead of every chat product implementing bespoke plugins for Git, databases, or ticketing, a tool provider ships an MCP server and any compatible client (IDE, assistant, agent runtime) can use it with consistent auth and capability negotiation. MCP complements HTTP inference APIs—it sits at the orchestration layer where the model decides which tool to call, not inside vLLM’s token loop. It is widely associated with agentic workflows (multi-step plans, code execution, retrieval).

Architecturally, MCP is control-plane and I/O heavy relative to GPU matmuls. The CPU runs the host application, MCP client library, and often local or remote MCP servers (stdio, SSE, or streamable HTTP transports). The LLM still runs on GPU via vLLM, cloud API, or NIM; MCP messages carry tool definitions, arguments, and results back into the prompt context. That increases prefill size and token cost versus single-shot chat. Security matters: tools equate to arbitrary code or data access, so enterprises pair MCP with policy, sandboxing, and identity—similar concerns to RAG connectors. MCP does not replace Kubernetes scheduling; it standardizes application wiring above the platform.

Red Hat discusses MCP in the context of AI agents on OpenShift and RHEL AI—connecting models to cluster APIs, observability, and developer workflows without locking to one vendor IDE. Blog and documentation themes include operationalizing agents with the same Linux, OpenShift security (SCCs, routes, secrets), and Guardrails-style safety layers used for raw LLM serving. Red Hat does not own the protocol (Anthropic-originated, community ecosystem); the platform value is running MCP servers and inference backends on a supported, auditable stack customers already operate.

Related

Context window

Ai Context-Window Llm Tokens Kv-Cache Inference Rag
The context window is the maximum span of tokens—input prompt plus model-generated output—that an LLM can process in a single forward pass chain without truncating or sliding attention. It is set by model architecture (positional encoding limit, e.g. 8K, 128K, 1M+ in newer models) and by practical VRAM on the serving GPU, because the KV cache scales with total sequence length. Its objective is to bound memory and compute: longer windows enable whole documents, multi-turn chat history, and large RAG payloads in one shot, but cost more on every prefill and decode step. APIs expose this as max_tokens, context limits, or model cards; exceeding it yields errors or silent truncation.

Decode

Ai Decode Inference Llm Kv-Cache Vllm Throughput Latency
Decode is the second stage of LLM inference: after prefill has stored keys and values for the prompt, the model generates one new token per forward pass, appends it to the sequence, extends the KV cache, and repeats until a stop condition (EOS token, max length, or API limit). Its objective is fluent continuation—answer text, code, or tool-call JSON—at acceptable inter-token latency and cluster throughput (tokens per second across many concurrent sessions). Decode drives the “typing” experience in chat UIs; prefill drives how long users wait before the first character appears.

Fine-tuning / LoRA

Ai Fine-Tuning Lora Training Llm Peft Openshift-Ai Rhel-Ai
Fine-tuning is training continued from a pretrained LLM (or other model) on a smaller, task-specific dataset so behavior matches a domain—support tone, internal jargon, classification format, or tool-use style—without pretraining from scratch. LoRA (Low-Rank Adaptation) is a parameter-efficient fine-tuning method: instead of updating all billions of weights, small low-rank matrices are inserted into attention (and sometimes MLP) layers and only those adapters are trained, drastically cutting VRAM and checkpoint size. The objective is better task accuracy or alignment at lower cost than full fine-tuning; adapters can be swapped per tenant while a frozen base model stays shared. Fine-tuning differs from RAG, which injects external facts at inference time without changing weights.