Convertí mi sitio personal en una fuente de contexto para agentes

La mayoría de los sitios personales siguen diseñados para un tipo de visita:

Alguien llega al inicio, recorre unas páginas, revisa el trabajo y decide si la persona le inspira confianza.

Eso sigue importando, pero ya hay otras formas de descubrir el trabajo de alguien.

Cada vez más evaluaciones pasan por herramientas: búsquedas con IA, agentes de programación, sistemas internos de reclutamiento, asistentes del navegador, bots de vistas previas y personas que le piden a un LLM que resuma a alguien antes de contactarlo.

Por eso empecé a tratar mi sitio personal como una fuente de contexto que también pudieran consultar los agentes.

Qué significa eso

El sitio expone dos puntos de entrada estructurados:

• GET /api/v1/* para clientes HTTP convencionales;
• POST /api/mcp para agentes compatibles con MCP.

El objetivo es facilitar que inspeccionen mi trabajo sin obligar a cada cliente a extraerlo del HTML.

La API pública expone:

• GET /api/v1/me;
• GET /api/v1/projects;
• GET /api/v1/projects/:slug;
• GET /api/v1/products;
• GET /api/v1/products/:slug;
• GET /api/v1/notes;
• GET /api/v1/notes/:slug.

El servidor MCP ofrece herramientas para los mismos objetos principales:

• get_orlando_bio;
• get_projects;
• get_project;
• get_products;
• get_product;
• get_product_status;
• get_notes;
• get_note.

Las personas y los agentes pueden consultar una fuente de verdad compartida.

Por qué lo construí

La primera razón es práctica: mi sitio ya tiene contenido estructurado.

Los proyectos, productos y notas tienen modelos de contenido con frontmatter, slugs, descripciones, etiquetas, capturas y enlaces. Me parecía desaprovechar esos datos usarlos solo para renderizar páginas cuando también podía servirlos como JSON.

La segunda razón es estratégica: cada vez descubrimos más cosas a través de intermediarios.

Un reclutador quizá no lea cinco páginas del sitio. Puede pedirle a un asistente: «Resume el trabajo de este desarrollador». Un fundador puede pedirle a un agente: «Encuentra personas que hayan publicado extensiones de Chrome y herramientas de IA». Un desarrollador puede incorporar la API a su propio flujo de búsqueda.

Una API clara permite que esas herramientas consulten y citen hechos estructurados en vez de deducirlos del HTML.

Cómo está diseñada la API

La diseñé alrededor de garantías pequeñas y conocidas:

• todas las respuestas correctas tienen una estructura previsible;
• los endpoints de colecciones permiten paginar;
• el contenido público puede filtrarse por tema, etiqueta, estado, destacado e idioma cuando corresponde;
• las respuestas incluyen ai_summary, una interpretación en inglés junto a los datos originales;
• las cabeceras hacen explícitos los límites de peticiones;
• CORS está habilitado para las lecturas públicas sencillas.

El campo ai_summary es el detalle que más me gusta.

Una API convencional está pensada para software. Una API que van a leer agentes también debería facilitar la interpretación. El resumen les ayuda a entender qué recibieron sin tener que deducirlo todo de campos aislados.

La capa de MCP

El endpoint MCP existe para que un agente que trabaja con herramientas no tenga que pensar en URL.

El servidor describe las herramientas disponibles:

get_projects({ tag?: string, status?: "active" | "archive", locale?: string })
get_product({ slug: string, locale?: string })
get_notes({ topic?: string })

Los nombres expresan qué puede hacer cada herramienta. Eso encaja mejor con este tipo de interacción que pedirle al agente que elija un endpoint por su cuenta.

El mismo contenido que alimenta el sitio sirve ahora a:

• búsquedas;
• consumidores de la API;
• agentes de IA;
• clientes MCP;
• futuras automatizaciones.

Qué muestra esto en un sitio personal

Esta decisión muestra algo de cómo construyo:

• me importan los datos estructurados;
• pienso en cómo se descubre el trabajo;
• diseño para interfaces futuras además de las pantallas actuales;
• prefiero que los sistemas se puedan inspeccionar, en lugar de ocultarlo todo detrás de la presentación.

Un sitio personal debería mostrar criterio y cuidado. Añadir una API y un servidor MCP es una forma pequeña de hacerlo.

La idea de fondo

Los sitios personales están convirtiéndose en interfaces para los datos de una persona. El inicio sirve a quienes navegan, la API al software y el servidor MCP a los agentes. Juntos facilitan encontrar, entender, reutilizar y verificar el mismo trabajo.

Quiero que mi sitio avance en esa dirección: que evolucione como un producto que se puede consultar, además de presentar mi experiencia.