EasyPeasyMCP Server

EasyPeasyMCP

Why it's different

• No RAG, no vector database, no embedding pipeline. Search is a case-insensitive line scan with configurable context — all in-process, in memory. For small projects with well-structured content like llms-full.txt, this is all you need to get started — no infrastructure, no ops burden, easy to pitch internally. The entire search capability is ~25 lines of vanilla JS with zero runtime dependencies.

• Any project with an llms-full.txt is MCP-enabled in 30 seconds. Point llmsTxt at a hosted URL and you're done — no local file sync, no pipeline. Docs update, the AI gets fresh content automatically. It's the adoption curve that matters: the llms.txt standard is becoming the norm for docs sites, and this tool makes every one of them instantly AI-accessible.

  Don't have an llms-full.txt yet? No problem — as long as you have Markdown files, the bundled easy-peasy-build CLI will generate one for you from your docs and specs.

• Conditional tool registration keeps the AI's context clean. No OpenAPI directory? No list_openapi_specs tool. Tools only appear when the content exists — the MCP surface matches exactly what you've provided.

When to use this — and when not to

This is a speed-first tool. Use it when you need an agent to access new knowledge in minutes, not days — a quick proof of concept, a personal workflow, a demo, or an early internal pilot where getting something working fast matters more than getting it perfect.

For professional, long-term setups shared across teams, you will eventually want a proper chunk → embed → RAG pipeline instead. That gives you semantic search (the agent finds meaning, not just matching words), much lower token consumption per query, and the ability to scale across large or frequently updated knowledge bases without loading everything into memory. This tool loads the full content on every startup — that's fine for a few hundred KB, but it's a ceiling, not a foundation.

No docs at all? Not even Markdown files? If you're in a real hurry, just ask the agent to scrape the developer portal you depend on — it can crawl the relevant pages and pull the content together. It can even check common locations for OpenAPI or AsyncAPI specs and fetch those too. Combine that with easy-peasy-build and you have a working MCP server in minutes, with zero local files to maintain.

The honest summary: use this to validate that AI-assisted documentation is worth investing in. Once it is, graduate to a proper RAG stack.

How it works

search_documentation covers all loaded content (llms-full.txt + all specs).

Quick start

{
  "name": "my-project",
  "llmsTxt": "./llms-full.txt",
  "openapi": "./openapi",
  "asyncapi": "./asyncapi",
  "build": {
    "docs": ["./guides", "./api-reference"]
  }
}

name: my-project
llmsTxt: ./llms-full.txt
openapi: ./openapi
asyncapi: ./asyncapi
build:
  docs:
    - ./guides
    - ./api-reference

# Use absolute path
claude mcp add my-project npx easy-peasy-m

{"mcpServers": {"easy-peasy-mcp": {"command": "npx", "args": ["-y", "easy-peasy-mcp"], "env": {"CONFIG_PATH": "/absolute/path/to/.easypeasymcp.json"}}}}