Integrates with GitHub to dynamically discover, index, and retrieve documentation files from repositories, managing API rate limits while fetching content.
Provides full-text search and retrieval capabilities for Markdown documentation, allowing AI tools to fetch specific sections or complete documentation bundles for context.
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., "@Slice.js Documentation MCP How do I handle routing in Slice.js?"
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.
An MCP (Model Context Protocol) server that provides access to Slice.js documentation from the official GitHub repository. This server allows AI assistants and tools to query, search, and retrieve documentation seamlessly.
Dynamic Documentation Discovery: Automatically discovers and indexes all documentation files from the GitHub repo
Intelligent Caching: Infinite session cache to minimize API requests and improve performance
Full-Text Search: Search across all documentation with keyword matching
Content Retrieval: Fetch specific documentation pages or the complete documentation bundle
Lazy Initialization: Docs structure is loaded on-demand when first needed
Related MCP server: Unified Docs Hub
npm install -g slicejs-mcpnpx slicejs-mcpThe MCP server runs as a stdio-based service, perfect for integration with AI assistants and MCP-compatible tools.
npx slicejs-mcpThis server is designed to work with MCP-compatible clients. When launched, it exposes 4 tools:
list_docsReturns a list of all available documentation sections and categories.
Parameters: None
Response: JSON array of documentation items with id, title, and path.
Example:
[
{
"id": "getting-started",
"title": "Getting Started",
"path": "markdown/getting-started.md"
}
]search_docsSearches across all documentation using keywords or phrases.
Parameters:
query (string, required): Search term
max_results (number, optional, default: 5): Maximum number of results
Response: JSON array of search results with snippets and metadata.
get_doc_contentFetches the full content of specific documentation page(s).
Parameters:
doc_id (string or string[], required): Documentation ID(s) to fetch
include_metadata (boolean, optional, default: false): Include additional metadata
Response: JSON object(s) with document content, title, and optional metadata.
get_llm_full_contextFetches the complete documentation bundle (~2000 lines) for comprehensive LLM context.
Parameters: None
Response: Complete documentation text
Note: This consumes considerable tokens but provides all documentation in one request.
// Via MCP client
await callTool("list_docs", {});await callTool("search_docs", {
query: "routing",
max_results: 3
});await callTool("get_doc_content", {
doc_id: "getting-started/routing"
});await callTool("get_llm_full_context", {});Source: Documentation fetched from https://github.com/VKneider/slicejs_docs
Caching: Infinite session cache prevents redundant API calls
Initialization: Lazy loading of document structure on first tool use
Rate Limiting: Optimized to stay within GitHub API limits (60 req/hour)
Node.js >= 18
npm or yarn
git clone <repo>
cd slicejs-mcp
npm install
npm run buildnpm start
# or
node dist/index.jsnpx @modelcontextprotocol/inspector node dist/index.jsContributions welcome! Please ensure:
All tools maintain backward compatibility
Cache behavior is preserved
Error handling is robust
MIT
Fetches full content of specific doc page(s)
| Name | Required | Description | Default |
|---|---|---|---|
| doc_id | Yes | ||
| include_metadata | No |
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 behavioral disclosure. It mentions fetching 'full content' but lacks details on permissions required, rate limits, error handling, or whether this is a read-only operation. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
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, efficient sentence with zero waste. It's front-loaded with the core purpose, making it easy to scan and understand quickly. Every word earns its place without unnecessary elaboration.
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 complexity (2 parameters, no output schema, no annotations), the description is incomplete. It doesn't cover parameter details, return values, or behavioral traits like safety or performance. For a tool that fetches content, more context on output format or limitations would be helpful to compensate for the lack of structured data.
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%, so the description must compensate for undocumented parameters. It implies 'doc_id' is used to specify pages but doesn't explain its format or that it can be a single string or array. It doesn't mention 'include_metadata' at all, leaving a key parameter undocumented. The description adds minimal value beyond the 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 action ('fetches') and resource ('full content of specific doc page(s)'), making the purpose immediately understandable. It doesn't explicitly distinguish from sibling tools like 'list_docs' or 'search_docs', but the specificity of 'full content' versus listing or searching provides some implicit differentiation.
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 no guidance on when to use this tool versus alternatives like 'list_docs' or 'search_docs'. It doesn't mention prerequisites, such as needing a valid doc_id, or contextual factors like performance implications for fetching multiple pages. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches the complete documentation bundle (~2000 lines, consumes considerable tokens but provides all documentation in one go). IMPORTANT: Ask the user for confirmation before executing this tool as it will add the entire Slice.js documentation to the context.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: the output size (~2000 lines), token consumption ('consumes considerable tokens'), and the action of adding documentation to context. However, it lacks details on potential errors or rate limits, keeping it from a perfect score.
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 front-loaded with the core purpose, followed by critical usage instructions, all in two efficient sentences with zero wasted words. Every sentence earns its place by providing essential information.
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 complexity (no parameters, no output schema, no annotations), the description is largely complete, covering purpose, usage, and behavioral traits. However, it could be more complete by specifying the format of the returned documentation or any limitations, slightly reducing the score.
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 input schema has 0 parameters with 100% coverage, so no parameter information is needed. The description adds value by explaining the tool's behavior and implications, but it could slightly enhance semantics by mentioning any implicit assumptions, such as the source of the documentation.
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 specific action ('fetches') and resource ('complete documentation bundle'), distinguishing it from sibling tools like get_doc_content, list_docs, and search_docs by emphasizing the comprehensive nature of the 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?
It provides explicit guidance on when to use this tool (to get all documentation at once) and includes a crucial prerequisite: 'Ask the user for confirmation before executing this tool,' which helps differentiate it from alternatives that might be more targeted or less resource-intensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns available documentation sections/categories
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 behavioral disclosure. It states the action ('Returns') but doesn't describe what 'available' means (e.g., all sections, filtered by permissions), the return format (e.g., list of strings, structured data), or any constraints (e.g., pagination, rate limits). This leaves significant gaps for a tool with no annotation coverage.
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, efficient sentence that directly states the tool's function without any wasted words. It's front-loaded with the core action, making it easy to parse quickly.
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 has 0 parameters and no output schema, the description is minimally adequate but incomplete. It explains what the tool does at a high level but lacks details on behavior, return values, and differentiation from siblings. For a simple listing tool, this is the minimum viable, but it could benefit from more context to guide usage effectively.
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 input schema has 0 parameters with 100% description coverage, meaning no parameters need documentation. The description doesn't add parameter information, which is appropriate here. Baseline is 4 for 0 parameters, as there's nothing to compensate for, and the description doesn't introduce confusion.
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 verb ('Returns') and resource ('available documentation sections/categories'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_doc_content' or 'search_docs', which would require mentioning it's a listing/overview function rather than retrieving content or searching.
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 no guidance on when to use this tool versus alternatives. It doesn't mention that this tool is for browsing categories before accessing content with 'get_doc_content' or for when 'search_docs' is more appropriate for specific queries. Without such context, usage is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches across all docs by keyword/phrase
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| max_results | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the search scope ('across all docs') but lacks critical behavioral details: it doesn't specify if results are paginated, what the return format is (e.g., list of titles or full content snippets), or any rate limits. For a search tool with zero annotation coverage, this is insufficient.
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, efficient sentence with zero waste. It's front-loaded and appropriately sized for a simple tool, making it easy to parse quickly.
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 moderate complexity (search with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain return values, error conditions, or behavioral constraints, leaving significant gaps for the agent to infer.
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%, meaning parameters are undocumented in the schema. The description mentions 'keyword/phrase' which hints at the 'query' parameter, but it doesn't explain 'max_results' or provide any syntax details (e.g., query operators). It adds minimal value beyond the bare schema, failing to compensate for the coverage gap.
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 ('Searches') and target resource ('across all docs') with the method ('by keyword/phrase'). It distinguishes this from siblings like 'get_doc_content' (retrieves specific content) and 'list_docs' (likely lists without search). However, it doesn't explicitly differentiate from 'get_llm_full_context', which might be a more comprehensive search, so it's not a perfect 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer 'search_docs' over 'list_docs' or 'get_llm_full_context', nor does it specify prerequisites like needing a query. This leaves the agent with minimal context for tool 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.
v1.0.3get_doc_contentget_llm_full_contextlist_docssearch_docsEach tool has a clearly distinct purpose: get_doc_content retrieves specific pages, get_llm_full_context fetches the entire bundle, list_docs shows available sections, and search_docs performs keyword searches. There is no overlap or ambiguity in their functions.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., get_doc_content, list_docs, search_docs). The naming is predictable and readable throughout the set.
With 4 tools, the count is reasonable for a documentation server, covering core needs like listing, fetching, and searching. It might be slightly thin for advanced use cases, but it's well-scoped for basic documentation access.
The toolset provides good coverage for documentation retrieval: listing, searching, and fetching content (both specific and full). A minor gap is the lack of update or management tools, but this is acceptable for a read-only documentation server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Versioned documentation registry and semantic search for AI tools and coding assistants.
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
@latest documentation and code examples to 9000+ libraries for LLMs and AI code editors in a singl…
Access the GitHub API, enabling file operations, repository management, search functionality, and…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/VKneider/slicejs-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server