---
title: "Making Your Blog Readable by AI Agents: AIO with llms.txt and MCP Server"
description: "Making a personal blog discoverable by AI agents as Perplexity and ChatGPT replace traditional search. Implementation of AIO (AI Optimization) with llms.txt, JSON API, and MCP Server design—decision criteria for a 46-post blog."
lang: "en"
canonical: "https://llm-lab.dev/en/posts/blog-aio-llms-mcp/"
source: "https://llm-lab.dev/en/posts/blog-aio-llms-mcp.md"
publishedAt: "2026-06-29"
updatedAt: "2026-06-29"
category: "LLMOps"
tags:
  - "llmops"
  - "llms-txt"
  - "mcp"
  - "agent"
  - "seo"
  - "astro"
---

# Making Your Blog Readable by AI Agents: AIO with llms.txt and MCP Server

I recently noticed that the way I look for information has changed. When I have a technical question, I no longer open Google first. Instead, I ask Perplexity, Claude Code, or ChatGPT. This is not just a personal habit—it is a sign that the entry point for search is shifting from "search engines" to "AI agents."

That raised a question. How does my blog look from an AI agent's perspective?

## Human-oriented SEO is done. AI-oriented is not

I have been running this blog on Astro since 2024, publishing 46 posts in both Japanese and English. I thought I had covered the basics of SEO for human readers.

I introduced Pagefind for full-text search, indexing 92 pages across both languages. For multilingual support, I set up hreflang, canonical URLs, JSON-LD BreadcrumbList, and OGP so Google can index the site correctly. Each post has a table of contents, previous/next navigation, and copy buttons for code blocks.

But all of these are optimizations for humans browsing the web. If an AI agent visits this site, those 46 posts are just a pile of fragmented HTML. Pagefind's search UI is for humans; AI needs a programmatic interface.

AI agents want to quickly grasp the site's structure and mechanically understand "what is written in which post." For that, they need a structured overview and programmatically accessible metadata—not HTML.

## Three-layer AIO (AI Optimization) design

To address this, I designed a three-layer AIO approach.

- **Layer 1**: llms.txt — An AI-oriented site overview file
- **Layer 2**: JSON API — A machine-readable endpoint for post metadata
- **Layer 3**: MCP Server — Standardized tool calls from AI agents

Each layer serves a different granularity: "conveying overview," "providing data," and "acting as a tool." They are not all mandatory, but Layers 1 and 2 offer high impact with minimal implementation cost.

## Layer 1: The decision to adopt llms.txt

llms.txt is a rapidly spreading standard for AI-oriented site overview files since 2024, defined at llmstxt.org. It includes the site name, overview, main sections, and contact information in plain text.

The first thing I hesitated about was "how mechanical should it be?" There are proposals to follow strict formats like whatwg/fetch, but the essence of llms.txt is "human-readable plain text." I decided that being AI-friendly and being maintainable by humans should go hand in hand, so I adopted a markdown-flavored text format.

I placed the implementation in `src/pages/llms.txt.ts` as an Astro endpoint. Instead of a standalone script, I made it part of the Astro build so that the latest post list and category counts are fetched automatically at build time. Updating the text manually every time a new post is published would not scale.

The content includes:

- Site name and overview (both Japanese and English)
- Main categories and post counts (13 categories)
- Top 15 popular posts with titles and URLs
- Series list (Langfuse Morning Briefing, Vercel Eve Intro, Flue Practical Guide)
- Markdown export instructions
- License and contact information

> Honestly, I was unsure whether to include all of this at first. But when I considered the goal of "helping AI correctly understand the scope of this site," I concluded that including too much is less problematic than including too little.

## Layer 2: JSON API design decisions

For Layer 2, I created `/api/articles.json` to expose metadata for all 46 posts in JSON format.

The first design question was whether GraphQL was necessary. My conclusion: at 46 posts, GraphQL is overkill. Plain REST with full-list return is sufficient, and simplicity benefits maintainability. When the post count exceeds 500, I can add query parameters like `?limit=` or `?category=`.

The JSON structure is Japanese-post-centric with English paired alongside. For Japanese-English pairing, I use `translationKey` (or fallback to `permalink`) to correctly map different-language versions of the same post.

```json
{
  "title": "APIで最小ループを組むと...",
  "titleEn": "When You Build a Minimal API Loop...",
  "slug": "llm-loop-engineering-minimal-api",
  "url": "https://llm-lab.dev/posts/llm-loop-engineering-minimal-api/",
  "urlEn": "https://llm-lab.dev/en/posts/llm-loop-engineering-minimal-api/",
  "date": "2026-06-28",
  "category": "設計",
  "categoryEn": "Design",
  "tags": ["llmops", "eval", "loop-engineering", "aidd"],
  "description": "...",
  "series": null,
  "seriesOrder": null
}
```

For CORS, I set `Access-Control-Allow-Origin: *`. This is public data with no authentication required, so there is no reason to restrict cross-origin access.

## Layer 3: MCP Server design

Layer 3 is currently at the design stage rather than implementation. MCP (Model Context Protocol) is a standard protocol proposed by Anthropic for connecting AI agents with external tools.

MCP has two transport layers: stdio (standard input/output, for local connections) and SSE over HTTP (Server-Sent Events, for remote connections). Since I am providing blog post information as a public API, stdio—which is confined to local connections—is inappropriate. I chose SSE over HTTP for accessibility from anywhere.

For infrastructure, I recommend Cloudflare Workers. It operates within the same Cloudflare ecosystem as the site, offers edge deployment for low latency, and has a generous free tier (100,000 requests/day). For 46 posts, in-memory search yields sub-millisecond latency.

I designed five tools:

- `search_articles`: Search by keyword, category, tag, series, or language
- `get_article`: Individual post metadata by slug
- `list_categories`: Category list with Japanese/English labels
- `list_tags`: Tag list with post counts
- `list_series`: Series list with ordered post lists

The detailed design is documented in `docs/mcp-design.md`, ready for Phase 3 implementation.

## Verification and findings

After implementation, `npm run build` completed with 0 errors, 0 warnings, and 0 hints. I confirmed that both `dist/llms.txt` and `dist/api/articles.json` were generated.

A finding was the discrepancy in post counts. The total post count is 49, but the JSON API only contains 46. This is the correct filtered result excluding `draft` and `visibility: private`. However, I noted this in documentation to prevent future confusion about "missing posts."

Another current limitation: `TAG_LABELS` is empty, so tag names may display in Japanese on the English site. For now, tags are unified in English, so this is not a problem. But if Japanese tags are added later, English translations must be registered simultaneously.

Also, the "Popular Articles" in `llms.txt` currently shows the "latest 15" rather than "top 15 by views." Without an analytics foundation, this is unavoidable, but I recognize that real view data should be reflected in the future.

## Implications: what individual blog operators should do for AIO

Through this implementation, I extracted three reusable decision criteria.

First, llms.txt is "minimum effort, high impact." With a single file and roughly 100 lines of code, you can create an entry point for AI agents to understand your entire site. For individual blog operators, this should be the first thing to do.

Second, JSON API is a "foundation for future automation." It is just a metadata list now, but it can be reused for automated newsletter generation, social media posting, and as a data source for MCP Servers. Even at 46 posts, there is value in structuring it early.

Third, MCP Server is a "paradigm shift in tooling content." Until now, content was designed for humans to read. Through MCP, posts become "knowledge sources that agents call as tools." The value of content may eventually be measured not just by reader count but by "agent invocation count."

## Looking ahead to Phase 3

With the AIO foundation in place, the next stage I am considering is breaking through the limits of in-memory search. At 46 posts, there is no problem, but beyond 500, the Cloudflare Workers in-memory approach will degrade. I plan to migrate to Cloudflare Vectorize for semantic search.

I am also planning interactive demos. For example, publishing a tool under `/tools/` that generates MCP Server configurations for Claude Desktop based on the blog's metadata would let readers experience "what MCP is and how to configure it" hands-on.

As AI agents become the default for search, personal blogs need more than just human-oriented appearance. They need machine-oriented structuring to make their very existence discoverable. This is not an extension of SEO but a new layer of optimization—making content discoverable by both humans and machines.