Content Kit: Personal Hub MCP and Public API

Systems design3 min read

A technical launch is easier to distribute when the story, snippets, and proof points are already packaged.

This is a working content kit for the MCP server and public API behind my personal hub.

The canonical idea:

I turned my personal hub into an agent-readable surface. Humans can browse the website. Software can use the API. AI agents can call the MCP server.

Core positioning

Short version:

My personal hub now has a public API and MCP server so people, scripts, and AI agents can inspect my work without scraping pages.

Sharper version:

The homepage is for humans. The API is for software. The MCP server is for agents.

Technical version:

I exposed my projects, products, notes, and profile through a versioned Next.js API and a remote MCP endpoint with tool calls for agent workflows.

LinkedIn post 1: builder story

I made a small upgrade to my personal hub that feels bigger than it looks:

It now has a public API and MCP server.

The website is still for humans. You can browse projects, products, notes, and case studies like a normal personal site.

But now software can read the same work too:

  • GET /api/v1/me
  • GET /api/v1/projects
  • GET /api/v1/products
  • GET /api/v1/notes
  • POST /api/mcp

Why?

Because more discovery is happening through tools.

Someone might ask an AI assistant to summarize my work. A recruiter might use an internal system. A developer might want structured project data. An agent might need to inspect what I have shipped.

I do not want those systems scraping HTML and guessing.

I want them reading structured context.

The homepage is for humans. The API is for software. The MCP server is for agents.

That feels like the direction personal sites are heading: not static resumes, but living surfaces that can be browsed, queried, and reused.

LinkedIn post 2: technical lesson

Most personal sites are optimized for screenshots.

I am trying to optimize mine for context.

I added a public API to expose my profile, products, projects, and notes as structured JSON. Each response includes:

  • versioned envelope
  • metadata
  • rate-limit headers
  • localized fields where useful
  • an ai_summary field for agent-readable interpretation

That last field is the interesting one.

Normal APIs assume the consumer is deterministic software.

Agent-facing APIs also need to help the model understand what came back.

Raw JSON says what exists.

A short summary explains what matters.

Small example:

Found 3 products. Statuses: active, in_development. Each product includes tagline, metric, tech_stack, and direct external_link.

That is not complicated. It is just useful.

I think more personal websites, docs, and product pages will move this way: human-readable pages with structured, agent-readable surfaces underneath.

X thread

1/ I turned my personal hub into an agent-readable surface.

Humans can browse the website. Software can use the API. AI agents can call the MCP server.

2/ The public API exposes the core objects behind the site:

  • profile
  • projects
  • products
  • notes

No scraping. No guessing from layout. Just structured context.

3/ The endpoints are intentionally boring:

GET /api/v1/me GET /api/v1/projects GET /api/v1/products GET /api/v1/notes

Boring is good here. If a tool needs context, it should be predictable.

4/ The part I like most: every response includes an ai_summary.

That means clients get both raw data and a plain-English interpretation of what the response contains.

Useful for agents. Useful for humans debugging too.

5/ I also added a remote MCP endpoint:

POST /api/mcp

Instead of making agents think in URLs, they can call tools like get_projects, get_product, get_notes, and get_orlando_bio.

6/ The bigger idea:

Your homepage is not the only interface to your work anymore.

Some visitors will be people. Some will be scripts. Some will be AI agents.

Design for all three.

Short posts

Tiny personal hub upgrade:

I added a public API and MCP server.

The site is no longer just a page people can browse. It is a structured surface software and AI agents can query.

The homepage is for humans.
The API is for software.
The MCP server is for agents.

That is the new shape of my personal hub.

If an AI agent is going to summarize my work, I would rather give it structured context than make it scrape HTML and guess.

So I added `/api/v1` and `/api/mcp` to my personal hub.

Newsletter angle

Subject options:

  • I made my personal hub readable by AI agents
  • The personal hub is becoming a product surface
  • Humans browse pages. Agents call tools.

Opening:

This week I made my personal hub a little less like a static resume and a little more like infrastructure.

It now exposes my profile, projects, products, and notes through a public API and remote MCP server.

Main point:

The reason is not novelty. The reason is distribution.

More people are going to discover builders through mediated interfaces: AI search, assistants, internal recruiting tools, coding agents, and custom workflows.

If those systems are going to read my work, I want them to read structured context instead of guessing from rendered pages.

CTA:

Try the API, inspect the MCP endpoint, or send me a note if you are building agent-readable surfaces too.

Demo prompts

Use these prompts when showing the MCP/API work in a video or live demo:

Use Orlando's personal hub MCP server to summarize his active products and explain which one is most relevant for developers struggling with focus.

Call the public API and list projects tagged with AI. For each project, include the problem, tech stack, and why it matters.

Fetch Orlando's latest notes and group them by theme: AI engineering, Chrome extensions, product thinking, and systems design.

Use the public API to create a recruiter brief about Orlando's experience with Next.js, Chrome extensions, and AI product development.

Proof points to repeat

  • The API is versioned as 1.0.0
  • Public read endpoints use consistent JSON envelopes
  • Responses include ai_summary for model-readable context
  • Projects and products support tag/status filters
  • Notes support topic/category filters
  • The MCP server exposes intent-named tools over the same content
  • Rate limits are explicit through response headers
  • The site remains human-readable first

Visual ideas

  • Split screen: site page on the left, JSON response on the right
  • Short terminal demo calling /api/v1/me
  • MCP client listing tools from the personal hub MCP server
  • Diagram with three interfaces: Human -> Website, Software -> API, Agent -> MCP
  • Before/after: "site as pages" vs "site as queryable context"

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.

Content Kit: Personal Hub MCP and Public API | Orlando Ascanio