A local MCP server that fetches, caches, and serves official library documentation to coding agents — offline-first, deterministic, and free.
list_libraries(): View all libraries in the registry along with their current cache status (fresh, stale, or not yet fetched).
get_docs(library, topic?, maxTokens?): Fetch or serve cached documentation for a specific library. Provide a topic to get the best-matching sections (via markdown heading-split and keyword scoring), or omit it to receive a table of contents and document head. Supports an optional maxTokens budget (default 4000). Automatically follows llms.txt index links one level deep.
refresh(library?): Force a re-fetch from the network, bypassing the cache TTL. Omit the library name to refresh all libraries at once.
Offline fallback: When the network is unavailable, stale cached content is served and clearly flagged as STALE:.
Custom libraries: Extend the default registry (Fastify, Prisma, React, Playwright, Anthropic SDK, etc.) via a JSON config file, specifying source URLs and custom TTL values.
Fetches and caches official documentation for Fastify, providing relevant sections to coding agents via llms.txt-first retrieval.
Fetches and caches official documentation for Hono, providing relevant sections to coding agents via llms.txt-first retrieval.
Fetches and caches official documentation for Prisma, providing relevant sections to coding agents via llms.txt-first retrieval.
Fetches and caches official documentation for React, providing relevant sections to coding agents via llms.txt-first retrieval.
Fetches and caches official documentation for TimescaleDB, providing relevant sections to coding agents via llms.txt-first retrieval.
Fetches and caches official documentation for fastify-type-provider-zod (Zod integration), providing relevant sections to coding agents via llms.txt-first retrieval.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@docs-cache-mcp get docs for Fastify request validation"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A local MCP server that fetches official library documentation (llms.txt-first), caches it to disk, and serves the relevant sections to your coding agents — offline, deterministic, zero recurring cost.
Published on npm as
@blackraptorai/vibectx. (Formerly@blackraptorai/docs-cache-mcp≤ 0.1.1 — deprecated in favor of this package.)
By BlackRaptor AI · MIT · Companion to BlackRaptor Agents — development and BlackRaptor Agents — council.
Coding agents need current, correct docs in context. Cloud docs services work, but you
trade away control, offline use, and repeatability. This server keeps the whole loop
local: fetch once from the official source (preferring each project's published
llms.txt / llms-full.txt), cache to disk with a TTL, serve
sections matched to the agent's question. When the network is down you get the cached
copy, clearly flagged as stale, instead of a failure.
Related MCP server: docs-mcp
# Claude Code
claude mcp add vibectx -- npx -y @blackraptorai/vibectx
# or any MCP client (stdio):
npx -y @blackraptorai/vibectxTool | What it does |
| Registry + per-library cache status |
| Fetch-or-cache, then return the sections best matching |
| Force refetch past the TTL (all libraries when omitted) |
Ships with a default registry (Fastify, Prisma, TimescaleDB, pgvector, Anthropic SDK, AWS CDK, Playwright, React, fastify-type-provider-zod). Add or override libraries with a JSON config:
npx -y @blackraptorai/vibectx --config ./docs-cache.config.json{
"libraries": [
{
"name": "hono",
"urls": ["https://hono.dev/llms-full.txt", "https://hono.dev/llms.txt"],
"ttlHours": 168,
"description": "Hono web framework"
}
]
}URLs are candidates probed in order — list llms-full.txt first, then llms.txt,
then any curated fallback page (raw GitHub READMEs work well). Cache lives at
~/.docs-cache-mcp/ (override with DOCS_CACHE_DIR). Default TTL is 7 days.
Offline-first: past-TTL cache is served (flagged STALE:) when the network fails —
an old answer beats no answer, but the agent is told which it got.
Index-aware: many projects publish llms.txt as a link index rather than full
content. When the source looks like an index, the topic's best-matching links are
fetched (and cached) one level deep.
Deterministic retrieval: markdown heading-split + keyword scoring. No embeddings, no external calls at query time, same answer every run.
This tool is free and MIT-licensed, and will stay that way. If you have a private documentation, air-gapped, or enterprise deployment need it doesn't cover — open an issue and describe your setup. Real-world reports directly shape what gets built.
npm install
npm test # vitest
npm run build # tsc → dist/MIT © 2026 Tom Hanks / BlackRaptor AI
Get official documentation for a library. With a topic, returns the best-matching sections (following index links when the source is an llms.txt index); without one, returns the document head and section list.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | What you need docs about | |
| library | Yes | Library name from list_libraries | |
| maxTokens | No | Approximate response budget (default 4000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: returns best-matching sections, follows index links if source is llms.txt, returns head and section list when no topic, and mentions response budget via maxTokens. It does not cover auth needs or error handling but is quite detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with main purpose, each sentence adds value without redundancy. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and no annotations, the description is fairly complete. It explains behavior for both usage modes. Lacks details on return format and error scenarios, but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds context beyond the schema: explains how topic affects output (with vs without), and that library comes from list_libraries. This enriches parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets official documentation for a library, with specific behavior for when a topic is provided. It distinguishes itself from siblings (list_libraries, refresh) which are obviously different.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need docs for a library) but does not explicitly state when to use this over alternatives or when not to use it. It lacks explicit guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the libraries this server can fetch docs for, with cache status. Use get_docs to retrieve content.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the output includes cache status but does not explicitly state read-only behavior or any side effects. The verb 'list' implies read-only, but more detail could be added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Purpose is front-loaded, and alternative usage is given succinctly. Conciseness is excellent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 0-parameter tool, the description covers purpose, output (libraries with cache status), and relationship to siblings. It is complete and sufficient for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is trivially 100%. The description adds context about what the list contains (libraries with cache status), which is helpful beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists libraries with cache status, using the verb 'list' and specifying the resource 'libraries'. It distinguishes itself from sibling 'get_docs' by directing to use that tool for content retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use this tool (to list libraries) and provides an alternative ('Use get_docs to retrieve content'). It is clear but does not explicitly mention when not to use or cover the 'refresh' sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Force-refetch a library's docs from the network, bypassing the cache TTL. Omit library to refresh everything.
| Name | Required | Description | Default |
|---|---|---|---|
| library | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses network fetch, cache bypass, and the ability to refresh all libraries. No annotations exist, so description provides necessary behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste, action verb first, and essential details packed efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key behavior and parameter usage for a simple tool. Could mention return format or side effects, but sufficient given no output schema and low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, but description explains the optional 'library' parameter and its default behavior (refresh everything when omitted), adding significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (force-refetch), resource (library's docs), and distinguishes from siblings like get_docs and list_libraries by emphasizing bypassing cache.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (when fresh data needed) and implies when not to (if cached data acceptable). No explicit alternatives named, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0get_docslist_librariesrefreshEach tool serves a distinct purpose: get_docs retrieves documentation, list_libraries lists available libraries, and refresh manages the cache. No overlap in functionality.
All tool names follow the verb_noun pattern (get_docs, list_libraries, refresh) with consistent imperative verbs and underscore separation.
With 3 tools, the server is minimal but covers the essential operations for a documentation cache. It could benefit from a search or add tool but is still appropriately scoped.
The set covers core cache operations: listing available libraries, fetching docs, and refreshing cache. Minor gap: no explicit way to add/remove libraries, but that may be handled externally.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that gives your AI access to the source code and docs of all public github repos
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
MCP server for accessing curated awesome list documentation
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/BlackRaptorAI/VibeCTX'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
