Paso 0 · El MCP entrega el contexto ensamblado al LLM
● FROM MCP
MCP Context Payload
CONTEXTO MCP
Paquete unificado: system prompt + tools + resources + history + user query
🔧 System Instructions — 4.2K tokens
⚡ Tools Schema (24 tools) — 12.8K tokens
📦 Resources (DB schemas, docs) — 18.4K tokens
💬 Conversation History — 8.6K tokens
👤 User Query — 0.3K tokens
🔄 Previous tool_results — 6.2K tokens
50.5K tokens payload
①
Paso 1 — Tokenización & EncodingTOKENIZER
~12ms
1.1
BPE Tokenizer
Byte-Pair Encoding convierte cada carácter del contexto MCP a tokens numéricos. "query_sql" → [8834, 2102, 4719]. Vocabulario de ~100K tokens.
100K vocab
UTF-8
→
1.2
Special Token Injection
Inserta tokens especiales: [SYSTEM], [TOOLS_START], [TOOL_DEF], [RESOURCES], [USER], [ASSISTANT], [TOOL_USE], [TOOL_RESULT] para marcar secciones del MCP.
8 special tokens
→
1.3
Token Embedding
Cada token ID se convierte a un vector denso de dimensión d=4096. Lookup en la embedding matrix: 100K × 4096 parámetros. Produce tensor [seq_len, 4096].
d=4096
~410M params
→
1.4
Positional Encoding
Agrega información de posición con RoPE (Rotary Position Embedding). El LLM sabe el ORDEN del contexto MCP: qué va primero (system) y qué al final (user query).
RoPE
128K max pos
Tensor [50.5K, 4096]
②
Paso 2 — Lectura del Contexto MCP (Self-Attention)ATTENTION LAYERS
~120ms
2.1
Multi-Head Attention
96 "cabezas" de atención leen el contexto SIMULTÁNEAMENTE. Cada cabeza se especializa: unas leen tools, otras resources, otras la relación entre user query y data disponible.
96 heads
Parallel
→
2.2
Query-Key-Value
Para cada token, calcula Q (qué busco), K (qué ofrezco), V (qué valor tengo). Cuando el LLM lee "query_sql", su Q busca schemas en los K de los resources del MCP.
QKV matmul
d_head=128
→
2.3
Attention Scores
softmax(QK^T/√d) produce scores de atención. El LLM asigna PESO a cada parte del MCP: alto peso a tools relevantes, bajo peso a history antigua. Así "lee" selectivamente.
softmax
Causal mask
→
2.4
Context Mixing
Multiplica scores × V. Mezcla información: el token de user query ahora "contiene" información de los tools schema y resources del MCP. Contexto fusionado.
Score × V
Concat heads
→
2.5
KV Cache
Cachea los Key-Value del contexto MCP completo. En tokens subsiguientes NO re-calcula el contexto. Solo atiende al nuevo token contra el cache. Eficiencia 10x.
KV cached
~8GB VRAM
Contextualized vectors
③
Paso 3 — Razonamiento & Comprensión (Feed-Forward + MoE)REASONING ENGINE
~80ms
3.1
Feed-Forward Network
Cada token pasa por 2 capas densas: up-projection (4096→16384) → SwiGLU activation → down-projection (16384→4096). Aquí ocurre el "pensamiento" no-lineal.
SwiGLU
4x expansion
→
3.2
Mixture of Experts
Router selecciona 2 de 8+ experts para cada token. Un expert se especializa en código/tools, otro en lenguaje natural, otro en datos numéricos. Eficiencia: solo 25% de params activos.
8 experts
Top-2 routing
→
3.3
Layer Norm + Residual
Normaliza activaciones + suma residual del input. Estabiliza el gradiente. Permite que información del MCP original fluya directamente a capas profundas sin degradarse.
RMSNorm
Skip connect
→
3.4
×80 Layers Deep
Los pasos 2+3 se repiten 80 VECES. Cada capa refina la comprensión. Capas tempranas: sintaxis y schema. Medias: semántica y relaciones. Profundas: razonamiento y planificación.
80 layers
Progressive
Deep representations
④
Paso 4 — Decisión: ¿Usar Tool o Responder Directo?DECISION LAYER
~15ms
4.1
Intent Detection
Las representaciones profundas "saben" si la query necesita datos (→ tool) o si puede responder con conocimiento interno. Analiza: ¿hay un tool que matchee la necesidad?
Classification
→
4.2
Tool Matching
Compara la query contra los 24 tool schemas del MCP que leyó en Step 2. Calcula relevancia: query_sql score=0.94, get_kpi score=0.87, search_docs score=0.23...
24 tools scored
→
4.3
Plan Generation
Si necesita múltiples tools, genera un PLAN interno: "1. query_sql para datos raw → 2. get_kpi para métricas → 3. sintetizar respuesta". El MCP ejecutará cada paso.
Multi-step plan
→
4.4
Decision Output
Emite decisión: genera token especial [TOOL_USE] seguido del nombre del tool y parámetros JSON, O genera [TEXT] para respuesta directa. Bifurcación crítica del flujo.
→ TOOL_USE
→ TEXT
⚡ Si TOOL_USE → genera tool call JSON → MCP ejecuta → resultado regresa como tool_result → vuelve a Step 2
Decision: tool_use | text
⑤
Paso 5 — Generación Token-by-Token (Autoregressive Decode)DECODER
~200-600ms
5.1
Logits Head
Última capa lineal: transforma vector 4096 → 100K logits (uno por cada token posible del vocabulario). Raw scores sin normalizar.
4096→100K
Linear proj
→
5.2
Sampling Strategy
Aplica temperature (0.3 = conservador), top-p (nucleus sampling 0.95), top-k filtering. Baja temperatura = respuestas más deterministas y factuales para datos financieros.
temp=0.3
top_p=0.95
→
5.3
Token Selection
Selecciona el token con mayor probabilidad post-sampling. Ejemplo: genera "tool_use" o genera la primera palabra de la respuesta. Un token a la vez, secuencialmente.
Autoregressive
→
5.4
Append & Loop
El token generado se agrega a la secuencia. Vuelve a Step 2 (con KV Cache, solo procesa el nuevo token). Repite hasta generar [STOP] o tool_use block completo. 200-1200 tokens.
Loop until stop
KV cached
→
5.5
Stream Output
Cada token generado se envía inmediatamente via SSE al cliente. El usuario ve la respuesta aparecer en tiempo real. No espera a que termine toda la generación.
SSE stream
Per-token
Generated token stream
⑥
Paso 6 — Ejecución de Tool Call (Loop MCP ↔ LLM)TOOL LOOP
~50-500ms per call
6.1
tool_use Block
LLM genera JSON: {"type":"tool_use", "name":"query_sql", "input":{"query":"SELECT revenue FROM..."}}. El MCP intercepta este bloque antes de enviarlo al usuario.
JSON block
→
6.2
MCP Executes
MCP recibe el tool call, lo rutea al server correcto (mcp-server-db), ejecuta query_sql contra PostgreSQL, obtiene 847 rows, sanitiza resultado, y lo empaqueta como tool_result.
MCP routing
Server exec
→
6.3
tool_result Injection
tool_result se inyecta como nuevo mensaje en el contexto: [TOOL_RESULT] + data. El LLM ahora tiene los datos REALES de las bases de datos del MCP para razonar.
Context updated
→
6.4
Re-enter Inference
LLM vuelve a Step 2 con el contexto expandido. Ahora "lee" los datos reales. Puede decidir: otro tool call (más datos) o generar respuesta final con la información obtenida.
→ Step 2
Max 10 loops
↻ Loop iterativo: el LLM puede llamar N tools secuencialmente hasta tener toda la data necesaria para responder
⑦
Paso 7 — Post-Procesamiento & Validación de SalidaOUTPUT VALIDATOR
~18ms
7.1
Safety Output Filter
RLHF-trained classifier evalúa la respuesta completa. Verifica: no PII expuesto, no alucinaciones detectables, no contenido fuera de política. Bloquea si falla.
RLHF check
Block/Pass
→
7.2
Hallucination Check
Verifica que los datos citados coincidan con los tool_results reales. Cross-reference: si dice "$4.2M revenue" → busca en el tool_result de query_sql. Flags inconsistencias.
Fact verify
Source match
→
7.3
Citation Builder
Agrega citations trazables: cada dato se liga a su data source original del MCP. "[Revenue: $4.2M — source: PostgreSQL/financials, query_sql, row 42]".
Traceability
→
7.4
Format & Serialize
Estructura la respuesta final: text blocks + tool_use blocks + metadata. Serializa a JSON response. Calcula token usage (input + output) para billing y audit.
JSON serialize
Usage calc
→
7.5
Audit & Trace Log
Registra trace completo: request_id, user, tokens_in, tokens_out, tool_calls[], latency_ms, safety_score, sources_used[]. Compliance log para auditoría.
Full trace
Compliance
Final validated response
⑧
Paso 8 — Entrega al Usuario FinalRESPONSE DELIVERY
~5ms
8.1
SSE Stream Encode
Codifica respuesta validada en formato SSE (Server-Sent Events). Cada chunk es un evento data:. El usuario ya vio tokens previos en streaming; este es el cierre final.
SSE
Final chunk
→
8.2
Metadata Attach
Adjunta metadata: model usado, tokens consumidos (input: 50.5K, output: 842), latency total, tools_called: [query_sql, get_kpi], stop_reason: end_turn.
Usage metadata
→
8.3
Cache Response
Si la query es cacheable, guarda en Redis con TTL. Próxima query similar no necesita re-inferencia completa. Cache key = hash(user_query + context_fingerprint).
Redis cache
TTL 300s
→
8.4
Deliver to Client
HTTP 200 con body JSON completo. El frontend renderiza: texto formateado, tablas de datos, gráficos generados, citations clicables, y metadata de fuentes del MCP.
HTTP 200
Complete
● DELIVERED
Response Delivered
USUARIO FINAL
Respuesta con datos reales del MCP · Citada · Validada · Trazable
Dashboard Widget
Chat Response
Auto-generated Report
API JSON Response
Push Notification
Email Digest
Slack Message