El modelo de datos de mi sitio personal

Pensar en mi sitio personal como un modelo de datos facilitó convertirlo en una API y un servidor MCP.

Si el sitio solo contiene páginas, cada integración empieza por el HTML renderizado. Con datos estructurados, todas las interfaces pueden reutilizar la misma fuente de verdad. El inicio es una vista, la API es otra y el servidor MCP es otra. El modelo de datos las mantiene alineadas.

Perfil

La entidad de perfil responde:

Who is Orlando?

Es decir: ¿quién es Orlando?

Incluye:

• nombre;
• nombre de usuario;
• rol;
• ubicación;
• frase de presentación;
• biografía;
• enfoque actual;
• habilidades;
• enlaces.

Alimenta el endpoint /api/v1/me y la herramienta MCP get_orlando_bio.

El perfil tiene suficiente estructura para que una herramienta entienda:

• qué hago;
• dónde estoy;
• en qué me estoy centrando;
• dónde encontrarme;
• cómo resumir mi perfil.

Ese contexto suele ser lo primero que necesita un asistente de IA.

Proyecto

La entidad de proyecto responde:

What has Orlando built on his personal hub?

La pregunta es qué he construido y muestro en mi sitio.

Sus campos incluyen:

• título;
• año;
• slug;
• descripción;
• resumen;
• por qué importa;
• etiquetas;
• tecnologías;
• captura;
• enlace externo;
• enlace de GitHub;
• estado.

El campo más importante es why_it_matters.

Muchos sitios enumeran lo que se construyó. Menos sitios explican por qué importaba hacerlo.

Ese campo aporta contexto a las personas y a los agentes:

• qué problema aborda el proyecto;
• por qué valía la pena construirlo;
• qué criterio demuestra.

Para que un agente entienda el trabajo, la motivación importa tanto como la implementación.

Producto

La entidad de producto responde:

What has Orlando shipped for users?

Es decir: ¿qué he publicado para que lo usen otras personas?

Los proyectos muestran capacidad. Los productos muestran criterio de producto.

Un producto incluye:

• título;
• año;
• slug;
• frase de presentación;
• descripción;
• resumen;
• métrica;
• público;
• punto de comparación;
• etiquetas;
• tecnologías;
• captura;
• enlace externo;
• indicador de destacado;
• estado.

Un proyecto puede ser un caso de estudio. Un producto está presentado para sus usuarios. Por eso necesita campos como la frase de presentación, la métrica, el público y el estado: explican su adopción, su posicionamiento y a quién quiere servir.

Nota

La entidad de nota responde:

What does Orlando think about?

La pregunta es sobre qué pienso y escribo.

Las notas incluyen:

• título;
• categoría;
• idea principal;
• resumen;
• descripción;
• palabras clave;
• fecha de publicación;
• slug;
• contenido;
• imagen.

El campo insight_line hace explícita la idea de la nota. Sirve para la página de notas, los metadatos, los consumidores de la API y los agentes que deciden si un texto responde a la petición del usuario.

En este modelo, lo que escribo también muestra cómo razono.

Habilidades

Las habilidades forman parte del perfil y también sirven para encontrar trabajo relacionado.

Por ejemplo:

• TypeScript;
• React;
• Next.js;
• Python;
• integración de IA y LLM;
• extensiones de Chrome.

Responden:

What can Orlando work with?

Es decir: ¿con qué puede trabajar Orlando?

Las personas pueden revisar la lista rápidamente. Los agentes pueden buscar coincidencias con un requisito.

Un asistente de reclutamiento podría preguntar:

Does this developer have experience with Next.js and AI products?

La lista ayuda a responder directamente si tengo experiencia con Next.js y productos de IA.

Enlaces

Los enlaces conectan el sitio con el resto de internet.

Entre los campos útiles están:

• sitio personal;
• GitHub;
• correo;
• documentación de la API;
• enlaces externos a productos;
• enlaces a proyectos.

Parecen simples, pero forman parte de cómo se verifica la información.

Un enlace estructurado le dice a una herramienta:

• dónde está el sitio canónico;
• dónde puede encontrar código;
• cómo contactarme;
• dónde probar un producto;
• qué URL debe citar.

Si los enlaces solo aparecen dentro de párrafos, el agente tiene que extraerlos. Si están estructurados, puede usarlos directamente.

Estados

Los campos de estado explican el ciclo de vida.

Para los proyectos, son útiles:

• activo (active);
• archivado (archive).

Para los productos, las opciones son más amplias:

• activo;
• beta pública;
• en desarrollo;
• pendiente de revisión;
• archivado.

No todo el trabajo debe interpretarse igual. Un experimento archivado no es un producto actual. Un producto activo puede seguir evolucionando. Un producto en desarrollo no debería describirse como ya lanzado. Los agentes necesitan ese contexto para no exagerar su disponibilidad.

Etiquetas

Las etiquetas responden:

What themes does this belong to?

Es decir: ¿con qué temas se relaciona este trabajo?

Por ejemplo:

• IA;
• productividad;
• extensión de Chrome;
• concentración;
• API;
• diseño de sistemas.

Las etiquetas permiten:

• filtrar;
• buscar;
• agrupar contenido;
• recomendar;
• recuperar información desde un agente.

Deben servir para encontrar algo. Si cada elemento lleva diez etiquetas vagas, dejan de ayudar. Las buenas etiquetas reflejan cómo una persona buscaría o preguntaría por ese trabajo.

Tecnologías

La lista de tecnologías responde:

What was this built with?

Es decir: ¿con qué se construyó?

Por ejemplo:

• Next.js;
• TypeScript;
• React;
• Python;
• Manifest V3 de extensiones de Chrome;
• chrome.storage.local;
• MCP.

Este campo es útil para la evaluación técnica. Una persona puede revisarlo rápidamente, un consumidor de la API puede filtrarlo o mostrarlo y un agente puede responder preguntas como:

Which projects demonstrate TypeScript experience?

La pregunta pide identificar qué proyectos demuestran experiencia con TypeScript. Estructurar las tecnologías permite responder sin tener que buscarlas dentro de párrafos.

El modelo que comparten las interfaces

Una vez que existe el modelo de datos, resulta más fácil construir las interfaces. La web lo convierte en páginas, la API lo devuelve como JSON y el servidor MCP lo envuelve en herramientas que un agente puede llamar.

Ese es el principio de diseño del sitio:

Model the work once. Expose it through the right interfaces.

Modela el trabajo una sola vez y ofrécelo mediante las interfaces adecuadas.

Lo que deja espacio para evolucionar es que la API, el servidor MCP y la web parten de la misma representación estructurada del trabajo.