This MCP server provides comprehensive broken link checking capabilities for websites:
Check Single Page Links: Scan all links on a specific HTML page to identify broken links with detailed status information
Check Entire Sites: Recursively crawl and validate all links across multiple pages of a website
Detailed Reporting: Receive comprehensive JSON reports including HTTP status codes, broken reasons, link metadata, and summary statistics (total, working, and broken link counts)
Flexible Configuration: Options to exclude external links, respect robots.txt and meta robots tags, and control crawl rate with configurable maximum concurrent requests per host
Multiple Deployment Options: Supports both local stdio transport for Claude Desktop integration and remote HTTP/SSE deployment with production-ready features like process managers, reverse proxies, and monitoring
Click on "Deploy 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., "@Broken Link Checker MCP Server check all links on our homepage https://example.com for any broken ones"
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 broken link checking capabilities using the broken-link-checker library.
Check Single Page Links: Scan all links on a single HTML page for broken links
Check Entire Site: Recursively crawl and check all links across an entire website
Detailed reporting including HTTP status codes, broken reasons, and link metadata
Support for excluding external links and respecting robots.txt
Two deployment modes: Local stdio or Remote HTTP/SSE
Related MCP server: siteone-mcp-server
npm installUse index.js for local Claude Desktop integration.
Use server.js for remote deployment with ngrok or similar proxy services.
Add this server to your Claude Desktop configuration file:
MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"broken-link-checker": {
"command": "node",
"args": ["/Users/davinoishi/Documents/Projects-AI/BLC/index.js"]
}
}
}Make sure to update the path to match your actual installation directory.
After updating the configuration, restart Claude Desktop for the changes to take effect.
The MCP server provides two main tools:
check_page_linksCheck all links on a single HTML page.
Parameters:
url (required): The URL of the page to check
excludeExternalLinks (optional): If true, only check internal links (default: false)
honorRobotExclusions (optional): If true, respect robots.txt (default: true)
Example:
Can you check the links on https://example.com for any broken links?check_siteRecursively crawl and check all links across an entire website.
Parameters:
url (required): The starting URL of the site to check
excludeExternalLinks (optional): If true, only check internal links (default: false)
honorRobotExclusions (optional): If true, respect robots.txt (default: true)
maxSocketsPerHost (optional): Maximum concurrent requests per host (default: 1)
Example:
Can you crawl https://example.com and check all pages for broken links?For remote deployments (e.g., deploying on a VPS and connecting via ngrok), use the HTTP/SSE server:
# Start the HTTP/SSE server (default port 3000)
npm run start:http
# Or specify a custom port
PORT=8080 npm run start:httpThe server will start on http://localhost:3000 (or your specified port).
# Install ngrok if you haven't already
npm install -g ngrok
# Expose your local server
ngrok http 3000ngrok will provide you with a public URL like: https://abc123.ngrok.io
Update your Claude Desktop configuration to use the HTTP/SSE transport:
MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"broken-link-checker": {
"url": "https://your-ngrok-url.ngrok.io/sse"
}
}
}Replace your-ngrok-url.ngrok.io with your actual ngrok URL.
Check the health endpoint: https://your-ngrok-url.ngrok.io/health
Restart Claude Desktop
Ask Claude to check links on a webpage
You can configure the server using environment variables:
# Copy the example environment file
cp .env.example .env
# Edit .env with your settings
PORT=3000
HOST=0.0.0.0For production deployments, consider:
Use a process manager (PM2, systemd):
npm install -g pm2
pm2 start server.js --name broken-link-checker-mcp
pm2 save
pm2 startupUse a reverse proxy (nginx, Caddy) for HTTPS
Add authentication if exposing publicly
Monitor logs and resource usage
Both tools return JSON with the following structure:
{
"summary": {
"totalLinks": 100,
"brokenLinks": 5,
"workingLinks": 95
},
"brokenLinks": [
{
"url": "https://example.com/broken-page",
"base": "https://example.com",
"broken": true,
"brokenReason": "HTTP_404",
"http": {
"statusCode": 404
}
}
]
}The main server code is in index.js. The server uses:
@modelcontextprotocol/sdk for MCP protocol implementation
broken-link-checker for link checking functionality
MIT
Check all links on a single HTML page for broken links. Returns detailed information about each link found including broken status, HTTP status codes, and reasons for failure.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the page to check for broken links | |
| excludeExternalLinks | No | If true, only check internal links (default: false) | |
| honorRobotExclusions | No | If true, respect robots.txt and meta robots tags (default: true) |
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 describes the operation (checking links for broken status) and the return format (detailed information about each link), but doesn't mention important behavioral aspects like rate limits, timeout behavior, authentication requirements, or what constitutes a 'broken' link. It adds some value but leaves significant gaps.
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 perfectly concise with two sentences that each earn their place: the first states the core functionality, and the second describes the return format. There's no wasted language, and the information is front-loaded with the primary purpose.
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 no annotations and no output schema, the description provides basic operational context but lacks important details about the tool's behavior, error handling, and return format specifics. For a tool that performs network operations and returns complex results, more information about limitations, performance characteristics, and output structure would be beneficial.
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 schema description coverage is 100%, so all parameters are well-documented in the schema itself. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions, so it meets the baseline for high schema coverage without providing additional semantic context.
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 ('check all links on a single HTML page for broken links') and distinguishes it from the sibling tool 'check_site' by specifying it's for a single page rather than an entire site. It includes both the verb ('check') and resource ('links on a single HTML page') with precise scope.
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 clear context about what the tool does (single page link checking), which implicitly differentiates it from the sibling 'check_site' tool that presumably checks an entire site. However, it doesn't explicitly state when to use this tool versus 'check_site' or provide any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recursively crawl and check all links across an entire website. This will scan multiple pages and check all internal and external links found. Use with caution on large sites as it may take significant time.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The starting URL of the site to check | |
| excludeExternalLinks | No | If true, only check internal links (default: false) | |
| honorRobotExclusions | No | If true, respect robots.txt and meta robots tags (default: true) | |
| maxSocketsPerHost | No | Maximum concurrent requests per host (default: 1) |
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 behavioral traits: the recursive crawling nature, scanning of multiple pages, checking of both internal and external links, and the performance warning about time consumption on large sites. This gives the agent important context about what to expect from this 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 perfectly concise and well-structured in just two sentences. The first sentence clearly states the tool's purpose and scope, while the second provides important usage guidance. Every word earns its place with no redundancy or unnecessary 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 (recursive crawling operation with performance implications), no annotations, and no output schema, the description does a good job of providing essential context. It explains what the tool does, its scope, and important behavioral considerations. However, it doesn't describe what the output looks like or any error conditions, which would be helpful given the absence of an output schema.
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, so all parameters are well-documented in the schema itself. The description doesn't add any additional parameter semantics beyond what's already in the schema descriptions. The baseline score of 3 is appropriate when the schema does the heavy lifting of parameter 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 tool's purpose with specific verbs ('recursively crawl and check all links') and resource ('across an entire website'). It distinguishes from the sibling tool 'check_page_links' by emphasizing it checks 'all links across an entire website' rather than just a single page.
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 clear context for when to use this tool ('Use with caution on large sites as it may take significant time'), which helps the agent understand performance implications. However, it doesn't explicitly state when to use the alternative 'check_page_links' tool versus this one, nor does it provide exclusion criteria beyond the caution about large sites.
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.
check_page_linkscheck_siteScored across 2 tools
The two tools have clearly distinct purposes: check_page_links targets a single HTML page, while check_site handles an entire website with recursive crawling. There is no overlap in scope or functionality, making it easy for an agent to choose the appropriate tool based on the task.
Both tools follow a consistent verb_noun pattern (check_page_links and check_site), using the same verb 'check' and descriptive nouns that clearly indicate their targets. The naming is predictable and readable throughout.
With only two tools, the server feels thin for a broken link checker domain. While the tools cover single-page and site-wide checks, there are likely missing operations such as checking specific links, managing crawl settings, or handling reports, which could limit agent workflows.
The tools provide basic coverage for checking links on a page or site, but there are notable gaps. For example, there is no tool to check individual links, configure crawl parameters, or retrieve historical results, which might be expected in a more complete link-checking surface.
Crawl a site for broken links, 404s, dead images and redirect chains, with the page each is on
Scan a web page for accessibility, security, privacy, quality and SEO issues, with fixes.
Read, screenshot, diff, verify and audit any URL: SEO, links, sitemaps, schema, a11y.
Audit public webpages and supplied markup for HTML, CSS, SEO, JSON-LD, and link issues.