Provides searchable official Cloudflare documentation, allowing agents to look up Workers, Pages, and network APIs.
Provides searchable official FastAPI documentation, allowing agents to retrieve accurate API usage, parameters, and examples.
Provides searchable official Hono documentation, allowing agents to look up web framework APIs and middleware.
Provides searchable official Netlify documentation, enabling agents to retrieve deployment and configuration guidance.
Provides searchable official Next.js documentation, helping agents use current App Router and server/client components correctly.
Provides searchable official Pydantic documentation, helping agents use data validation and settings management APIs.
Provides searchable official React documentation, helping agents use current React 19 APIs and avoid deprecated patterns.
Provides searchable official Resend documentation, enabling agents to send emails and manage email APIs.
Provides searchable official shadcn/ui documentation, enabling agents to use UI components and styling patterns.
Provides searchable official Supabase documentation, enabling agents to retrieve database, auth, and storage APIs.
Provides searchable official Svelte 5 documentation, enabling agents to avoid deprecated APIs and use Runes correctly.
Provides searchable official Tauri 2 documentation, enabling agents to look up desktop app development APIs.
Provides searchable official TypeScript documentation, helping agents retrieve accurate type system information and handbook sections.
Provides searchable official Vite documentation, allowing agents to look up build tool configuration and features.
Provides searchable official WXT documentation, helping agents build browser extensions with current APIs.
Provides searchable official Zod documentation, enabling agents to use schema validation APIs correctly.
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., "@agents-docs search FastAPI docs for dependency injection"
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.
Ultra-fast, zero-bloat local markdown documentation RAG for AI coding agents via MCP.
Instant BM25 search over official framework documentation and live AI model registries. Shared across Cursor, Claude Code, Antigravity, and Zed.
.agents/docs?Coding agents frequently hallucinate deprecated APIs (Svelte 4 vs 5 Runes, Tailwind v3 vs v4, React 19 Actions) or reference outdated LLM models and token pricing.
Traditional vector-embedding RAG solutions are bloated: they require Docker containers, hundreds of megabytes of Python dependencies (Chroma, LangChain), and slow API embedding calls that split code blocks in half.
agents-docs applies the Lolaplex philosophy:
Zero Vector DBs: Header-aware markdown chunking + pure Python lexical BM25 ranking with header match boost (+6.0) and full phrase boost (+10.0).
Sub-10ms Search: Instant retrieval directly from plain markdown files on disk (~/.agents/docs/).
Live AI Models Registry: Real-time tracked context windows, benchmarks, and token pricing ($/1M) for Frontier and Open-Weights models (Claude 5/4, GPT-5/o3/o4, Gemini 3.x, DeepSeek V4/R1, Qwen 2.5 Coder).
Curated 21+ Framework Catalog: 1-click sync for official llms.txt (TypeScript Handbook, Svelte 5, FastAPI, Tailwind v3/v4, Tauri 2, Next.js, Supabase, Hono, WXT, Netlify, Coolify, Cloudflare, Resend, React, Vite, Zod, Pydantic, shadcn/ui).
Deterministic Noise Pruning: Automatically strips HTML wrappers, link noise, and cookie banners without altering code blocks or tables.
Universal MCP Server: FastMCP stdio interface with auto-sync and dependency manifest inspection.
Related MCP server: Speakeasy Docs MCP
┌─────────────────────────────────────────────────────────────┐
│ DOCS & MODEL REGISTRIES │
│ Official llms.txt · TypeScript Handbook · OpenRouter │
└──────────────────────────────┬──────────────────────────────┘
│ agents-docs sync <name>
▼
┌─────────────────────────────────────────────────────────────┐
│ DETERMINISTIC NOISE PRUNER │
│ Strips HTML boilerplate while preserving 100% of code │
└──────────────────────────────┬──────────────────────────────┘
│ Header-aware chunking
▼
┌─────────────────────────────────────────────────────────────┐
│ LOCAL DOCUMENTATION STORE │
│ ~/.agents/docs/ai-models/ ~/.agents/docs/svelte-5/ │
│ ~/.agents/docs/typescript/ ~/.agents/docs/fastapi/ │
└──────────────┬───────────────────────────────┬──────────────┘
│ │
▼ ▼
┌─────────────────────────────┐ ┌─────────────────────────────┐
│ LEXICAL BM25 │ │ MCP SERVER & CLERK │
│ Header Match Boost (+6.0) │ │ search_docs · list_docsets │
│ Sub-10ms Exact Retrieval │ │ sync_project_docs │
└─────────────────────────────┘ └─────────────────────────────┘pip install agents-docs && agents-docs initScaffolds ~/.agents/docs/, seeds the live ai-models registry, autowires MCP configurations into your installed IDEs, and registers assistant skills.
🤖 Agent-Driven Setup (Zero Friction):
Simply tell your coding agent: "Install and set up agents-docs for me."
The agent installs the package, runs agents-docs init, and automatically retrieves fresh documentation whenever you ask technical stack or model pricing questions.
Command | Purpose |
| Plug & Play setup: auto-configures MCP across all IDEs and seeds model docs |
| Lists all 21+ pre-configured frameworks and model catalogs |
| 1-click download/update of official framework documentation |
| Ingests any custom |
| Fast BM25 search across all installed docsets |
| Scoped search within a specific documentation set |
| In-place noise & boilerplate cleaner across all installed docs |
| Lists all installed docsets on disk with file and byte counts |
| Runs the FastMCP stdio server (default) |
Tool | Parameters | Description |
| None | Lists all installed docsets in |
|
| Returns top matching markdown sections with headers and code blocks in milliseconds. Auto-syncs missing catalog docsets on demand. |
|
| Returns the raw markdown content of a specific file. |
| None | Lists all 21+ pre-configured frameworks and model catalogs available for 1-click sync. |
|
| Downloads/updates official documentation from the catalog or custom |
|
| Inspects |
| None | Scans |
Claude Code: Bound via MCP server and .agents/skills/docs-search.
Google Antigravity: Integrated via .gemini/config rules and agents-docs MCP.
Cursor: Automatically configures .cursor/mcp.json and agent rules.
Zed: Configures context_servers and mirrors assistant skills.
VS Code / Windsurf: Autowires Cline / Roo-Code MCP configuration.
Detailed architectural specifications live in abi/:
abi/WHY.md — Architectural rationale & BM25 vs Vector embeddings.
abi/LAYOUT.md — Storage taxonomy in ~/.agents/docs/.
abi/MCP.md — Tool surface definitions and schemas.
abi/CATALOG.md — Curated catalog schema and supported types.
abi/LLMSTXT.md — Support for the llms.txt standard.
Run the test suite across all engines:
python tests/run_all_tests.pyMIT License. See LICENSE for details.
Fetch the complete raw markdown of a specific documentation page.
Args: docset: Name of the docset (e.g. 'svelte-5') rel_path: Relative path to the markdown file within the docset (e.g. 'docs.md' or 'runes/state.md')
| Name | Required | Description | Default |
|---|---|---|---|
| docset | Yes | ||
| rel_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the operation is a 'fetch' which implies read-only, but does not explicitly declare no side effects, error behavior, or access requirements. For a simple fetch, this is adequate but not rich.
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 plus a compact args block with examples. No fluff; every sentence earns its place. The information is front-loaded and easy to scan.
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 the tool's simplicity (two string parameters, no nesting) and the presence of an output schema (though not shown), the description is nearly complete. It lacks error handling and existence prerequisites, but these are not critical for a straightforward fetch operation.
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 0%, but the description compensates with concrete examples for both docset ('svelte-5') and rel_path ('docs.md' or 'runes/state.md'), adding meaning beyond the bare schema titles. This is helpful and clarifies expected formatting.
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 'Fetch the complete raw markdown of a specific documentation page' - a specific verb (Fetch) and resource (documentation page) with an explicit output format (raw markdown). This distinguishes it from siblings like list_docsets, search_docs, and sync_* tools.
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 provides examples for both arguments but does not explicitly state when to use this tool versus alternatives like search_docs or list_catalog. It implies usage for retrieving a known page but lacks exclusions or alternative naming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List curated pre-configured framework docsets available for 1-click sync. Includes Svelte 5, FastAPI, Next.js, Supabase, Tailwind v3/v4, Tauri 2, Hono, MCP, WXT.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'List' and the example frameworks give a reasonable sense of expected content, and the tool has no parameters, making it likely read-only. With no annotations, the description carries the transparency burden, but it does not explicitly state that this is a non-mutating operation or how results are ordered.
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 the core purpose, and concrete examples. Every word earns its place with no filler.
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 zero-parameter list tool with an output schema, the description fully covers what is being listed, why it matters for one-click sync, and what the catalog contains. There are no critical gaps for this level of 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?
The tool has zero parameters, so the baseline is 4. The description adds meaningful context about curated pre-configured docsets and the sync availability that the empty schema cannot convey.
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 curated pre-configured framework docsets and gives concrete examples, so the verb and resource are specific. It does not explicitly differentiate itself from the similarly named sibling list_docsets, preventing a 5.
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?
There is no guidance on when to use this tool versus list_docsets, search_docs, or sync_docset. The wording implies it is for discovering pre-configured docsets, but no alternatives or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all indexed framework/library docsets in ~/.agents/docs/ with file stats and metadata.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and only the phrase 'with file stats and metadata,' the description conveys a read-only listing operation but does not disclose access needs, sort details, permissions, potential network access, or other side effects.
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?
A single concise sentence fully conveys a clear scope for a zero-argument tool; no wordy details or redundancy.
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?
With an output-schema available, zero parameters, and no nested objects, the description completely defines a simple listing operation. It lacks alternate-tool guidance and explicit return shape, but the output schema and simplicity give enough context for successful selection.
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?
The tool accepts zero parameters, and its empty input schema is fully documented; there are no parameter semantics to describe, so the baseline is appropriate (no penalties).
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?
Description uses an explicit verb 'list' with a specific resource ('all indexed framework/library docsets') plus qualifiers ('in ~/.agents/', 'with file stats and metadata'), clearly distinguishing it from sibling tools that search, fetch, or sync.
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?
It provides no explicit guidance on when to choose this tool over siblings like search_docs or list_catalog, though the name and listing-specific wording imply a browsing/listing use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search local documentation sets using header-aware BM25 lexical ranking. Auto-fetches missing catalog docsets on demand in 1 second.
Args: query: Keywords, function signatures, or questions (e.g. '$state runes', 'HTTPException', 'glassmorphism') docset: Target docset name (e.g. 'svelte-5', 'fastapi', 'tailwind-v3') or 'all' to search all installed docs. top_k: Number of relevant sections to return (default 4).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_k | No | ||
| docset | No | all |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It mentions auto-fetching missing docsets, which is a side effect, and the ranking method. However, it does not clarify whether the operation is read-only, the format of results, or potential performance implications beyond a vague '1 second' claim.
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?
The description is concise, with a brief two-sentence overview followed by a clear parameter breakdown. No unnecessary filler; each sentence contributes to understanding.
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 search tool, the description covers the core functionality, parameters, and a side effect (auto-fetch). It does not explain return structure, but since an output schema is present, that is not required. The description is sufficiently complete for typical usage.
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?
The description adds meaningful context to each parameter: query accepts keywords/signatures/questions, docset specifies target or 'all', and top_k indicates number of sections. Examples are provided, enhancing clarity beyond the bare 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?
Clearly states the tool's function: searching local documentation sets using header-aware BM25 lexical ranking. Distinguishes itself from sibling tools like list_docsets and get_doc_page by focusing on search.
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?
Provides examples for query and docset but does not explicitly explain when to choose this tool over alternatives like get_doc_page or list_docsets. The intended use case is implied but not directly contrasted with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Synchronize or update a documentation set from the curated catalog or a custom URL.
Args: name: Name of the catalog item (e.g. 'svelte-5', 'fastapi', 'tailwind-v3') or a custom docset identifier. url: Optional custom URL (pointing to llms.txt, llms-full.txt, or raw markdown) if name is not in catalog.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing side effects. It only says 'Synchronize or update' without specifying whether this is destructive, requires permissions, involves network calls, or modifies local state. This is insufficient for a mutating operation.
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?
The description is concise—two sentences covering purpose and parameter details. It avoids unnecessary fluff and is well-structured, making it easy to parse.
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?
The description lacks information about return value, side effects, and clear differentiation from other sync tools. While it covers the basic purpose and parameters, it does not fully address the context needed for an agent to use it confidently in all scenarios.
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?
The description adds meaningful context beyond the bare schema: it explains that 'name' can be a catalog item or custom identifier (with examples), and clarifies that 'url' is used only when the name is not in the catalog. This gives practical guidance for parameter usage.
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's function: 'Synchronize or update a documentation set from the curated catalog or a custom URL.' It distinguishes itself from sibling tools like list_docsets and get_doc_page by focusing on synchronization/update, and mentions two input modes (catalog name or URL).
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 a docset needs syncing, but does not explicitly differentiate from other sync-related siblings (sync_project_docs, sync_memory_docs). It lacks clear guidance on when to choose this tool over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan local agents-memory (~/.agents/memory/PROJECTS.md & projects/*.md), detect all active tech stacks/frameworks, and auto-sync matching documentation sets.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing side effects. It states that it scans and 'auto-syncs' documentation sets, which implies writes, but does not disclose whether files may be overwritten, whether network access is required, or whether the operation is reversible. This is a meaningful transparency gap for a sync tool.
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?
The description is a single, front-loaded sentence that conveys source paths, detection logic, and action without filler. Every phrase earns its place.
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 zero-parameter tool with an output schema, the description covers what it scans, what it detects, and what it syncs. It could be more complete by noting side effects or differentiating from sibling sync tools, but the core usage context is adequately specified.
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?
The tool takes zero parameters, and the input schema already covers this completely (100% coverage). The description does not need to add parameter details, and with no parameters, the baseline for this dimension is 4.
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 uses specific verbs ('scan', 'detect', 'auto-sync') and names the exact resource (~/.agents/memory files) and target (matching documentation sets). It clearly distinguishes itself from sibling sync tools by emphasizing memory-driven stack detection and automatic synchronization.
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 conveys a clear usage context: run this when you want documentation sets synced based on active tech stacks detected from local agents-memory. It does not explicitly name alternatives or exclusions, but the memory-scanning trigger is enough to guide tool selection in most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect a project directory (package.json, requirements.txt, pyproject.toml, Cargo.toml), detect used frameworks/libraries, and auto-sync all matching official documentation sets.
Args: project_path: Absolute or relative path to project root folder
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It mentions 'auto-sync' but does not disclose side effects like overwriting files, network access requirements, permissions needed, or failure behavior. For a tool that likely modifies files, this is a significant transparency gap.
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?
The description is concise, front-loaded with the core action in the first sentence, and includes a clear Args section. Every sentence serves a purpose, with no redundant or irrelevant content.
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?
The tool is complex (inspects multiple file types, detects frameworks, syncs multiple docs) but the description does not explain what the output will be, what changes it makes, or how errors are handled. With no annotations and no visible output schema, the description leaves too many operational questions unanswered for a mutation-like tool.
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 description coverage is 0%, but the description compensates by defining project_path as an absolute or relative path to the project root folder. This adds basic semantics beyond the schema's generic string type, but it lacks constraints, examples, or handling of invalid paths, so it is only partially helpful.
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's purpose: inspecting a project directory, detecting frameworks/libraries, and auto-syncing all matching official documentation sets. It uses specific verbs and resources, and distinguishes itself from siblings like sync_docset by addressing a holistic project-wide sync, not just a single docset.
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 a use case (when you have a project with manifest files like package.json) but does not explicitly state when to use this tool versus alternatives such as sync_docset, nor does it provide any exclusions or conditions. The context is clear but lacks explicit guidance on selection.
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.42.0get_doc_pagelist_cataloglist_docsetssearch_docssync_docsetsync_memory_docssync_project_docsEach tool serves a distinct purpose: listing installed docs, searching, fetching a page, listing available catalogs, and three specific sync modes. Even the two 'list' tools are clearly separated by context (local vs catalog). No overlaps or ambiguous boundaries.
All tool names follow a consistent verb_noun pattern (list_, search_, get_, sync_, etc.). The nouns are specific and descriptive, and the use of snake_case is uniform throughout. No style mixing or vague generic names.
Seven tools is well-scoped for a documentation management server. Each tool covers a distinct aspect—listing, searching, fetching, catalog access, and syncing via three methods—without unnecessary duplication or bloat.
The toolset covers the full lifecycle of local documentation management: discover installed docs, search, retrieve content, sync from catalog or custom URL, and auto-sync based on project dependencies or memory files. No obvious missing operations for the intended purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search GitHub, npm, PyPI, StackOverflow, ArXiv from one MCP — built for coding agents.
Versioned documentation registry and semantic search for AI tools and coding assistants.
Token-efficient MCP memory for Markdown vaults. Tiered search, GraphRAG, AI memories.
Team docs served to AI agents over MCP - search, Markdown reads, version pinning, read audit.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Lolaplex/agents-docs'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
