agents-docs

by Lolaplex

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.42.0
Disambiguation5/5
Each 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 3.8/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on August 20, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![agents-docs MCP server](https://glama.ai/mcp/servers/Lolaplex/agents-docs/badges/card.svg)](https://glama.ai/mcp/servers/Lolaplex/agents-docs)

Score Badge

Copy to your README.md:

[![agents-docs MCP server](https://glama.ai/mcp/servers/Lolaplex/agents-docs/badges/score.svg)](https://glama.ai/mcp/servers/Lolaplex/agents-docs)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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