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., "@DocsScraper search for authentication setup examples in the Stripe API"
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 server that connects to the DocsScraper web API to provide semantic search capabilities through documentation chunks.
Semantic Search: Search through documentation chunks using embeddings and AI validation
API Integration: Connects to your DocsScraper web application via REST API
Fallback Sources: Automatically falls back to scraper sources when no local results are found
Configurable Results: Control the number of search results (1-10, default: 5)
Service Filtering: Filter search results by specific service names (case-insensitive)
Related MCP server: Documentation MCP Server
The server requires the following environment variables:
DOCS_SCRAPER_API_KEY: API key for authentication (required)
Search through documentation chunks using semantic search.
Parameters:
query (string, required): The search query to find relevant documentation
top (number, optional): Maximum number of results to return (1-10, default: 5)
service (string, required): Service name to filter results by (case-insensitive)
Examples:
{
"query": "how to configure authentication",
"service": "Binance",
"top": 3
}{
"query": "React hooks documentation",
"top": 5,
"service": "React"
}Provides information about the connected DocsScraper API, including:
Base URL configuration
API key status
Endpoint details
Authentication method
This server connects to the DocsScraper web API endpoint:
Endpoint: GET /api/chunks/search
Authentication: API Key via X-API-Key header
Parameters: query (string), top (number), service (string, optional)
The search endpoint:
Uses embeddings to find semantically similar chunks
Applies AI validation to ensure relevance
Falls back to scraper sources if no local results are found
Returns chunks with scores and source information
npm install
npm run build{
"mcpServers": {
"docs-scraper": {
"command": "node",
"args": [
"/Users/tanevanwifferen/Documents/Cline/MCP/docs-scraper-server/build/index.js"
],
"env": {
"DOCS_SCRAPER_API_KEY": "###",
"DOCS_SCRAPER_BASE_URL": "https://api.mcpdocsscraper.click"
},
"disabled": false,
"alwaysAllow": [
"search_docs"
],
"timeout": 900 // important, we need a lot of time to do our requests
}
}The server is designed to be used with MCP-compatible clients. Configure your client to connect to this server with the appropriate environment variables set.
The server provides detailed error messages for common issues:
Authentication failures (401)
Invalid requests (400)
Connection issues (ECONNREFUSED)
# Build the server
npm run build
# Watch for changes during development
npm run watch
# Test with MCP inspector
npm run inspectorSearch through documentation chunks using semantic search. Make sure your query is specific to get the best results. Forgetting to add 'api' to the query will return ui results etc.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query to find relevant documentation | |
| service | Yes | Service name to filter results by (case-insensitive) | |
| top | No | Maximum number of results to return (1-10, default: 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 behavioral disclosure. It mentions that queries should be specific and that omitting 'api' affects results, which adds some context about search behavior. However, it fails to disclose critical traits like whether the search is read-only, if it has rate limits, authentication needs, or what the output format looks like (especially since there's no output schema). This leaves significant gaps for an agent to understand the tool's behavior fully.
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 and front-loaded, starting with the core purpose in the first sentence. The second sentence provides practical advice without unnecessary elaboration. Both sentences earn their place by adding value, though the structure could be slightly improved by explicitly mentioning parameters or output expectations to enhance clarity.
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 (semantic search with three parameters) and the absence of both annotations and an output schema, the description is incomplete. It explains the basic purpose and offers usage tips but fails to cover behavioral aspects like safety, performance, or return values. This leaves the agent with insufficient information to use the tool confidently in varied contexts.
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 100% description coverage, clearly documenting all three parameters (query, service, top) with their types, constraints, and purposes. The description does not add any meaningful parameter semantics beyond what the schema provides; it only references the 'query' parameter indirectly in usage tips. Thus, it meets the baseline score of 3, as the schema adequately covers parameter details without needing extra explanation in the description.
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: 'Search through documentation chunks using semantic search.' It specifies the verb ('search'), resource ('documentation chunks'), and method ('semantic search'), making the function unambiguous. However, without sibling tools for comparison, it cannot demonstrate differentiation, preventing a perfect score.
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 implied usage guidance: it advises making queries 'specific to get the best results' and warns that forgetting to add 'api' to the query will return 'ui results etc.' This offers some context on how to use the tool effectively. However, it lacks explicit when-to-use scenarios, prerequisites, or comparisons to alternatives, as no sibling tools exist.
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.0search_docsWith only one tool, there is no possibility of ambiguity or overlap between tools. The tool 'search_docs' has a single, clear purpose of searching documentation chunks using semantic search, so agents cannot misselect among multiple options.
The naming follows a consistent verb_noun pattern with 'search_docs', and since there is only one tool, there are no deviations or mixed conventions to evaluate. The naming is straightforward and predictable.
A single tool for a server named 'DocsScraper' feels too thin for the apparent scope, as scraping documentation typically involves more operations like fetching, parsing, or updating content. One tool may limit functionality and agent workflows, making it borderline inadequate.
The tool surface is severely incomplete for a documentation scraping domain. While 'search_docs' provides search capability, there are obvious gaps such as no tools for retrieving, listing, or managing documentation sources, which are essential for comprehensive scraping operations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
@latest documentation and code examples to 9000+ libraries for LLMs and AI code editors in a singl…
Search and read Rust documentation for the standard library and any crate on crates.io
Turn any URL into clean Markdown and structured data. Scrape, crawl, search and extract.
Provides access to Google's public developer documentation.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tanevanwifferen/DocsScraperMCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server