Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
LINKRESCUE_API_KEYNoAPI key for authenticated requests
LINKRESCUE_API_BASE_URLNoYour LinkRescue API base URLhttp://localhost:3000/api

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}
logging
{}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
extensions
{
  "io.modelcontextprotocol/ui": {}
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
check_broken_linksA

Scans a single URL or entire site/sitemap for broken links.

Returns a structured report with every broken link found, its HTTP status code, the page it was discovered on, link type (affiliate/external/internal), SEO impact rating, and estimated revenue loss.

Agents can pass the output directly to get_fix_suggestions for remediation steps.

monitor_linksA

Sets up ongoing broken-link monitoring for a website.

The monitor runs on a schedule (default: every 24 hours) and will detect new broken links, links that were fixed, and changes in site health score.

Returns a monitoring_id you can reference later to check status or cancel.

get_fix_suggestionsA

Given a broken links report, returns prioritized remediation suggestions.

Each suggestion includes the broken URL, a recommended action (update link, follow redirect, remove, etc.), a human-readable explanation, and a code snippet where applicable.

Accepts either the full JSON report from check_broken_links or just the broken_links array.

health_checkA

Confirms the LinkRescue MCP server is alive and can reach the backend API.

Use this to verify connectivity before running scans. Returns server status, API reachability, and current configuration.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription
example_reportSample broken-links scan report showing the output format of check_broken_links. Agents can read this resource to understand the data schema before calling tools.

TDQS

A4.4/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: check_broken_links for scanning, get_fix_suggestions for remediation, health_check for connectivity, and monitor_links for ongoing monitoring. There is no overlap or ambiguity in their functions.

Naming Consistency4/5

The tools follow a consistent verb_noun pattern (check_broken_links, get_fix_suggestions, monitor_links), with one minor deviation (health_check uses noun_verb). This is mostly consistent and readable.

Tool Count5/5

With 4 tools, the server is well-scoped for its purpose of broken link detection and management. Each tool earns its place, covering scanning, remediation, monitoring, and health checks without being too sparse or bloated.

Completeness5/5

The tool set provides complete coverage for the domain: check_broken_links for detection, get_fix_suggestions for remediation, monitor_links for ongoing tracking, and health_check for connectivity. There are no obvious gaps, and agents can follow a full workflow from scan to fix to monitoring.

Maintenance

ActivityMaintained
ResponsivenessNo issues