Blumeで作る、LLMに読ませるドキュメントの3つの出口This article explains how to use Blume as an MCP tool to export LLM-readable…

As large language models become part of everyday development workflows, the way documentation is prepared for machine consumption is becoming nearly as important as how it is written for people. A recent tutorial published on Zenn addresses this shift using Blume, a documentation tool that can operate as a Model Context Protocol (MCP) server, and it lays out three distinct output formats—Markdown, JSON, and embedding vectors—each suited to a different method of feeding content to an LLM. The framing matters because the format in which documentation reaches a model can strongly influence how reliably that model retrieves and uses the information.

The Model Context Protocol is an open standard, introduced by Anthropic in late 2024, that defines how AI applications connect to external tools and data sources. Instead of building a custom integration for every combination of model and system, developers can expose a resource once through an MCP server and let any compatible client—such as Claude Desktop, IDE assistants, or custom agents—consume it. Treating Blume as an MCP tool means a model can request documentation on demand during a task, rather than depending on whatever text a user happened to paste into the prompt. This positions documentation as a live, queryable resource instead of a static file.

The article organizes its guidance around the idea of three "exits," the notion that the same underlying documentation can leave the system through three different doors depending on who or what is consuming it. The first exit is Markdown, which remains the most direct option for placing content into a model's context window. Markdown is lightweight, human-readable, and preserves structural cues such as headings, lists, and code blocks that models generally parse well. It is a sensible default when the goal is to hand a model a self-contained document to read and reason over in a single pass.

The second exit is JSON, aimed at programmatic and agentic consumption. By expressing documentation as structured data with predictable fields, JSON allows an agent to navigate sections, extract metadata, or pull only the parts it needs without interpreting free-form prose. This is especially useful in multi-step workflows where a tool or orchestration layer processes the documentation before it ever reaches the model, or where consistency and validation matter more than readability.

The third exit is embedding vectors, the numerical representations that underpin semantic search and retrieval-augmented generation, commonly abbreviated as RAG. Here, documentation is split into chunks and passed through an embedding model to produce vectors that capture meaning rather than exact wording. Those vectors are typically stored in a vector database—options in this space include pgvector, Chroma, Weaviate, and Pinecone—so that a query can retrieve the most semantically relevant passages by similarity. This exit is intended for large corpora that cannot fit into a context window, where the system fetches only the passages most likely to answer a given question.

Taken together, the three formats reflect a broader principle in AI-integrated documentation: the right representation depends on the retrieval pattern. Markdown suits direct reading, JSON suits structured programmatic access, and embeddings suit similarity-based search across large collections. Some workflows are likely to combine them, for instance using vector search to locate relevant documents and then serving the underlying Markdown for the final generation step. The article appears to emphasize this design perspective, treating documentation structure as an upstream decision that shapes downstream LLM behavior.

For readers unfamiliar with the surrounding ecosystem, a few prerequisite concepts help. Embedding models differ from the generative models that produce answers, and the choice of embedding model affects retrieval quality. Chunking strategy—how documents are divided before embedding—also influences results, since overly large or poorly bounded chunks can dilute relevance. MCP itself continues to gain adoption across editors and agent frameworks, which makes tooling that speaks the protocol more broadly reusable.

The practical value of an approach like Blume's is that it consolidates these output paths behind a single interface, reducing the need to maintain separate pipelines. As with any tutorial, readers should verify current behavior against the tool's documentation, since MCP tooling and Blume's own features may evolve. Still, the underlying guidance—matching document format to how an LLM will actually consume it—is likely to remain relevant as retrieval-centric AI systems mature.