MCP y la Web Semántica: cómo el Model Context Protocol redefine el significado en la web moderna

La Web Semántica intentó enseñar a las máquinas lo que el mundo significa.
El Model Context Protocol está enseñando discretamente a los modelos cómo usar ese significado.

De los sueños de la Web Semántica a la realidad de los LLM

A comienzos de siglo, la Web Semántica prometía una web de datos: documentos anotados con significado legible por máquinas, unidos por estándares como RDF, OWL y SPARQL. Los grafos de conocimiento surgieron de esa idea, convirtiendo texto desordenado en tríos estructurados.

Hoy, lo que ocupa el centro es algo muy distinto: modelos de lenguaje a gran escala (LLMs), envueltos en ecosistemas de herramientas como el Model Context Protocol (MCP). En lugar de incrustar la semántica directamente en los documentos, MCP trata el significado como algo que se accede bajo demanda desde herramientas y repositorios externos.

Ambos movimientos persiguen el mismo premio: un mundo en el que el software pueda entender y actuar sobre la información con la menor fricción posible. Pero parten de direcciones opuestas:

• La Web Semántica:
  “Estructura el mundo y el comportamiento inteligente seguirá.”
• MCP y los ecosistemas LLM:
  “Enseña a los agentes a usar herramientas y la información estructurada será útil cuando haga falta.”

La relación entre ambos ya no es teórica. Los repositorios MCP están empezando a dar acceso a grafos de conocimiento, ontologías y almacenes de datos enlazados. Ese contacto es donde las cosas se ponen interesantes.

Qué es realmente MCP: contexto como interfaz

Tras el ruido, MCP no es nada místico. Es un protocolo para conectar modelos con herramientas y fuentes de datos de forma predecible.

En su núcleo, MCP define:

• Herramientas – operaciones invocables (APIs, scripts, consultas, transformaciones).
• Recursos – superficies de datos que los modelos pueden explorar o recuperar (ficheros, endpoints, subconjuntos de grafos).
• Prompts / plantillas – estructuras de prompt reutilizables que codifican flujos de trabajo, no solo texto.
• Repositorios – colecciones de herramientas, recursos y prompts empaquetadas como una capacidad coherente.

En lugar de cablear APIs directamente en una aplicación, las expones a través de servidores MCP. Un cliente consciente del modelo (editor, agente, IDE, ejecutor de flujos de trabajo) negocia capacidades y luego permite que el modelo llame a esas herramientas según sea necesario.

Ese es el ángulo crucial para la Web Semántica: MCP se convierte cada vez más en el adaptador universal entre los LLM y la infraestructura semántica existente.

La persistencia silenciosa de la Web Semántica

La historia de que “la Web Semántica fracasó” es popular y falsa. Lo que pasó es más sutil: el sueño visible de RDF en todas las páginas se desvaneció, pero la pila subyacente echó raíces profundas en dominios específicos:

• Grafos de conocimiento empresariales y gestión de datos maestros
• Ontologías biomédicas y vocabularios curados
• Patrimonio cultural y metadatos bibliotecarios
• Datos de cumplimiento, legales y regulatorios
• Integración de datos científicos y procedencia

La Web Semántica se transformó en una columna vertebral especializada detrás de escena. Endpoints SPARQL, almacenes RDF y ontologías OWL siguen impulsando sistemas donde la precisión, la auditabilidad y el significado compartido importan más que la velocidad bruta.

Lo que ha cambiado es la interfaz: los usuarios humanos interactúan cada vez menos con estos sistemas mediante editores de consultas y más mediante interfaces en lenguaje natural. Ahí es donde encaja MCP.

MCP como puente hacia los grafos de conocimiento

Imagina que gestionas un gran grafo de conocimiento: productos, clientes, regulaciones o entidades biomédicas. Históricamente, para hacerlo útil tenías que:

• Enseñar a los usuarios SPARQL o distribuir consultas predefinidas
• Envolver el grafo en APIs personalizadas
• Mantener código adaptador frágil entre el grafo y cada aplicación

Con MCP, replanteas el problema:

1. Exponer herramientas de consulta del grafo vía MCP:

   • run_sparql_query
   • lookup_entity_by_label
   • get_neighbors(entity, predicate_filter)

2. Exponer recursos semánticos:

   • Fragmentos de grafo nombrados
   • Módulos de ontología
   • Vistas SPARQL predefinidas como recursos virtuales

3. Enviarlo como un repositorio MCP de grafo de conocimiento que cualquier agente consciente del modelo pueda cargar.

El modelo nunca tiene que “entender RDF” en abstracto. Solo necesita aprender (por patrón y ejemplos) cómo invocar esas herramientas correctamente para responder preguntas. La semántica permanece en el grafo; MCP le da al modelo manos y ojos para usarlas.

En la práctica, esto hace tres cosas:

• Oculta SPARQL detrás del lenguaje natural: el modelo escribe o selecciona consultas en nombre del usuario.
• Unifica interfaces: el mismo repositorio MCP puede hablar con múltiples almacenes de triples o DBs de grafos.
• Soporta adopción gradual: puedes empezar con unas pocas herramientas simples y crecer hacia operaciones semánticas más complejas.

Repositorios MCP como “packs de capacidades” semánticas

El espacio de diseño más interesante hoy no son las herramientas individuales; es cómo las compones en repositorios MCP que encarnan dominios de conocimiento específicos.

Un repositorio MCP enfocado en semántica podría incluir:

• Herramientas de ontología de dominio

  • get_classes_in_domain(domain_id)
  • explain_property(property_uri)
  • validate_instance_against_class(instance_id, class_uri)

• Herramientas de alineación de entidades

  • resolve_to_canonical(entity_alias)
  • map_external_id_to_internal(external_system, id)

• Herramientas de razonamiento y consistencia

  • check_conflicts(entity_id)
  • suggest_new_relations(entity_id) usando reglas o razonadores OWL

• Herramientas de mediación lenguaje natural ↔ URI

  • search_concepts(text_query) que devuelve URIs y puntuaciones
  • render_entity_summary(uri) usando datos del grafo

En lugar de un “backend semántico” monolítico, envías un módulo MCP modular que se puede insertar en varios agentes:

• Un asistente de investigación que necesita respuestas conscientes de la ontología
• Un agente de integración de datos que debe alinear identificadores entre catálogos
• Un bot analista de cumplimiento que necesita razonamiento trazable y explicable

Los repositorios MCP convierten la semántica abstracta en capacidades prácticas.

Por qué los LLM necesitan la infraestructura de la Web Semántica

Es tentador asumir que los LLM sustituirán a la semántica estructurada. No lo harán, por al menos cuatro razones.

1. Precisión y significado formal

Los LLM funcionan con asociaciones difusas. Los activos de la Web Semántica son explícitos:

• Una relación skos:broader transmite una intención distinta a owl:subClassOf.
• Una regulación que se aplica “solo a entidades con tipo de licencia X” no es una intuición; es una condición formal.

MCP permite a un modelo:

• Redactar una respuesta en lenguaje natural
• Llamar a una herramienta semántica para confirmar restricciones o relaciones
• Devolver una respuesta que sea a la vez fluida y fundamentada en significado explícito

2. Trazabilidad y gobernanza

Los sistemas de la Web Semántica están diseñados para trazas de auditoría:

• Procedencia vía prov:wasDerivedFrom
• Vocabularios versionados y términos controlados
• Restricciones OWL que pueden inspeccionarse

En dominios regulados, una explicación tipo “porque el modelo lo dijo” no vale. MCP ayuda mediante:

• Obligar a que el acceso a datos pase por herramientas que puedan registrar consultas y resultados
• Exponer la procedencia como parte de las salidas de las herramientas
• Permitir que los prompts de generación de respuestas integren el “por qué” y “desde dónde” basándose en esa procedencia

3. Interoperabilidad entre sistemas

Los grafos de conocimiento y las ontologías son cómo las grandes organizaciones hacen que sistemas independientes se comuniquen coherentemente. Esquemas de identificadores, mapeos, axiomas de equivalencia: el cableado poco glamuroso de la interoperabilidad.

Los LLM pueden pasar por alto estas distinciones en texto, pero las aplicaciones no pueden. MCP permite:

• Una capa semántica común expuesta una sola vez
• Múltiples agentes e interfaces que reutilizan la misma lógica de mapeo semántico
• Herramientas compartidas para resolución de identidad, mapeo de códigos y normalización de conceptos

4. Longevidad del significado

Los modelos se entrenan con instantáneas; las ontologías y los grafos pueden curarse y mantenerse durante décadas. Estándares como RDF, OWL y SHACL están diseñados para sobrevivir a cualquier generación de modelos.

MCP hace posible conectar nuevos modelos a la misma columna vertebral semántica sin reconfigurar la pila. La semántica se convierte en un sustrato estable bajo un reparto rotativo de LLM.

Dónde MCP cambia la historia de la Web Semántica

Si el optimismo clásico de la Web Semántica imaginaba humanos anotando cuidadosamente páginas con metadatos ricos, MCP introduce una dinámica distinta: modelos que ayudan a producir, consumir y refinar la semántica sobre la marcha.

Se están produciendo varios cambios.

De la anotación manual a la estructuración asistida

La autoría manual de RDF nunca escaló a toda la web. Pero con MCP:

• Un modelo puede leer documentos existentes a través de recursos de fichero MCP.
• Puede llamar a herramientas MCP específicas de dominio para proponer triples RDF o fragmentos JSON-LD.
• Los curadores humanos aprueban, rechazan o editan esas sugerencias mediante flujos editoriales.

Con el tiempo, esto se parece a:

• LLM como borradores semánticos
• Curadores como editores semánticos
• MCP como la pegamento del flujo de trabajo entre texto libre y grafos estructurados

De ontologías estáticas a esquemas negociados

Las ontologías a veces se trataron como verdades impuestas desde arriba. En la práctica, evolucionan mediante negociación entre equipos, proveedores y organismos de estandarización.

Surge aquí un patrón MCP:

• Un “repositorio MCP de ontología” expone los vocabularios y las restricciones actuales.
• Los agentes usan esas herramientas al construir nuevos modelos de datos, formularios y esquemas.
• Cuando aparece fricción (“no tenemos término para esto, pero los equipos siguen inventando uno”), las herramientas MCP pueden señalar huecos del esquema.

Se pasa de “aquí está la ontología, cúmplela” a “aquí está la ontología y aquí cómo su uso nos está empujando contra sus límites.” El protocolo da visibilidad a esa tensión.

De islas de datos a superposiciones semánticas

Muchos datos nunca se migrarán a almacenes de triples. Viven en data warehouses, object stores y silos SaaS. En lugar de forzar la uniformidad, MCP fomenta superposiciones semánticas:

• Herramientas que leen metadatos relacionales
• Mapeos de tablas o campos JSON a conceptos de ontologías
• Vistas RDF generadas al vuelo por consulta

Los LLM orquestan esto: en lugar de pedir “el endpoint SPARQL”, pides “clientes que compraron X y Y en los últimos 90 días y que coinciden con el perfil de riesgo Z”, y el modelo usa herramientas MCP para:

• Descubrir qué sistemas contienen esos datos
• Usar mapeos registrados para alinear términos
• Producir un conjunto de resultados o una representación semántica inicial

La Web Semántica pasa de ser un universo completamente estructurado a una lente interpretativa que se posa sobre sistemas heterogéneos.

_{Photo by Philipp Katzenberger on Unsplash}

Diseñar un repositorio MCP con conciencia semántica

Si estás construyendo repositorios MCP que realmente aprovechen los activos de la Web Semántica, unos cuantos principios de diseño ayudan.

1. Mantén los URIs, oculta la complejidad

Los URIs son las unidades atómicas de la Web Semántica. Exponlos claramente en las entradas y salidas de las herramientas, pero no pidas al usuario que los escriba o memorice.

Patrón:

• Las herramientas devuelven tanto URI como una etiqueta humana.
• El modelo razona con etiquetas, pero usa URIs al invocar herramientas más profundas.
• Cuando los usuarios necesiten ver algo, muestra etiquetas e identificadores cortos, no URIs crudos.

El modelo se convierte en el traductor entre el lenguaje humano y el espacio de URIs.

2. Ofrece consultas tipadas, no solo SPARQL en bruto

Aunque es posible permitir que el modelo escriba SPARQL arbitrario, los patrones más fiables suelen venir de herramientas con plantillas:

• get_drug_interactions(drug_uri)
• list_regulations_applicable_to(entity_uri, jurisdiction_uri)
• get_equivalent_concepts(concept_uri, target_scheme_uri)

Bajo el capó, cada herramienta ejecuta una consulta SPARQL, pero la interfaz es estable y documentada. Siempre puedes exponer una herramienta de “SPARQL en bruto” para usuarios avanzados, pero las herramientas tipadas hacen el sistema manejable y testeable.

3. Trata a los razonadores como herramientas de primera clase

Si usas razonadores OWL o motores de reglas personalizados, expónlos vía MCP:

• run_reasoner_on_entity(entity_uri)
• check_policy_compliance(entity_uri)
• infer_additional_types(entity_uri)

Devuelve tanto:

• Nuevas declaraciones inferidas
• Explicaciones o trazas de reglas cuando estén disponibles

El modelo podrá entonces incorporar este razonamiento formal en respuestas en lenguaje natural e incluso probar hipótesis (“¿y si esta entidad perteneciera a la clase X en lugar de Y?”) llamando a herramientas con parámetros alternativos.

4. Inserta la validación en el flujo de trabajo

Los sistemas semánticos brillan cuando pueden decir “esto no encaja”. Exponlo.

Ejemplos:

• validate_triple(subject_uri, predicate_uri, object_value)
• validate_dataset_against_shape(shape_uri, dataset_id)

Cuando un modelo propone nuevos triples o mapeos, puede llamar inmediatamente a herramientas de validación para detectar conflictos. Ese bucle de retroalimentación es central para construir superposiciones semánticas confiables.

MCP, Linked Data y la pregunta de la apertura

La ambición ética de la Web Semántica fue la apertura: URIs dereferenciables, vocabularios compartidos, datasets enlazados. MCP surgió mayoritariamente de necesidades a nivel de aplicación: conectar este editor con esa herramienta, este IDE con ese servidor.

La tensión es productiva.

• Por un lado, los repositorios MCP pueden ser totalmente privados, envolviendo grafos de conocimiento propietarios.
• Por otro, MCP puede también situarse encima de fuentes de linked data públicas, como Wikidata, DBpedia o bases de conocimiento abiertas específicas de dominio.

Esto plantea preguntas prácticas:

• ¿Queremos repositorios MCP estándar para datasets abiertos de uso general?
• ¿Debería haber herramientas convencionales para lookup_wikidata_entity o map_to_mesh_term?
• ¿Podría MCP convertirse en la capa de interfaz de facto por la cual los agentes recorren la web de datos abierta?

Si eso ocurre, Linked Data ganaría no solo otro método de acceso, sino una capa de interpretación: agentes que puedan mezclar semánticas públicas y privadas respetando los límites.

Riesgos en la intersección

Donde hay convergencia, también hay puntos de fractura.

Deriva semántica por “correcciones” de los LLM

Los LLM son buenos para “arreglar” cosas que parecen inconsistentes. Ese instinto es útil para borradores, peligroso para la semántica formal. Si un modelo decide que una ontología “está mal” y trata de autocorregirla, puede:

• Proponer relaciones que violen restricciones previstas
• Empujar conceptos de dominio hacia el uso del lenguaje cotidiano
• Introducir desalineaciones silenciosas entre significado formal e informal

MCP debe por tanto soportar:

• Pasarelas de revisión explícitas para cambios semánticos
• Flujos de trabajo humano-en-bucle para ediciones de ontologías
• Registro y diff de cualquier actualización propuesta por el modelo

Dependencia excesiva en contexto difuso

El objetivo de MCP es reducir las alucinaciones apoyando a los modelos en herramientas y datos. Pero si solo expones semánticas parciales —algunos vocabularios, algunas reglas— los modelos pueden rellenar huecos con conjeturas plausibles.

Mitigaciones:

• Herramientas que respondan “no lo sé” explícitamente cuando faltan datos
• Metadatos a nivel MCP que describan la cobertura y los límites de cada repositorio
• Patrones donde los modelos consultan varias fuentes antes de comprometerse con una respuesta

Mini-ontologías fragmentadas

Si cada repositorio MCP inventa su propio esquema reducido en aislamiento, corres el riesgo de un mundo de mini-ontologías incoherentes, comprensibles solo dentro de su propio agente.

La lección dura de la Web Semántica es que los vocabularios compartidos importan. Reutilizar ontologías y mapeos existentes, aunque no sean perfectos, es mejor que reinventar constantemente. Los implementadores MCP deberán:

• Preferir vocabularios establecidos cuando sea posible
• Documentar términos personalizados con claridad
• Ofrecer herramientas de mapeo entre sus esquemas locales y los públicos

Cómo podrían ser los próximos años

La relación entre MCP y la Web Semántica aún se está formando, pero hay algunas trayectorias probables.

Herramientas semánticas como ingrediente por defecto

Veremos:

• Repositorios MCP genéricos para operaciones semánticas comunes: resolución de entidades, navegación de taxonomías, operaciones RDF simples.
• Packs específicos de dominio que envuelvan ontologías principales (p. ej., biomédico, instrumentos financieros, códigos geoespaciales).
• Agentes que vengan “preconectados” para entender al menos un puñado de vocabularios compartidos.

Cuantos más existan, más fácil será para los constructores de aplicaciones añadir profundidad semántica sin reimplementar la pila.

Grafos de conocimiento como backends de agentes

Los grafos de conocimiento pasarán de estar ocultos tras paneles analíticos a ser el backend de agentes inteligentes. En ese modelo:

• MCP es la capa de alineación entre LLM y almacenes de grafos.
• Las consultas semánticas forman parte de las interacciones cotidianas por chat.
• Las actualizaciones del grafo pueden ser redactadas colaborativamente por humanos y modelos, con validación intermedia.

La Web Semántica deja de ser solo una historia de integración de datos y se convierte en una historia de interacción.

Las ontologías evolucionan con retroalimentación observacional

Los datos de uso de llamadas MCP mostrarán dónde las ontologías son frágiles o incompletas:

• Necesidad recurrente de sinónimos que no figuran en los vocabularios
• Conceptos “fuera de ontología” que surgen en consultas en lenguaje natural
• Conflictos entre el modelo mental del usuario y jerarquías formales

Las ontologías pueden adaptarse mediante:

• Introducción de términos nuevos que coincidan con el lenguaje observado
• Añadir crosswalks entre clasificaciones incompatibles pero necesarias en la práctica
• Reestructurar áreas que confunden de forma consistente a usuarios y modelos

MCP se convierte en una red de sensores para la fricción semántica.

Una Web Semántica distinta

En retrospectiva, la Web Semántica intentó ordenar lógicamente el mundo antes de que éste lo pidiera. MCP y los ecosistemas de LLM aceptan el caos y trabajan hacia afuera desde el uso:

• Mantén la semántica donde importa.
• Deja que las herramientas la expongan como capacidades.
• Enseña a los modelos a apoyarse en esas capacidades en lugar de improvisar.

El resultado no es la visión original de una web uniformemente anotada. Es algo más orgánico: bolsillos de significado altamente estructurado que emergen a través de un protocolo construido para agentes, no para humanos que miran RDF en el código fuente de una página.

Si eso llega a ser la nueva normalidad depende menos de la brillantez de los estándares y más de si la gente encuentra estas combinaciones realmente útiles. Por ahora, una cosa está clara: si el significado en la web es una negociación en evolución entre formalidad y lenguaje, MCP acaba de sentarse a la mesa de negociación.

External Links

The Semantic Web Project Didn’t Fail — It Was Waiting for AI (The … MCP Servers and the Semantic Layer Gap: What Data Teams Need … MCP is the coming of Web 2.0 2.0 - Hacker News MCP (Model Context Protocol): The Future of AI Integration - Digidop 1. Direct API Wrapper Pattern Agents interact …