I Turned My Personal Hub Into an Agent-Readable Surface

Product thinking3 min read

A personal site should not only be browsed by people. It should also be legible to the tools people use to discover, evaluate, and remember work.

Most personal sites are still designed for one visitor pattern:

Someone lands on the homepage, clicks through a few pages, scans the work, and decides whether the person seems credible.

That still matters. But it is no longer the only way people discover work.

More and more evaluation happens through tools: AI search, coding agents, recruiters using internal systems, browser assistants, link preview bots, and people asking an LLM to summarize someone before reaching out.

So I started treating my personal hub as more than a website. I turned it into an agent-readable surface.

What that means

The site now exposes two structured entry points:

  • GET /api/v1/* for normal HTTP clients
  • POST /api/mcp for MCP-compatible agents

The goal is simple: make my work easy to inspect without forcing every client to scrape HTML.

The public API exposes:

  • 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

The MCP server exposes tools for the same core objects:

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

That gives both humans and agents a shared source of truth.

Why I built it

The first reason is practical: my site already has structured content.

Projects, products, and notes live as content models. Each has frontmatter, slugs, descriptions, tags, screenshots, and links. It felt wasteful to only render that data into pages when it could also be served as JSON.

The second reason is strategic: the internet is becoming more mediated.

A recruiter might not read five pages on the site. They might ask an assistant, "Summarize this developer's work." A founder might ask an agent, "Find builders who have shipped Chrome extensions and AI tools." A developer might pipe the public API into their own discovery workflow.

If the site is only HTML, those tools guess.

If the site has a clean API, they can cite structured facts.

The shape of the API

I designed the API around small, boring guarantees:

  • Every successful response uses a predictable envelope
  • Collection endpoints support pagination
  • Public content can be filtered by topic, tag, status, featured state, and locale where appropriate
  • Responses include an ai_summary field so agents get a plain-English interpretation alongside raw data
  • Rate-limit headers make usage constraints explicit
  • CORS is enabled for simple public reads

The ai_summary field is the detail I like most.

A normal API response optimizes for software. An agent-readable API should also optimize for interpretation. The summary helps downstream tools understand what came back without needing to infer everything from raw fields.

The MCP layer

The MCP endpoint exists because agents should not have to think in URLs if they are working in a tool-calling environment.

Instead of making an agent decide which endpoint to call, the MCP server describes available tools:

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

That is a better interaction model for AI systems. The tools are named by intent, not transport.

The same content that powers the site now powers:

  • search
  • API consumers
  • AI agents
  • MCP clients
  • future automations

Why this belongs on a personal hub

This is not just a technical flourish.

It says something about how I build:

  • I care about structured data
  • I think about distribution
  • I design for future interfaces, not only current screens
  • I prefer making systems inspectable instead of hiding everything behind presentation

A personal hub should prove taste. It should also prove judgment.

Adding an API and MCP server is a small way to show both.

The bigger idea

Personal websites are becoming personal data interfaces.

The homepage is for humans.

The API is for software.

The MCP server is for agents.

Together, they make the same body of work easier to find, understand, reuse, and trust.

That is the direction I want my personal hub to move in: less static resume, more living product surface.

Notes from the build

Get more AI engineering insights

Follow the work: AI tools, browser products, product decisions, and honest lessons from the build.

By subscribing, you agree to receive Orlando's emails. No spam. Unsubscribe anytime.

I Turned My Personal Hub Into an Agent-Readable Surface | Orlando Ascanio