How do I use Amazon Q Web Documentation Reader?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Amazon Q Web Documentation Reader How do I set up environment variables in a Next.js app? Documentation: https://nextjs.org/docs" 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.

Amazon Q Web Documentation Reader

by Lumos-Labs-HQ

Overview Schema Source Related Servers Discussions Admin

Python

Remote

🌐 Amazon Q Web Documentation Reader

MCP Server for Intelligent Web Content Extraction

Features • Installation • Setup • Usage • Tools

✨ Features

🧠 Intelligent Navigation - Amazon Q (Claude 4.5) decides which documentation pages to visit
🧹 Clean Content Extraction - Removes navigation, ads, scripts, and other non-content elements
📝 Multiple Output Formats - Supports both Markdown and plain text output
💻 Code Block Extraction - Specifically extracts code examples from documentation
📊 Page Structure Analysis - Extracts heading hierarchy and table of contents
🔗 Link Discovery - Finds and filters documentation links
📚 Batch Processing - Read multiple documentation pages at once

Related MCP server: Nexus MCP Server

🎯 How It Works

User: "I'm having issues with Razorpay routes"
      Documentation: https://razorpay.com/docs

Amazon Q (Claude 4.5):
  1. Reads main docs page
  2. Sees links: ["Payments", "Routes", "Webhooks", ...]
  3. Intelligently decides: "Routes link is relevant!"
  4. Navigates to Routes documentation
  5. Extracts content and solves your problem

All navigation decisions = Amazon Q's Claude brain 🧠
MCP Server = Clean content extraction tool 🛠️

📦 Installation

Prerequisites

Python 3.12 or higher
uv (recommended) or pip
Amazon Q CLI

Step 1: Clone the Repository

git clone https://github.com/yourusername/amazon-q-web_search.git
cd amazon-q-web_search

Step 2: Install Dependencies

Using uv (Recommended):

uv sync

Using pip:

pip install -e .

🔧 Setup with Amazon Q

Step 1: Locate Your MCP Configuration File

Amazon Q looks for MCP server configuration in:

Linux/WSL: ~/.aws/amazonq/mcp.json
macOS: ~/.aws/amazonq/mcp.json
Windows: %USERPROFILE%\.aws\amazonq\mcp.json

Step 2: Create/Edit the Configuration File

Create the directory if it doesn't exist:

mkdir -p ~/.aws/amazonq

Edit or create ~/.aws/amazonq/mcp.json:

For Linux/WSL:

{
  "mcpServers": {
    "doc_reader": {
      "command": "/full/path/to/amazon-q-web_search/.venv/bin/python",
      "args": ["/full/path/to/amazon-q-web_search/main.py"]
    }
  }
}

For macOS:

{
  "mcpServers": {
    "doc_reader": {
      "command": "/full/path/to/amazon-q-web_search/.venv/bin/python",
      "args": ["/full/path/to/amazon-q-web_search/main.py"]
    }
  }
}

For Windows:

{
  "mcpServers": {
    "doc_reader": {
      "command": "C:\\full\\path\\to\\amazon-q-web_search\\.venv\\Scripts\\python.exe",
      "args": ["C:\\full\\path\\to\\amazon-q-web_search\\main.py"]
    }
  }
}

💡 Tip: Replace /full/path/to/ with the actual path where you cloned the repository.

Step 3: Verify Installation

Start Amazon Q CLI:
```
q chat
```

Check if MCP server is loaded:

/mcp

You should see:

doc_reader
  - read_web_documentation
  - get_documentation_links
  - get_page_structure
  - extract_code_examples
  - read_multiple_docs

If not loaded:
- Check the file path in mcp.json is correct
- Restart Amazon Q CLI
- Check logs: q chat logdump

🚀 Usage

Basic Example

In Amazon Q CLI, simply ask about documentation:

I'm having issues with Razorpay routes. Can you help me understand how they work?
Documentation: https://razorpay.com/docs/

Amazon Q will:

✅ Read the main documentation page
✅ Extract all available links
✅ Intelligently identify the "Routes" link
✅ Navigate to the Routes documentation
✅ Provide you with accurate information

More Examples

Python Documentation:

Can you explain Python asyncio event loops?
Documentation: https://docs.python.org/3/library/asyncio.html

FastAPI Tutorial:

How do I create a basic FastAPI application?
Documentation: https://fastapi.tiangolo.com/

AWS Lambda:

How do I create a Lambda function with Python?
Documentation: https://docs.aws.amazon.com/lambda/

🛠 Available Tools

Amazon Q intelligently chains these tools to navigate documentation:

1. `read_web_documentation`

Fetches and extracts clean documentation content from a web page.

Parameters:

url (required): The URL of the documentation page
output_format (optional): "markdown" (default) or "text"

Returns: Extracted documentation content with title and metadata

2. `get_documentation_links`

Extracts all links from a documentation page with optional filtering.

Parameters:

url (required): The URL of the documentation page
filter_pattern (optional): Pattern to filter links (e.g., "api", "guide")

Returns: List of links found on the page

3. `get_page_structure`

Extracts the heading structure and table of contents from a documentation page.

Parameters:

url (required): The URL of the documentation page

Returns: Hierarchical structure of headings on the page

4. `extract_code_examples`

Extracts all code blocks from a documentation page.

Parameters:

url (required): The URL of the documentation page

Returns: All code blocks found with their detected languages

5. `read_multiple_docs`

Reads multiple documentation pages and combines their content.

Parameters:

urls (required): List of documentation URLs (max 10)

Returns: Combined content from all pages

📁 Project Structure

amazon-q-web_search/
├── main.py              # Entry point
├── pyproject.toml       # Project configuration
├── README.md            # This file
├── run_mcp.sh           # Startup script (Linux/macOS)
└── src/
    ├── __init__.py      # Package initialization
    ├── server.py        # MCP server initialization
    ├── config.py        # Configuration constants
    ├── fetcher.py       # HTTP fetching logic
    ├── extractor.py     # HTML content extraction
    ├── formatters.py    # Output formatting
    └── tools.py         # MCP tool definitions

⚙️ Configuration

Edit src/config.py to customize behavior:

Setting	Default	Description
`HTTP_TIMEOUT`	30.0s	Request timeout in seconds
`MAX_CONTENT_LENGTH`	10MB	Maximum content size in bytes
`USER_AGENT`	Custom	HTTP User-Agent string
`REMOVE_TAGS`	Various	HTML tags to remove during extraction
`CONTENT_SELECTORS`	Various	Selectors for finding main content

🐛 Troubleshooting

MCP Server Not Loading

Check configuration:

cat ~/.aws/amazonq/mcp.json

Verify paths are correct:

Use absolute paths, not relative
Check that Python executable exists
Check that main.py exists

Test server manually:

cd /path/to/amazon-q-web_search
.venv/bin/python main.py

Check Amazon Q logs:

q chat logdump

Server Starts But Tools Don't Work

Verify dependencies are installed:

cd /path/to/amazon-q-web_search
.venv/bin/python -c "import httpx, bs4, markdownify; print('OK')"

Reinstall dependencies:

uv sync --reinstall

Connection Timeout

Increase timeout in settings:

q settings mcp.initTimeout 60000

📚 Dependencies

Package	Purpose
httpx	Async HTTP client for fetching web pages
beautifulsoup4	HTML parsing and navigation
lxml	Fast XML/HTML parser
markdownify	HTML to Markdown conversion
mcp	Model Context Protocol SDK

⚠️ Limitations

Limit	Value
Maximum content size	10MB per page
Maximum URLs per batch	10
Request timeout	30 seconds
Content type	HTML only

🤝 Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

Fork the repository
Create your feature branch (git checkout -b feature/AmazingFeature)
Commit your changes (git commit -m 'Add some AmazingFeature')
Push to the branch (git push origin feature/AmazingFeature)
Open a Pull Request

📄 License

This project is licensed under the MIT License - see the LICENSE file for details.

💬 Support

📫 Open an Issue for bug reports or feature requests
⭐ Star this repo if you find it useful!

Available Tools

5 tools

extract_code_examplesA

Extracts all code examples/blocks from a documentation page.

This tool specifically targets code blocks in documentation, useful for
finding implementation examples, snippets, and code samples.

Args:
    url: The URL of the documentation page

Returns:
    All code blocks found on the page with their detected languages

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full responsibility. It states it extracts all code blocks and returns them with detected languages, but does not disclose potential failures, format, or side effects. Adequate but could be more detailed.

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 two sentences plus an Args and Returns section. It is front-loaded with the core purpose and contains no fluff.

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?

The tool is simple with one parameter and an output schema. The description covers the main behavior and return values. Missing details on errors or edge cases, but overall complete for the context.

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?

With schema description coverage at 0%, the description adds value by specifying the parameter as 'The URL of the documentation page'. For a single simple parameter, this is sufficient.

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 verb 'Extracts' and the resource 'code examples/blocks from a documentation page'. It distinguishes from siblings (e.g., get_documentation_links, get_page_structure) by specifying extraction of code blocks specifically.

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 implies usage for finding implementation examples and code snippets, but does not explicitly exclude alternatives or state when not to use it. It provides enough context to differentiate from sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_documentation_linksA

Extracts all links from a documentation page, useful for discovering related docs.

This tool helps navigate documentation by finding all links on a page,
optionally filtering by a pattern.

Args:
    url: The URL of the documentation page
    filter_pattern: Optional pattern to filter links (e.g., "api", "guide")

Returns:
    List of links found on the page

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes
`filter_pattern`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

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. It does not disclose potential behavioral traits such as error handling, handling of relative URLs, JavaScript-rendered content, rate limiting, or authentication needs. The description is minimal and lacks caveats about limitations.

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 two short paragraphs and a structured 'Args' and 'Returns' section. The first sentence immediately conveys the main purpose, and every sentence adds value. No wasted words.

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 low complexity (2 parameters, none required unless url), no annotations, and the existence of an output schema (which reduces the need to explain return values), the description is largely complete. It covers the inputs and basic behavior. Minor gaps include lack of error scenarios or edge cases, but these are acceptable for a simple extraction tool.

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 description coverage is 0%, so the description must compensate. The description includes an 'Args' section that explains 'url' as the documentation page URL and 'filter_pattern' as an optional pattern with examples ('api', 'guide'). This adds meaning beyond the schema, though the pattern format (regex vs substring) is not specified. Overall, it provides useful guidance.

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 extracts all links from a documentation page, which is specific and actionable. The name and description together make it obvious this is for link discovery, distinguishing it from siblings like 'get_page_structure' which handles structure, and 'extract_code_examples' which handles code. While not explicit, the differentiation is clear from context.

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 mentions it's 'useful for discovering related docs,' which implies a typical use case. However, it does not provide explicit guidance on when not to use this tool or how it compares to siblings. No alternatives or exclusions are mentioned, leaving the agent to infer context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_page_structureA

Extracts the heading structure and table of contents from a documentation page.

This tool helps understand the organization of a documentation page by
extracting all headings and their hierarchy.

Args:
    url: The URL of the documentation page

Returns:
    Hierarchical structure of headings on the page

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must fully disclose behavior, but it only states what the tool does. It fails to mention potential issues like invalid URLs, authentication needs, or rate limits. The behavioral transparency is minimal.

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 three clear sentences plus structured Args/Returns sections. Every sentence adds value, and the most important information is front-loaded.

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 (one parameter, clear output) and the existence of an output schema (inferred), the description covers the core functionality. However, it could be more complete by specifying what happens with non-documentation pages or error conditions.

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 description coverage is 0%, so the description compensates by adding context: 'The URL of the documentation page' clarifies the expected input beyond the schema's bare 'url' field. It adds meaningful, though basic, guidance.

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 starts with a clear verb ('Extracts') and resource ('heading structure and table of contents'), making the tool's function immediately understandable. It distinguishes itself from sibling tools like 'extract_code_examples' by focusing specifically on page organization.

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?

The description implies use when understanding page organization, but it does not explicitly state when to prefer this tool over alternatives like get_documentation_links or read_web_documentation. No guidance on when not to use it is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_multiple_docsA

Reads multiple documentation pages and combines their content.

This tool fetches and extracts content from multiple URLs, useful when
documentation is spread across several pages.

Args:
    urls: List of documentation URLs to read

Returns:
    Combined content from all pages

ParametersJSON Schema

Name	Required	Description	Default
`urls`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full responsibility. It only states it 'fetches and extracts content' without disclosing behavioral details like error handling, caching, rate limits, or order of combination.

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-loads the purpose, and uses a clear structure with Args/Returns. Every sentence adds value.

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 simple tool with one parameter and an output schema, the description covers the essentials. It lacks details on error handling and combination specifics, but overall it is adequate.

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?

The description adds a qualifier ('documentation URLs') beyond the schema's array-of-strings definition, but it is minimal and the schema is straightforward.

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 it reads multiple documentation pages and combines their content, using a specific verb and resource. It distinguishes itself from sibling tools like read_web_documentation (singular) and get_page_structure.

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?

It provides clear context: 'useful when documentation is spread across several pages.' However, it does not explicitly state when not to use it or mention alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_web_documentationA

Fetches and extracts clean documentation content from a web page.

This tool is designed to read documentation websites and extract the main
content in a clean, readable format suitable for analysis.

Args:
    url: The URL of the documentation page to read
    output_format: Output format - "markdown" (default) or "text"

Returns:
    Extracted documentation content with title and metadata

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes
`output_format`	No		markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

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 discloses that it fetches and extracts content, and specifies output formats and return content (title and metadata). However, it does not mention potential issues like rate limits, error handling for non-documentation pages, or behavior with non-text content. The disclosure is adequate but not exhaustive.

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 two paragraphs and an Args/Returns block. Every sentence adds value: verb+resource, intended use, parameter explanations, and return description. No unnecessary text.

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?

Given the tool's simplicity (two parameters, one required), the existence of an output schema, and sibling tools providing context, the description is complete. It covers purpose, parameters, return values, and intended use. No gaps are apparent.

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 input schema has 0% description coverage, but the description compensates by explaining the 'url' parameter (URL of the documentation page) and the 'output_format' parameter (options: 'markdown' default or 'text'). This adds meaning beyond the schema's bare property definitions.

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 fetches and extracts clean documentation content from a web page. It uses a specific verb and resource (reading documentation), and the name aligns with its purpose. While it doesn't explicitly distinguish from sibling tools like extract_code_examples, the description implies it is for the main content, which is distinct enough.

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 says it is 'designed to read documentation websites', which implies appropriate usage. However, it provides no explicit guidance on when to use this tool versus alternatives (e.g., using get_page_structure for structural details). The context is implied but not directive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.1.0Jun 15, 2026
- First observedextract_code_examples
- First observedget_documentation_links
- First observedget_page_structure
- First observedread_multiple_docs
- First observedread_web_documentation

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Scored 2026-06-16 03:31 across 5 tools

Disambiguation5/5

Each tool targets a distinct aspect of documentation: code blocks, links, page structure, single page content, and multiple pages. Descriptions clearly differentiate them, avoiding overlap.

Naming Consistency5/5

All tool names use snake_case with a clear verb_noun pattern (e.g., extract_code_examples, get_documentation_links), providing a predictable and consistent naming scheme.

Tool Count5/5

With 5 tools, the server is well-scoped: it covers all essential operations for documentation reading (single/multiple pages, code, links, structure) without unnecessary extras.

Completeness5/5

The tool set covers the core functionalities needed for a documentation reader: content extraction, structure, links, and code examples. Minor features like search are absent but not essential for the stated purpose.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

ScrapeGraphAI-scrapegraph-mcpOAuth
ai.smithery
Enable language models to perform advanced AI-powered web scraping with enterprise-grade reliabili…
Web Scraping RAG Systems
2106
Brainiall Web A
com.brainiall
Web search, URL content extraction to Markdown, site mapping, and recursive web crawler.
Browser Automation Web Scraping
51
TinyFish AI Web AgentOAuth
ai.mino
AI-powered web automation. Navigate websites using AI agents for one page or a thousand
Browser Automation Autonomous Agents Web Scraping
2
TinyFish AI Web AgentOAuth
ai.tinyfish.agent
AI-powered web automation. Navigate websites using AI agents for one page or a thousand
Browser Automation Agent Orchestration Web Scraping
2

Related MCP Servers

Documentation MCP Server
Documentation Access Web Scraping Search
wuyuwenj
F
license
Not graded
quality
D
maintenance
Scrapes and indexes documentation websites to provide AI assistants with searchable access to documentation content, API references, and code examples through configurable URL crawling.
Updated 9 months ago (2025-12-24 12:32 UTC)
-
Nexus MCP Server
Search Web Scraping Browser Automation
rcdelacruz
A
license
A
quality
Not graded
maintenance
Enables hybrid web search and intelligent content extraction, combining semantic search with documentation-optimized reading that strips noise and returns clean, token-efficient context for AI agents.
Updated 6 months ago (2026-03-08 01:55 UTC)
2
-
Crawl4AI RAG MCP Server
RAG Systems Web Scraping Vector Databases
Rob-P-Smith
F
license
Not graded
quality
D
maintenance
Enables AI assistants to crawl websites, extract and store web content with semantic search capabilities using vector embeddings, and retrieve information through natural language queries with tag-based filtering and intelligent content cleaning.
Updated a year ago (2025-10-17 19:40 UTC)
-
Spider MCP Server
Web Scraping Documentation Access Code Analysis
oeo
F
license
Not graded
quality
D
maintenance
Enables crawling and extracting clean content from documentation websites with optional LLM-powered analysis for intelligent summaries, code example extraction, and content classification.
Updated a year ago (2025-08-05 18:30 UTC)
-

🌐 Amazon Q Web Documentation Reader

MCP Server for Intelligent Web Content Extraction

✨ Features

🎯 How It Works

📦 Installation

Prerequisites

Step 1: Clone the Repository

Step 2: Install Dependencies

🔧 Setup with Amazon Q

Step 1: Locate Your MCP Configuration File

Step 2: Create/Edit the Configuration File

Step 3: Verify Installation

🚀 Usage

Basic Example

More Examples

🛠 Available Tools

1. read_web_documentation

2. get_documentation_links

3. get_page_structure

4. extract_code_examples

5. read_multiple_docs

📁 Project Structure

⚙️ Configuration

🐛 Troubleshooting

MCP Server Not Loading

Server Starts But Tools Don't Work

Connection Timeout

📚 Dependencies

⚠️ Limitations

🤝 Contributing

📄 License

💬 Support

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

1. `read_web_documentation`

2. `get_documentation_links`

3. `get_page_structure`

4. `extract_code_examples`

5. `read_multiple_docs`