Saltar al contenido

El futuro de los sitios personales también pasa por las APIs

Tu sitio debería poder consultarse desde software, además de visitarse.

Decisiones de producto3 min de lectura

Ingeniero de software. Desarrollo extensiones de Chrome, aplicaciones web y herramientas de IA aplicada.

Contenido

Creo que los sitios personales evolucionan hacia algo que se puede consultar desde software, además de visitar.

Durante años, su estructura habitual fue:

  • Inicio.
  • Acerca de mí.
  • Proyectos.
  • Escritura.
  • Contacto.

Sigue siendo útil. Mi propuesta es añadir una base estructurada que también entiendan el software y los agentes de IA.

El sitio personal pensado para visitantes

Una persona abre un enlace, recorre el inicio, consulta un proyecto, quizá lee una nota y contacta.

Ese recorrido sigue necesitando:

  • Posicionamiento claro.
  • Buena escritura.
  • Jerarquía visual.
  • Pruebas del trabajo.
  • Formas de contacto.

Pero hay otras interfaces de descubrimiento:

  • Asistentes y buscadores de IA.
  • Herramientas de selección de personal.
  • Agentes de programación.
  • Vistas previas en redes.
  • Índices de búsqueda.
  • Bases de datos internas.
  • Scripts propios.
  • Agentes que usan navegadores.

Esos sistemas no recorren el sitio como una persona. Una estructura explícita puede ayudarles.

Una web con más de una interfaz

La web conserva sus páginas y añade, cuando corresponde:

  • Datos estructurados.
  • Endpoints públicos.
  • Herramientas MCP.
  • Documentación.
  • Ejemplos.
  • Identidad legible por máquinas.

El inicio, la API y el servidor MCP son interfaces distintas sobre el mismo trabajo. Mantener una base común ayuda a que no se contradigan.

Cuándo conviene ofrecer algo más que HTML

HTML es excelente para documentos. Pero una herramienta puede querer responder consultas como estas, conservadas en su forma original:

What products has this person shipped?

O esta:

Which projects use TypeScript?

O esta otra:

Summarize this person's work for a recruiter.

En estos ejemplos se busca identificar proyectos, notas o productos con características concretas. Extraerlo de la presentación obliga a inferir parte de la estructura.

Una interfaz estructurada permite pedir directamente:

GET /api/v1/products
GET /api/v1/projects?tag=typescript
GET /api/v1/me

Ese contrato es más explícito que deducir campos a partir de tarjetas y títulos.

La identidad personal como datos consultables

Un sitio ya cuenta quién eres, qué haces, qué construiste, qué ideas tienes y dónde contactarte.

La misma información puede tener una representación para software:

  • Perfil.
  • Habilidades.
  • Proyectos.
  • Productos.
  • Notas.
  • Enlaces.
  • Estado.
  • Etiquetas.
  • Tecnologías.

Eso puede reforzar la web para personas sin sustituirla.

Dónde encaja MCP

Una API permite consultar el sitio desde software. MCP puede presentar esas capacidades como herramientas disponibles para un agente.

Un programa suele conocer el endpoint que necesita. Un agente puede empezar con una tarea en lenguaje natural, como la del ejemplo original:

Find Orlando's strongest projects for an AI engineering role.

Para resolver ese proceso, el servidor puede exponer herramientas como:

get_projects
get_products
get_notes
get_orlando_bio

El agente elige las herramientas, reúne contexto y redacta una respuesta. Dispone de una forma explícita de consultar en lugar de depender solo de extraer páginas.

Qué puede demostrar sobre quien construye

Muchos portafolios ofrecen un mensaje como este:

Here is my work.

Una base estructurada permite responder con más detalle:

What work matters here, and why?

Puede mostrar cómo piensas sobre:

  • Sistemas.
  • Modelado de datos.
  • Diseño de APIs.
  • Interfaces para agentes.
  • Decisiones de producto.
  • Distribución del contenido.

El propio sitio se convierte en una muestra de esas decisiones.

La estructura que imagino

La organización podría parecerse a esta:

/             human homepage
/about        human profile
/work         human project browsing
/notes        human writing
/api          developer documentation
/api/v1/*     structured public data
/api/mcp      agent-readable tool surface

No todo el mundo necesita un backend complejo. Para algunos bastan archivos JSON; para otros, endpoints REST o un servidor MCP. El principio es exponer contexto público estructurado más allá de la página.

Una web que participa en procesos

Una herramienta de selección puede resumir tu trabajo. Un asistente puede responder sobre tus productos. Un buscador puede clasificar tus notas y un agente de programación puede consultar tus proyectos públicos.

El sitio pasa a participar en esos procesos, además de esperar visitas.

Mi propuesta

Construye las páginas para personas y ofrece el mismo trabajo con una estructura que el software pueda consultar: proyectos verificables, identidad pública y contexto con un contrato claro.

Un pequeño voto de confianza

¿Valió la pena leer esta nota?