La evolución de la orquestación de agentes de IA: system prompts, skills, MCP y plugins

Todos los equipos que he visto adoptar agentes de IA para programar siguen la misma trayectoria invisible. Empiezan con un system prompt: unas pocas líneas de contexto pegadas en una ventana de chat. Luego el prompt crece, se vuelve desordenado y alguien lo convierte en una skill reutilizable. Después la skill necesita datos reales, así que conectan un servidor MCP. Finalmente, alguien empaqueta todo como un plugin y, de repente, se convierte en infraestructura.

Esta progresión no es accidental. Es una curva natural de madurez que refleja cómo evoluciona cualquier herramienta de ingeniería: de script a biblioteca y de biblioteca a servicio. Entenderla de antemano te permite avanzar por las etapas de forma deliberada, en lugar de hacerlo solo como reacción a los problemas.

Las cuatro capas

En cualquier momento de esta evolución, trabajas en una de cuatro capas:

1. System Prompt — contexto que se inyecta antes de cada conversación
2. Skills y comandos — workflows reutilizables que se pueden invocar: comandos como plantillas de prompts y skills como unidades inteligentes que se pueden descubrir automáticamente
3. Herramientas MCP — acceso estructurado a sistemas externos mediante un protocolo estándar
4. Plugins / extensiones — paquetes que combinan las tres capas anteriores y se distribuyen como unidades compartibles

Cada capa se construye sobre la anterior. Rara vez puedes saltarte una: un plugin que pasa directamente a invocar herramientas sin instrucciones que le den contexto al modelo alucinará. Una skill sin acceso a MCP no puede llegar a tus datos reales. Las capas son acumulativas.

Capa 1: el system prompt

Los system prompts son el punto de partida de cualquier workflow de IA. Ahí defines la personalidad del modelo, sus restricciones y el conocimiento del dominio que necesita para ser útil en tu contexto.

Cómo se ve en Claude Code

Claude Code lee archivos CLAUDE.md en tres niveles —proyecto (./CLAUDE.md), usuario (~/.claude/CLAUDE.md) y política empresarial— y los combina en un único system prompt efectivo antes de cada sesión.

Un CLAUDE.md típico para un equipo de backend se ve así:

# CLAUDE.md

## Stack
- Node.js 22 + TypeScript strict mode
- PostgreSQL 16 via Prisma ORM
- Jest for tests, ESLint + Prettier for style

## Conventions
- All new functions need JSDoc with @param and @returns
- Database queries go through service layer — never in controllers
- Run `npm test` before committing, fix any failures

## Branching
- Feature branches: feature/<jira-id>-<short-desc>
- Never push directly to main or develop

## Commands
- `npm run dev` starts the local dev server
- `npm run db:migrate` runs pending Prisma migrations

Cómo se ve en Cursor IDE

Cursor usa .cursor/rules: un directorio de archivos .mdc, cada uno con un alcance definido según cuándo se aplica:

.cursor/rules/
  global.mdc          # Always attached
  typescript.mdc      # Auto-attached to *.ts, *.tsx files
  database.mdc        # Manually invoked when working on DB code
  security.mdc        # Agent-requested when model detects security context

Cada archivo de reglas incluye metadatos:

---
description: TypeScript and React conventions
globs: ["**/*.ts", "**/*.tsx"]
alwaysApply: false
---

Use functional components only. No class components.
All async operations must have explicit error handling.
State management via Zustand — no Redux.

Cuándo basta el system prompt

El system prompt funciona bien cuando:

• El contexto es estable: tu stack no cambia de un proyecto a otro
• Las instrucciones son declarativas: le dicen al modelo qué hacer, no cómo
• El contexto cabe cómodamente en ~2,000 tokens sin desplazar la conversación en sí

Un proyecto de un solo equipo con un stack establecido rara vez necesita más que un CLAUDE.md bien escrito. El problema aparece cuando el prompt intenta hacer demasiado.

Cuándo pasar a la siguiente capa

Los system prompts dejan de ser suficientes en tres situaciones:

Explosión de contexto. Un prompt que intenta codificar todo tu manual de ingeniería —reglas de contratos de API, esquema de base de datos, procedimientos de despliegue, lista de verificación para revisión de código— llenará la ventana de contexto y aun así quedará incompleto. Los modelos también empiezan a ignorar las instrucciones enterradas en un prompt largo.

Tareas procedimentales repetitivas. Cuando te encuentras escribiendo la misma instrucción de varios pasos una y otra vez («revisa este PR: verifica los tipos, el manejo de errores y la cobertura de pruebas; resume los resultados en el formato de descripción del PR»), tienes una skill esperando a ser extraída.

Contexto dinámico. Cuando las instrucciones necesitan hacer referencia a datos en vivo —«usa el esquema actual de nuestra base de datos» o «revisa la última especificación de API de nuestro sitio de documentación»—, un archivo de texto estático no puede ayudarte.

Capa 2: skills y comandos

En esta capa viven los workflows reutilizables. Claude Code ofrece dos mecanismos relacionados pero distintos: los comandos son plantillas de prompts simples que se invocan con una barra diagonal, mientras que las skills son unidades estructuradas e inteligentes de workflow que Claude puede descubrir y ejecutar de forma autónoma. Ambos convierten instrucciones repetidas en el chat en artefactos reutilizables con nombre, pero las skills pueden hacer mucho más.

Comandos

Un comando es un archivo Markdown en .claude/commands/. Su nombre se convierte en un comando con barra diagonal. Su contenido es una plantilla de prompt que Claude ejecuta cuando lo invocas.

.claude/commands/
  review-pr.md
  gen-migration.md
  write-adr.md
  update-changelog.md

.claude/commands/review-pr.md:

Review the current git diff as a pull request.

Check the following in order:
1. TypeScript types — are all new functions properly typed?
2. Error handling — are async operations wrapped in try/catch?
3. Test coverage — do new code paths have tests?
4. Prisma queries — are they going through the service layer?
5. Performance — any N+1 queries or missing indexes?

After review, generate a PR description in this format:

## Summary
[2-3 bullet points about what this PR does]

## Test Plan
[Checkbox list of how to verify the changes]

## Risk
[Low / Medium / High and why]

Use $ARGUMENTS to target a specific file or directory.

Ahora /review-pr src/auth/ ejecuta el workflow completo sin tener que volver a escribir las instrucciones.

.claude/commands/gen-migration.md:

Generate a Prisma migration for the following schema change: $ARGUMENTS

Steps:
1. Read the current schema at prisma/schema.prisma
2. Design the migration to add/modify the requested fields
3. Check for data implications — will existing rows need backfilling?
4. Generate the migration SQL
5. Update the schema file
6. Write a short description of what the migration does for the migration history

If this migration is destructive (drops columns or tables), flag it clearly.

Los comandos transforman el system prompt de un documento de contexto pasivo en un registro activo de workflows. El system prompt le dice al modelo quién es. Los comandos le dicen qué sabe hacer.

Cómo funcionan las skills de Claude Code

Las skills son la evolución de los comandos. Mientras que un comando es una plantilla de prompt simple que invocas manualmente, una skill es una unidad estructurada con metadatos, reglas de invocación y la capacidad de crear agentes paralelos, inyectar datos en vivo y adaptarse a tu base de código.

Una skill se encuentra en .claude/skills/<name>/SKILL.md:

.claude/skills/
  review-pr/
    SKILL.md
  scaffold-tests/
    SKILL.md
  deploy/
    SKILL.md
    runbook.md     # referenced supporting files

.claude/skills/review-pr/SKILL.md:

---
name: review-pr
description: Reviews pull requests against team standards. Use when asked to review a PR or diff.
allowed-tools: Read, Grep, Glob, Bash
---

Review the PR at $ARGUMENTS against our engineering standards:

1. TypeScript types — all new functions properly typed?
2. Error handling — async operations wrapped in try/catch?
3. Test coverage — new code paths have tests?
4. Service layer — queries going through service layer only?
5. Performance — N+1 patterns or missing indexes?

Generate a PR description with Summary, Test Plan, and Risk level.

El campo description es clave. Claude lee las descripciones de las skills al inicio de la sesión e invoca automáticamente la skill cuando el contexto coincide; no tienes que escribir /review-pr. Pregunta «¿puedes revisar este diff?» y Claude cargará la skill porque su descripción coincide.

.claude/skills/deploy/SKILL.md:

---
name: deploy
description: Runs the deployment checklist for a service.
disable-model-invocation: true
allowed-tools: Bash, Read
---

Deploy $ARGUMENTS to the target environment:

1. Run `npm test` — abort if any failures
2. Check the deployment checklist in runbook.md
3. Run `npm run build`
4. Push the image and verify health checks pass

DO NOT proceed if any step fails.

disable-model-invocation: true significa que Claude nunca ejecutará esto automáticamente: solo tú puedes activarlo con /deploy. Es fundamental para cualquier operación con efectos en el mundo real.

Las skills pueden inyectar datos en vivo antes de ejecutarse:

---
name: pr-summary
description: Summarizes a PR with its current diff and review comments.
---

Context:
- PR diff: !`gh pr diff $ARGUMENTS`
- Existing comments: !`gh pr view $ARGUMENTS --comments`

Summarize the PR, highlight the most important reviewer feedback, and suggest next steps.

La sintaxis !command“ ejecuta el comando de shell en el momento de la invocación e inyecta su salida en el prompt. Ahora la skill trabaja con datos reales, no con una descripción de los datos que podrían existir.

Las skills pueden ejecutar subagentes en paralelo:

---
name: deep-review
description: Thorough code review using multiple parallel reviewers.
context: fork
---

Spawn three parallel review agents for $ARGUMENTS:
- Agent 1: Focus on correctness and logic errors
- Agent 2: Focus on security vulnerabilities and input validation
- Agent 3: Focus on performance and scalability

Aggregate their findings into a single prioritized report.

context: fork aísla la skill en un subagente, lo que evita que el trabajo pesado de revisión sature el contexto de tu conversación principal.

Campos clave del frontmatter:

Claude Code incluye varias skills listas para usar: /batch paraleliza refactorizaciones grandes en worktrees aislados, /simplify ejecuta tres agentes de revisión de código simultáneos y reúne sus hallazgos, /loop programa prompts recurrentes a intervalos y /claude-api carga la referencia del SDK de Anthropic en tu sesión.

La distinción entre comandos y skills importa a medida que tus workflows se vuelven más complejos. Los comandos funcionan bien para plantillas simples que reciben y devuelven texto. Las skills son la opción adecuada cuando necesitas descubrimiento automático, protecciones para acciones destructivas, inyección de datos en vivo o ejecución paralela en bases de código grandes.

El equivalente en Cursor: reglas de agentes y Composer

Composer de Cursor (el modo de agente para múltiples archivos) te permite adjuntar reglas de forma selectiva en cada sesión. Las reglas con alwaysApply: false están disponibles bajo demanda. También puedes crear «Notepads» reutilizables: bloques de contexto persistentes que adjuntas a cualquier conversación.

El patrón es el mismo: extraer instrucciones repetidas del chat y convertirlas en una unidad reutilizable con nombre.

Casos de uso reales en ingeniería

Revisión de código (comando /review-pr o skill con invocación automática): Codifica toda la lista de verificación de revisión de tu equipo. El modelo la aplica de forma consistente a cada diff sin que tengas que especificar de nuevo cada criterio.

Generación de ADR (/write-adr): Recibe la descripción de una decisión, investiga la base de código para obtener contexto y genera un Architecture Decision Record con el formato de la plantilla de tu equipo.

Actualización del changelog (/update-changelog): Lee los commits recientes, los categoriza por tipo de conventional commit y agrega una entrada con el formato adecuado a CHANGELOG.md.

Creación de estructuras de pruebas (/scaffold-tests): A partir de una ruta de archivo, lee el módulo, identifica funciones sin pruebas y genera pruebas base de Jest con los patrones de mocking adecuados para tu proyecto.

Refactorización paralela (skill /batch integrada): Divide un cambio grande en la base de código en 5–30 unidades independientes y las ejecuta en paralelo en worktrees aislados, mucho más rápido que con ediciones secuenciales.

Despliegues protegidos (skill /deploy con disable-model-invocation: true): Ejecuta una lista de verificación previa, valida el entorno y realiza el despliegue. La opción de seguridad garantiza que Claude nunca despliegue sin un comando humano explícito.

Cuándo pasar a la siguiente capa

Los comandos y las skills son potentes, pero siguen trabajando con texto en un circuito cerrado. En cuanto necesitas que:

• Consulten tu base de datos real para conocer el estado actual del esquema
• Obtengan la última especificación de una API interna
• Creen un ticket de Jira
• Lean el sistema de documentación interna de tu empresa
• Interactúen con GitHub, Slack o cualquier servicio externo

…has llegado al límite de lo que puede hacer un prompt estático. Ahí es donde entra MCP.

Capa 3: herramientas MCP

Model Context Protocol (MCP) es un estándar abierto —creado por Anthropic, pero adoptado por toda la industria— que define cómo los modelos de IA se conectan a sistemas externos. Es la capa estructurada de entrada y salida entre tu agente de IA y el mundo real.

La arquitectura

MCP usa un modelo cliente/servidor con dos transportes: stdio (comunicación entre procesos locales) y SSE (eventos enviados por el servidor mediante HTTP para servidores remotos). Un servidor MCP expone tres tipos de elementos primitivos:

• Tools — funciones que el modelo puede llamar (consultar una base de datos, crear un ticket, ejecutar un build)
• Resources — contexto que el modelo puede leer (documentación, esquema, configuración)
• Prompts — plantillas de prompts definidas por el servidor que el modelo puede invocar

┌─────────────────┐       MCP (stdio/SSE)      ┌─────────────────┐
│   Claude Code   │ ◄─────────────────────────► │   MCP Server    │
│   or Cursor     │   tools / resources /        │  (your system)  │
│    (client)     │        prompts               │                 │
└─────────────────┘                              └─────────────────┘
                                                        │
                                                        ▼
                                               Your DB / API / Service

Conectar servidores MCP en Claude Code

Los servidores MCP se configuran en .claude/settings.json:

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "POSTGRES_CONNECTION_STRING": "postgresql://localhost/myapp_dev"
      }
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    },
    "jira": {
      "command": "npx",
      "args": ["mcp-server-jira"],
      "env": {
        "JIRA_HOST": "https://mycompany.atlassian.net",
        "JIRA_API_TOKEN": "${JIRA_TOKEN}"
      }
    }
  }
}

Una vez configurados, el modelo puede llamar estas herramientas de forma natural durante la conversación, sin sintaxis especial ni conexión manual. Decide cuándo usarlas según el contexto.

MCP transforma las skills en workflows reales

Ahora las skills de la capa 2 adquieren verdadero poder:

/review-pr + GitHub MCP:

Review the current PR: $ARGUMENTS

1. Use the GitHub tool to fetch the PR diff and all inline review comments
2. Run the review checklist (types, error handling, tests, service layer, performance)
3. Check if any flagged patterns match existing GitHub issues
4. Post the review as a GitHub PR review (not just a comment) with line-level annotations
5. If all checks pass, approve the PR; otherwise request changes

/gen-migration + PostgreSQL MCP:

Generate a migration for: $ARGUMENTS

1. Use the postgres tool to read the current schema — run \d on relevant tables
2. Check for existing migrations in prisma/migrations/ to understand migration history
3. Generate the migration ensuring it's compatible with the current production schema
4. Check if any existing data would be affected
5. Generate rollback SQL as well

/write-adr + Confluence MCP:

Write an ADR for: $ARGUMENTS

1. Search Confluence for existing ADRs on related topics
2. Read the codebase to understand the current approach
3. Generate the ADR document
4. Create it in Confluence under the Engineering > ADRs space
5. Link the Confluence page in the PR description

Crear un servidor MCP personalizado

Para sistemas internos sin servidores MCP existentes, puedes crear el tuyo. Aquí tienes un servidor MCP mínimo en TypeScript que expone tu API interna:

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { ListToolsRequestSchema, CallToolRequestSchema } from "@modelcontextprotocol/sdk/types.js";

const server = new Server(
  { name: "internal-api", version: "1.0.0" },
  { capabilities: { tools: {} } }
);

server.setRequestHandler(ListToolsRequestSchema, async () => ({
  tools: [
    {
      name: "get_feature_flags",
      description: "Get the current feature flag configuration for an environment",
      inputSchema: {
        type: "object",
        properties: {
          environment: { type: "string", enum: ["dev", "staging", "prod"] },
        },
        required: ["environment"],
      },
    },
    {
      name: "get_service_status",
      description: "Get the health status of all microservices",
      inputSchema: {
        type: "object",
        properties: {
          service: { type: "string", description: "Service name (optional, all services if omitted)" },
        },
      },
    },
  ],
}));

server.setRequestHandler(CallToolRequestSchema, async (request) => {
  const { name, arguments: args } = request.params;

  if (name === "get_feature_flags") {
    const flags = await fetchFromInternalAPI(`/flags?env=${args.environment}`);
    return { content: [{ type: "text", text: JSON.stringify(flags, null, 2) }] };
  }

  if (name === "get_service_status") {
    const status = await fetchFromInternalAPI(`/health${args.service ? `/${args.service}` : ""}`);
    return { content: [{ type: "text", text: JSON.stringify(status, null, 2) }] };
  }

  throw new Error(`Unknown tool: ${name}`);
});

const transport = new StdioServerTransport();
await server.connect(transport);

Casos de uso reales de MCP en ingeniería

Exploración de bases de datos — Conecta tu base de datos de desarrollo y deja que el modelo inspeccione el esquema real, ejecute planes de consulta y genere migraciones cuya compatibilidad esté garantizada con el estado real de tus datos, no con un diagrama de esquema desactualizado.

Integración con CI/CD — Conecta GitHub Actions o Jenkins. El modelo puede verificar el estado del build, leer los logs de pruebas fallidas, identificar la causa raíz y proponer soluciones, todo sin que tengas que copiar logs en el chat.

Visibilidad entre repos — Un servidor MCP que exponga tu registro de servicios le permite al modelo entender qué servicio es responsable de cada API, dónde está desplegado y quién está de guardia: contexto que no cabe en un solo CLAUDE.md.

Acceso a documentación — Conecta Confluence o Notion. Las skills que generan ADR, RFC o runbooks ahora pueden leer documentos existentes para mantener la consistencia en lugar de alucinar a partir de su memoria.

Observabilidad — Conecta Datadog, Sentry o Grafana. Una sesión de depuración puede comenzar con una traza de error real en lugar de una descripción vaga.

Capa 4: plugins y extensiones

Los plugins son la capa de empaquetado. Toman todo lo de las capas 1–3 —las instrucciones que aportan contexto, las skills reutilizables, las conexiones MCP— y lo agrupan en una unidad que se puede compartir e instalar.

Cómo se ven los plugins hoy

Claude Code aún no tiene un registro formal de plugins, pero el patrón ya existe: un plugin es un directorio o paquete que contiene:

my-engineering-plugin/
  CLAUDE.md              # Grounding instructions for this domain
  .claude/
    commands/
      review-pr.md       # Skills specific to this workflow
      deploy-preview.md
      write-runbook.md
    settings.json        # MCP server declarations
  mcp-servers/
    internal-api/        # Custom MCP server code
      index.ts
      package.json
  README.md

Los equipos lo comparten mediante su registro interno de paquetes o un submódulo de Git. Una persona que se incorpora al equipo ejecuta npm install para instalar el plugin, ejecuta un script de configuración y tiene disponible localmente todo el workflow de IA del equipo: las mismas instrucciones, las mismas skills y las mismas conexiones de datos.

Extensiones de Cursor

Cursor tiene un mecanismo de extensiones más formal mediante su capa de compatibilidad con VS Code, pero el patrón que está surgiendo para compartir a nivel de equipo es el directorio .cursor/ incluido en el repo. Los equipos comparten:

• Reglas en .cursor/rules/ para instrucciones específicas del proyecto
• Notepads para bloques de contexto reutilizables
• Configuración de MCP en .cursor/mcp.json

Un directorio .cursor/ compartido en un monorepo funciona, en la práctica, como un plugin para cada persona del equipo que lo clone.

La ventaja de la distribución

La capa de plugins resuelve un problema organizacional clave: la divergencia de los workflows de IA. Sin empaquetado, cada integrante del equipo hace evolucionar su CLAUDE.md personal y su conjunto de skills de forma independiente. El proceso de revisión de una persona sénior se separa del de una persona junior. Las verificaciones críticas de seguridad se omiten porque no están en el conjunto de skills de todos.

Los plugins convierten la capacidad de IA del equipo en un artefacto versionado y desplegable, igual que cualquier otra pieza de infraestructura.

El panorama completo: un modelo de madurez

Así evoluciona la capacidad de IA de un equipo real a través de estas capas:

Etapa 1 — Contexto personal (semana 1)

Escribes un CLAUDE.md para tu proyecto. Diez líneas. Stack, convenciones, comando de prueba. El modelo deja de preguntarte qué framework de pruebas usas.

Etapa 2 — Alineación del equipo (mes 1)

Los archivos CLAUDE.md individuales del equipo divergen. Los combinas, haces commit de uno en el repo y estableces una base compartida. Ahora el modelo de cada integrante conoce las convenciones del equipo.

Etapa 3 — Extracción de workflows (mes 2–3)

Notas que todos escriben las mismas instrucciones de revisión. Extraes /review-pr. Luego /write-adr. Después /update-changelog. Las skills se convierten en una biblioteca de los procesos repetibles del equipo.

Etapa 4 — Datos en vivo (mes 3–6)

Las skills llegan a su límite: no pueden consultar la base de datos real, publicar en GitHub ni leer Confluence. Conectas servidores MCP para los sistemas que más usas. Las skills se convierten en workflows completos que interactúan con sistemas reales.

Etapa 5 — Distribución empaquetada (mes 6+)

Quieres que los nuevos integrantes del equipo, servicios y repos empiecen con todo configurado. Empaquetas CLAUDE.md + skills + configuraciones MCP en un plugin. Este pasa a formar parte del script de configuración de tu plataforma interna.

Cómo saber cuándo avanzar

Las señales son claras si prestas atención:

Un ejemplo concreto: el workflow de revisión de PR

Así se implementa la misma capacidad de revisión de PR en cada capa:

Capa 1 — Solo system prompt:

# CLAUDE.md
When reviewing PRs, check: types, error handling, test coverage,
service layer patterns, and N+1 queries.

Resultado: el modelo conoce tus estándares. Aún tienes que escribir «revisa este PR» y pegar el diff.

Capa 2a — Se agrega un comando:

# .claude/commands/review-pr.md
Review $ARGUMENTS as a PR. Check:
1. TypeScript types on all new functions
2. try/catch on async operations
3. Test coverage for new code paths
4. Queries only in service layer
5. N+1 query patterns

Format the output as a PR description ready to paste.

Resultado: /review-pr ejecuta toda la lista de verificación. Aún tienes que pegar el diff manualmente.

Capa 2b — Se agrega una skill:

# .claude/skills/review-pr/SKILL.md
---
name: review-pr
description: Reviews pull requests and diffs against team standards. Use when asked to review a PR or code changes.
allowed-tools: Read, Grep, Bash
---

Context:
- PR diff: !`gh pr diff $ARGUMENTS`

Review the diff against team standards (types, error handling, test coverage, service layer, N+1 patterns).
Format the output as a PR description ready to paste.

Resultado: Claude detecta automáticamente las solicitudes de revisión y ejecuta la lista de verificación. La skill obtiene el diff por sí sola, sin copiar y pegar manualmente.

Capa 3 — Se agrega MCP:

La misma skill, pero ahora con GitHub MCP configurado. La skill obtiene el diff del PR por sí sola, revisa los comentarios existentes del PR y publica la revisión directamente en GitHub como una revisión formal con anotaciones por línea.

Resultado: /review-pr 1234 es todo el workflow. Sin copiar y pegar. La revisión aparece en GitHub.

Capa 4 — Plugin:

Toda la configuración —CLAUDE.md, la skill /review-pr, la configuración de GitHub MCP y el servidor MCP para la API interna— se empaqueta e instala mediante npm install @mycompany/engineering-ai-plugin. Cada integrante del equipo la recibe. Todos los repos la tienen.

Resultado: la revisión de PR es una operación de un solo comando para cada integrante del equipo desde el primer día.

Fuentes

• Documentación de Claude Code — Memoria y CLAUDE.md
• Documentación de Claude Code — Skills (comandos con barra diagonal)
• Documentación de Claude Code — Integración de MCP
• Documentación de Claude Code — Hooks
• Model Context Protocol — Introducción
• Model Context Protocol — Arquitectura
• Model Context Protocol — SDK de TypeScript
• Documentación de Cursor IDE — Reglas para IA
• Documentación de Cursor IDE — MCP
• Blog de Anthropic — Presentación de Model Context Protocol
• Especificación de MCP — Repositorio de GitHub
• Claude Agent SDK — Paquete de NPM
• Awesome MCP Servers — Registro de la comunidad