What can you do with this server?

The ReviewWebsite MCP Server connects AI assistants to the ReviewWebsite.com API for managing reviews and performing website analysis tasks, including: * Create, read, update, and delete website reviews * Extract structured data from websites based on instructions and templates * Convert URLs to Markdown format * Scrape full content from URLs * Extract various types of links with options for status codes and recursive scraping * Summarize URLs or entire websites using AI, with format and length options * Perform SEO analysis (keyword research, difficulty checking, traffic analysis, backlink data) * Customize AI models and parameters for content processing * Control wait behavior and timing for operations

Which integrations are available for this server?

Connects to the ReviewWebsite.com API hosted on GitHub, enabling AI assistants to create, read, update, and delete website reviews, as well as extract and process website content. Converts URLs to Markdown format using AI models, allowing for structured representation of website content that can be used in reviews and other applications. Provides access to the ReviewWebsite.com API, allowing AI assistants to create and manage website reviews, extract data from URLs, convert URLs to markdown, scrape content, extract links, and summarize websites. Integrates with ReviewWebsite.com's API using Swagger configuration, providing a standardized way to access review management and website data extraction features. Utilizes TypeScript for improved developer experience when interacting with the ReviewWebsite.com API, providing type safety for review management and website data extraction. Leverages Zod for schema validation when interacting with the ReviewWebsite.com API, ensuring proper data formatting for website reviews and content extraction.

How do I use ReviewWebsite MCP Server?

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., "@ReviewWebsite MCP Server summarize the article at https://example.com/blog/post using gpt-4o" 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.

de en es ja ko ru zh

ReviewWebsite MCP Server

by mrgoonie

Overview Schema Related Servers Score Discussions

TypeScript

Remote

ReviewWebsite.com - MCP Server

This project provides a Model Context Protocol (MCP) server that connects AI assistants to ReviewWebsite.com API to create and manage website reviews, extract data, convert URLs to markdown, and more.

Available Features

Create, read, update, and delete website reviews
Get available AI models
Convert URLs to Markdown using AI
Extract structured data from URLs using AI
Scrape URLs and extract content
Extract links from websites
Summarize URLs and websites using AI
SEO insights (keyword ideas, keyword difficulty, traffic analysis, backlinks)
Customize AI models and parameters
Control wait behavior and timing

ReviewWeb.site

Related MCP server: WebforAI Text Extractor

Supported Transports

"stdio" transport - Default transport for CLI usage
"Streamable HTTP" transport - For web-based clients
- Implement auth ("Authorization" headers with Bearer <token>)
~~"sse" transport~~ (Deprecated)
Write tests

How to use

CLI

# Get available AI models
npm run dev:cli -- get-ai-models --api-key "your-api-key"

# Create a new review
npm run dev:cli -- create-review --url "https://example.com" --instructions "Review this website" --api-key "your-api-key"

# Get a specific review by ID
npm run dev:cli -- get-review --review-id "review-id" --api-key "your-api-key"

# List all reviews
npm run dev:cli -- list-reviews --page 1 --limit 10 --api-key "your-api-key"

# Update a review
npm run dev:cli -- update-review --review-id "review-id" --url "https://example.com" --instructions "Updated instructions" --api-key "your-api-key"

# Delete a review
npm run dev:cli -- delete-review --review-id "review-id" --api-key "your-api-key"

# Convert URL to Markdown
npm run dev:cli -- convert-to-markdown --url "https://example.com" --model "gpt-4o" --api-key "your-api-key"

# Extract structured data from URL
npm run dev:cli -- extract-data --url "https://example.com" --instructions "Extract product information" --api-key "your-api-key"

# Scrape URL
npm run dev:cli -- scrape-url --url "https://example.com" --api-key "your-api-key"

# Extract links from URL
npm run dev:cli -- extract-links --url "https://example.com" --type "all" --api-key "your-api-key"

# Summarize URL
npm run dev:cli -- summarize-url --url "https://example.com" --model "gpt-4o" --api-key "your-api-key"

# Get keyword ideas for SEO
npm run dev:cli -- seo-keyword-ideas --keyword "digital marketing" --country "us" --search-engine "Google" --api-key "your-api-key"

# Check keyword difficulty
npm run dev:cli -- seo-keyword-difficulty --keyword "digital marketing" --country "us" --api-key "your-api-key"

# Analyze website traffic
npm run dev:cli -- seo-traffic --domain-or-url "example.com" --mode "subdomains" --country "us" --api-key "your-api-key"

# Get backlinks for a domain
npm run dev:cli -- seo-backlinks --domain "example.com" --api-key "your-api-key"

MCP Setup

For local configuration with stdio transport:

{
  "mcpServers": {
    "reviewwebsite": {
      "command": "node",
      "args": ["/path/to/reviewwebsite-mcp-server/dist/index.js"],
      "transportType": "stdio"
    }
  }
}

For remote HTTP configuration:

{
  "mcpServers": {
    "reviewwebsite": {
      "type": "http",
      "url": "http://localhost:8080/mcp"
    }
  }
}

Environment Variables for HTTP Transport:

You can configure the HTTP server using these environment variables:

MCP_HTTP_HOST: The host to bind to (default: 127.0.0.1)
MCP_HTTP_PORT: The port to listen on (default: 8080)
MCP_HTTP_PATH: The endpoint path (default: /mcp)

Source Code Overview

What is MCP?

Model Context Protocol (MCP) is an open standard that allows AI systems to securely and contextually connect with external tools and data sources.

This boilerplate implements the MCP specification with a clean, layered architecture that can be extended to build custom MCP servers for any API or data source.

Why Use This Boilerplate?

Production-Ready Architecture: Follows the same pattern used in published MCP servers, with clear separation between CLI, tools, controllers, and services.
Type Safety: Built with TypeScript for improved developer experience, code quality, and maintainability.
Working Example: Includes a fully implemented IP lookup tool demonstrating the complete pattern from CLI to API integration.
Testing Framework: Comes with testing infrastructure for both unit and CLI integration tests, including coverage reporting.
Development Tooling: Includes ESLint, Prettier, TypeScript, and other quality tools preconfigured for MCP server development.

Getting Started

Prerequisites

Node.js (>=18.x): Download
Git: For version control

Step 1: Clone and Install

# Clone the repository
git clone https://github.com/mrgoonie/reviewwebsite-mcp-server.git
cd reviewwebsite-mcp-server

# Install dependencies
npm install

Step 2: Run Development Server

Start the server in development mode with stdio transport (default):

npm run dev:server

Or with the Streamable HTTP transport:

npm run dev:server:http

This starts the MCP server with hot-reloading and enables the MCP Inspector at http://localhost:5173.

⚙️ Proxy server listening on port 6277 🔍 MCP Inspector is up and running at http://127.0.0.1:6274

When using HTTP transport, the server will be available at http://127.0.0.1:8080/mcp by default.

Step 3: Test the ReviewWebsite API Tools

Use the ReviewWebsite API tools via CLI:

# Get available AI models
npm run dev:cli -- get-ai-models --api-key "your-api-key"

# Create a review
npm run dev:cli -- create-review --url "https://example.com" --instructions "Review this website" --api-key "your-api-key"

# Convert URL to Markdown
npm run dev:cli -- convert-to-markdown --url "https://example.com" --model "gpt-4o" --api-key "your-api-key"

Architecture

This boilerplate follows a clean, layered architecture pattern that separates concerns and promotes maintainability.

Project Structure

src/
├── cli/              # Command-line interfaces
├── controllers/      # Business logic
├── resources/        # MCP resources: expose data and content from your servers to LLMs
├── services/         # External API interactions
├── tools/            # MCP tool definitions
├── types/            # Type definitions
├── utils/            # Shared utilities
└── index.ts          # Entry point

Layers and Responsibilities

CLI Layer (`src/cli/*.cli.ts`)

Purpose: Define command-line interfaces that parse arguments and call controllers
Naming: Files should be named <feature>.cli.ts
Testing: CLI integration tests in <feature>.cli.test.ts

Tools Layer (`src/tools/*.tool.ts`)

Purpose: Define MCP tools with schemas and descriptions for AI assistants
Naming: Files should be named <feature>.tool.ts with types in <feature>.types.ts
Pattern: Each tool should use zod for argument validation

Controllers Layer (`src/controllers/*.controller.ts`)

Purpose: Implement business logic, handle errors, and format responses
Naming: Files should be named <feature>.controller.ts
Pattern: Should return standardized ControllerResponse objects

Services Layer (`src/services/*.service.ts`)

Purpose: Interact with external APIs or data sources
Naming: Files should be named <feature>.service.ts
Pattern: Pure API interactions with minimal logic

Utils Layer (`src/utils/*.util.ts`)

Purpose: Provide shared functionality across the application
Key Utils:
- logger.util.ts: Structured logging
- error.util.ts: Error handling and standardization
- formatter.util.ts: Markdown formatting helpers

Development Guide

Development Scripts

# Start server in development mode (hot-reload & inspector)
npm run dev:server

# Run CLI in development mode
npm run dev:cli -- [command] [args]

# Build the project
npm run build

# Start server in production mode
npm run start:server

# Run CLI in production mode
npm run start:cli -- [command] [args]

Testing

# Run all tests
npm test

# Run specific tests
npm test -- src/path/to/test.ts

# Generate test coverage report
npm run test:coverage

Code Quality

# Lint code
npm run lint

# Format code with Prettier
npm run format

# Check types
npm run typecheck

Building Custom Tools

Follow these steps to add your own tools to the server:

1. Define Service Layer

Create a new service in src/services/ to interact with your external API:

// src/services/example.service.ts
import { Logger } from '../utils/logger.util.js';

const logger = Logger.forContext('services/example.service.ts');

export async function getData(param: string): Promise<any> {
	logger.debug('Getting data', { param });
	// API interaction code here
	return { result: 'example data' };
}

2. Create Controller

Add a controller in src/controllers/ to handle business logic:

// src/controllers/example.controller.ts
import { Logger } from '../utils/logger.util.js';
import * as exampleService from '../services/example.service.js';
import { formatMarkdown } from '../utils/formatter.util.js';
import { handleControllerError } from '../utils/error-handler.util.js';
import { ControllerResponse } from '../types/common.types.js';

const logger = Logger.forContext('controllers/example.controller.ts');

export interface GetDataOptions {
	param?: string;
}

export async function getData(
	options: GetDataOptions = {},
): Promise<ControllerResponse> {
	try {
		logger.debug('Getting data with options', options);

		const data = await exampleService.getData(options.param || 'default');

		const content = formatMarkdown(data);

		return { content };
	} catch (error) {
		throw handleControllerError(error, {
			entityType: 'ExampleData',
			operation: 'getData',
			source: 'controllers/example.controller.ts',
		});
	}
}

3. Implement MCP Tool

Create a tool definition in src/tools/:

// src/tools/example.tool.ts
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { z } from 'zod';
import { Logger } from '../utils/logger.util.js';
import { formatErrorForMcpTool } from '../utils/error.util.js';
import * as exampleController from '../controllers/example.controller.js';

const logger = Logger.forContext('tools/example.tool.ts');

const GetDataArgs = z.object({
	param: z.string().optional().describe('Optional parameter'),
});

type GetDataArgsType = z.infer<typeof GetDataArgs>;

async function handleGetData(args: GetDataArgsType) {
	try {
		logger.debug('Tool get_data called', args);

		const result = await exampleController.getData({
			param: args.param,
		});

		return {
			content: [{ type: 'text' as const, text: result.content }],
		};
	} catch (error) {
		logger.error('Tool get_data failed', error);
		return formatErrorForMcpTool(error);
	}
}

export function register(server: McpServer) {
	server.tool(
		'get_data',
		`Gets data from the example API, optionally using \`param\`.
Use this to fetch example data. Returns formatted data as Markdown.`,
		GetDataArgs.shape,
		handleGetData,
	);
}

4. Add CLI Support

Create a CLI command in src/cli/:

// src/cli/example.cli.ts
import { program } from 'commander';
import { Logger } from '../utils/logger.util.js';
import * as exampleController from '../controllers/example.controller.js';
import { handleCliError } from '../utils/error-handler.util.js';

const logger = Logger.forContext('cli/example.cli.ts');

program
	.command('get-data')
	.description('Get example data')
	.option('--param <value>', 'Optional parameter')
	.action(async (options) => {
		try {
			logger.debug('CLI get-data called', options);

			const result = await exampleController.getData({
				param: options.param,
			});

			console.log(result.content);
		} catch (error) {
			handleCliError(error);
		}
	});

5. Register Components

Update the entry points to register your new components:

// In src/cli/index.ts
import '../cli/example.cli.js';

// In src/index.ts (for the tool)
import exampleTool from './tools/example.tool.js';
// Then in registerTools function:
exampleTool.register(server);

Debugging Tools

MCP Inspector

Access the visual MCP Inspector to test your tools and view request/response details:

Run npm run dev:server
Open http://localhost:5173 in your browser
Test your tools and view logs directly in the UI

Server Logs

Enable debug logs for development:

# Set environment variable
DEBUG=true npm run dev:server

# Or configure in ~/.mcp/configs.json

Publishing Your MCP Server

When ready to publish your custom MCP server:

Update package.json with your details
Update README.md with your tool documentation
Build the project: npm run build
Test the production build: npm run start:server
Publish to npm: npm publish

License

MIT License

{
	"reviewwebsite": {
		"environments": {
			"DEBUG": "true",
			"REVIEWWEBSITE_API_KEY": "your-api-key-here"
		}
	}
}

Note: For backward compatibility, the server will also recognize configurations under the full package name (reviewwebsite-mcp-server) or the unscoped package name (reviewwebsite-mcp-server) if the reviewwebsite key is not found. However, using the short reviewwebsite key is recommended for new configurations.

Available Tools

16 tools

convert_multiple_to_markdownB

Convert multiple URLs to Markdown using AI via ReviewWeb.site API. Turn multiple web pages into LLM-friendly content.

ParametersJSON Schema

Name	Required	Description
`urls`	Yes	List of URLs to convert to Markdown
`model`	No	AI model to use for conversion
`instructions`	No	Optional custom conversion guidance for the AI
`delayAfterLoad`	No	Optional delay after page load in milliseconds
`maxLinks`	No	Maximum number of URLs to process
`debug`	No	Whether to enable debug mode
`api_key`	No	Your ReviewWebsite API key

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are present, so the description carries full burden. It only mentions 'using AI' and 'via ReviewWeb.site API', but does not disclose behavioral traits like rate limits, authorization requirements, or what happens during conversion (e.g., destructive changes).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is only two sentences, no redundancy. Front-loaded with the core action. Concise but could be slightly more informative without extra length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters, no output schema, and no annotations, the description lacks crucial context. It does not explain the output format, the AI model selection, or how the API key is used, making it incomplete for effective use.

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?

Input schema has 100% description coverage for all 7 parameters. The description adds no additional meaning beyond the schema, so it meets the baseline of 3 for high coverage.

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?

Description clearly states 'Convert multiple URLs to Markdown using AI', identifying the verb (convert) and resource (multiple URLs to Markdown). It implicitly distinguishes from sibling 'convert_to_markdown' by specifying 'multiple' and 'multiple web pages'.

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?

No explicit guidance on when to use this tool versus alternatives. Does not mention the single-URL sibling or provide usage context such as prerequisites or typical scenarios.

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

convert_to_markdownB

Convert a URL to Markdown using AI via ReviewWeb.site API. Turn a web page into LLM-friendly content.

ParametersJSON Schema

Name	Required	Description
`url`	Yes	The URL to convert to Markdown
`model`	No	AI model to use for conversion
`instructions`	No	Optional custom conversion guidance for the AI
`delayAfterLoad`	No	Optional delay after page load in milliseconds
`debug`	No	Enable debug mode for detailed logging
`api_key`	No	Your ReviewWebsite API key

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are present, so the description carries the full burden. It mentions using an AI API but does not disclose behavioral details such as network requests, API key requirements, potential costs, rate limits, or output format beyond 'Markdown'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is only two sentences, clear and direct. The second sentence is slightly redundant with the first but does not significantly harm conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 6 parameters, no output schema, and no annotations, the description is too brief. It does not explain return values, API key necessity, model options, or how instructions affect output, leaving significant gaps for effective tool use.

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?

With 100% schema description coverage, the baseline is 3. The description does not add extra meaning beyond the schema, such as hints about default model or the effect of instructions.

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 'Convert a URL to Markdown using AI via ReviewWeb.site API', specifying the verb 'convert', resource 'URL to Markdown', and distinguishing from sibling tools like convert_multiple_to_markdown (multiple URLs) and scrape_url (raw HTML).

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 implies usage for making web content LLM-friendly but lacks explicit when-to-use or when-not-to-use guidance. No comparison to alternatives like summarize_url or extract_data is provided.

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

extract_dataB

Extract structured data (JSON) from a web page URL using AI via ReviewWeb.site API.

ParametersJSON Schema

Name	Required	Description
`url`	Yes	The URL to extract data from
`instructions`	Yes	Instructions for the AI on what data to extract
`jsonTemplate`	Yes	JSON template for structuring the extracted data
`systemPrompt`	No	Optional system prompt to guide the AI
`model`	No	AI model to use for extraction
`delayAfterLoad`	No	Optional delay after page load in milliseconds
`recursive`	No	If true, recursively scrape all internal URLs and extract data from each
`debug`	No	Enable debug mode for detailed logging
`api_key`	No	Your ReviewWebsite API key

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, and the description fails to disclose important behavioral traits such as API key requirements, rate limits, error handling, or the implications of the 'recursive' flag. The tool's reliance on an external API is mentioned, but without details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no unnecessary words. However, it could be slightly expanded to include key details without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (9 parameters, no output schema, no annotations), the description is insufficient. It does not explain return format details, required authentication, or the behavior of optional features like 'recursive' or 'debug'.

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 input schema already provides 100% coverage with clear descriptions for all 9 parameters. The description adds no additional meaning beyond what the schema offers, so a baseline score of 3 is appropriate.

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 action (extract), output format (structured JSON), source (web page URL), method (using AI), and service (ReviewWeb.site API). It effectively distinguishes from siblings like 'scrape_url' and 'extract_links'.

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?

No guidance on when to use this tool vs alternatives. With many sibling tools (scrape_url, convert_to_markdown, etc.), the description lacks context for when extraction is preferred over raw scraping or summarization.

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

extract_data_multipleB

Extract structured data (JSON) from multiple web page URLs using AI via ReviewWeb.site API.

ParametersJSON Schema

Name	Required	Description
`urls`	Yes	List of URLs to extract data from
`instructions`	Yes	Instructions for the AI to extract data from the websites
`jsonTemplate`	Yes	JSON schema template for the extracted data output
`systemPrompt`	No	System prompt for the AI
`model`	No	AI model to use for extraction
`delayAfterLoad`	No	Optional delay after page load in milliseconds
`debug`	No	Whether to enable debug mode
`api_key`	No	Your ReviewWebsite API key

TDQS

B3/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only mentions 'using AI' but omits details on cost, rate limits, mutability (read-only), error handling, or parallel execution. The description is too brief to inform safe usage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with no redundant information. It is concise, though it lacks structural elements like bullet points or sections that could improve scannability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 8 parameters, no output schema, and no annotations, the description is severely lacking. It does not explain return format, error handling, processing order (sequential vs. parallel), or API key requirement. This level of detail is insufficient for an agent to use the tool correctly.

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?

Schema coverage is 100% with descriptive field names and descriptions. The description adds no additional parameter context beyond what the schema already provides, so it meets the baseline but does not exceed it.

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 action (extract structured data as JSON), the resource (multiple web page URLs), and the method (using AI via ReviewWeb.site API). It distinguishes from the sibling 'extract_data' which likely handles single URLs.

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?

No guidance on when to use this tool vs. alternatives like 'extract_data' or 'convert_multiple_to_markdown'. No prerequisites or context are mentioned, leaving the agent to infer usage.

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

extract_linksC

Extract all links from a HTML content of web page URL using ReviewWeb.site API.

ParametersJSON Schema

Name	Required	Description
`url`	Yes	The target URL to extract links from
`type`	No	Type of links to extract
`maxLinks`	No	Maximum number of links to return
`delayAfterLoad`	No	Delay in milliseconds after page load before extracting links
`getStatusCode`	No	Whether to get HTTP status codes for each link
`autoScrapeInternalLinks`	No	Whether to automatically scrape internal links
`debug`	No	Whether to enable debug mode
`api_key`	No	Your ReviewWebsite API key

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavior. It only mentions the API and extraction, but does not describe side effects, rate limits, or how parameters like delayAfterLoad affect behavior. Insufficient for a tool with many parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no wasted words, though the phrasing is slightly awkward. Could be more concise but acceptable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 8 parameters, no output schema, and no annotations, the description is too minimal. It does not explain return format, limitations, or how to effectively use parameters like autoScrapeInternalLinks. Incomplete for the tool's complexity.

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?

Schema coverage is 100% with descriptions for all parameters, so baseline is 3. The description does not add any additional meaning beyond the schema.

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?

Description clearly states it extracts links from HTML content of a web page URL, which distinguishes it from other tools like scrape_url or extract_data. The phrasing is slightly awkward but the purpose is clear.

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?

No guidance on when to use this tool vs alternatives like scrape_url or seo_*. Does not mention prerequisites or when not to use.

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

html_to_screenshotB

Convert HTML content to a screenshot image using ReviewWeb.site API. Renders raw HTML string via headless browser and returns screenshot as hosted URL or image data.

ParametersJSON Schema

Name	Required	Description	Default
`html`	Yes	Raw HTML string to render as a screenshot
`viewport_width`	No	Viewport width in pixels (100-3840)
`viewport_height`	No	Viewport height in pixels (100-2160)
`full_page`	No	Capture full page instead of just viewport
`output`	No	"url" returns hosted image URL, "buffer" returns base64 image data	url
`type`	No	Screenshot image format	png
`quality`	No	JPEG quality 1-100 (only used when type is jpeg)
`delay_after_load`	No	Milliseconds to wait after page load before taking screenshot
`api_key`	No	Your ReviewWebsite API key

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided, and the description only mentions 'renders via headless browser' and 'returns hosted URL or image data'. It does not disclose potential side effects, authentication needs (api_key is a parameter but not described as required for access), rate limits, or error handling behavior.

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?

Two sentences, front-loaded with the core purpose. No redundant words; every sentence adds value. Highly concise and structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 9 parameters and no output schema, the description should provide more context on tool behavior. It adequately states the core functionality but lacks details on result format, error states, or API authorization, making it moderately complete.

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?

Schema description coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema (only mentions 'raw HTML string' and output options). No parameter details are elaborated beyond what the schema already provides.

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 'Convert' and the resource 'HTML content to a screenshot image', and distinguishes from sibling tools (e.g., scrape_url for live URLs) by specifying raw HTML rendering via headless browser.

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?

No explicit guidance on when to use this tool versus alternatives (e.g., scrape_url, summarize_url). No prerequisites or exclusions mentioned, leaving the agent without decision support.

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

scrape_urlC

Scrape a URL and return HTML content using ReviewWeb.site API.

ParametersJSON Schema

Name	Required	Description
`url`	Yes	The URL to scrape
`delayAfterLoad`	No	Optional delay after page load in milliseconds
`api_key`	No	Your ReviewWebsite API key

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations, description must fully explain behavior. It only states scraping and returning HTML, omitting details like authentication (api_key), page load behavior (delayAfterLoad), rate limits, or whether JavaScript is rendered. The delayAfterLoad parameter hints at dynamic content, but not explicitly stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence is concise but lacks structure such as front-loading key details. It is efficient but omits important context like authentication, making it somewhat under-specified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, so description should explain return format. It states 'return HTML content' but lacks details on raw vs processed HTML, error handling, or pagination. Given 3 parameters and no annotations, the description is too minimal for full tool understanding.

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?

Schema coverage is 100%, so baseline is 3. Description does not add significant meaning beyond the schema; mentioning 'ReviewWeb.site API' indirectly explains the api_key parameter, but no further elaboration on url format or delayAfterLoad usage.

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?

Description clearly states it scrapes a URL and returns HTML content. Verb and resource are specific, but it doesn't differentiate from sibling tools like convert_to_markdown or extract_data, which have overlapping functionality.

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?

No guidance on when to use this tool versus alternatives. It doesn't mention that for markdown output convert_to_markdown might be better, or that extract_data is for structured data.

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

seo_backlinksB

Get backlinks for a domain using ReviewWeb.site API.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes	The domain to get backlinks for
`api_key`	No	Your ReviewWebsite API key

TDQS

B3/5.0

Behavior1/5

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

No annotations provided. The description lacks any behavioral details such as data freshness, rate limits, or required permissions. The agent gets no insight beyond the basic action.

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?

Single sentence that is direct and front-loaded with the action. No extraneous words, achieving maximum conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema and the description does not explain what data is returned (e.g., backlink list, count). With two parameters and no behavioral hints, the description is too minimal to be fully informative.

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?

Schema coverage is 100% with clear descriptions for 'domain' and 'api_key'. The description adds no additional meaning beyond what the schema already provides, meeting the baseline.

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 action ('Get backlinks') and the resource ('for a domain'), making the tool's purpose specific and distinct from sibling SEO tools.

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?

No guidance on when to use this tool versus alternatives like seo_traffic or seo_keyword_difficulty. The description does not provide any context for selection.

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

seo_keyword_difficultyC

Get keyword difficulty for a keyword using ReviewWeb.site API.

ParametersJSON Schema

Name	Required	Description
`keyword`	Yes	The keyword to check difficulty for
`country`	No	Country code (default: us)
`api_key`	No	Your ReviewWebsite API key

TDQS

C2.9/5.0

Behavior2/5

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

No annotations were provided, and the description does not disclose behavioral details such as API key requirements, rate limits, or the nature of the difficulty score. The mention of 'ReviewWeb.site API' is vague.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, very concise with no wasted words. However, it could benefit from slight expansion to add value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of an output schema and only three parameters, the description is too minimal. It does not explain what 'keyword difficulty' means or how the result is interpreted, leaving gaps for an AI agent.

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?

Schema coverage is 100%, so the input schema already describes each parameter. The description adds no additional insight beyond the schema, meeting the baseline for high coverage.

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 action 'Get keyword difficulty for a keyword', which is a specific verb+resource. It distinguishes from sibling SEO tools like seo_backlinks or seo_traffic but lacks additional context such as the output format.

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?

No guidance on when to use this tool versus alternatives (e.g., seo_keyword_ideas). The description does not mention prerequisites or context for invoking the tool.

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

seo_keyword_ideasB

Get keyword ideas for a keyword using ReviewWeb.site API.

ParametersJSON Schema

Name	Required	Description
`keyword`	Yes	The keyword to get ideas for
`country`	No	Country code (default: us)
`searchEngine`	No	Search engine to use (default: Google)
`api_key`	No	Your ReviewWebsite API key

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, and the description does not disclose any behavioral traits such as rate limits, authentication requirements, or return format beyond the schema.

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?

Single sentence, no wasted words, and front-loaded with the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 4 parameters, no output schema, and no annotations, the description is too brief. It lacks details on expected results, error cases, or usage constraints.

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?

Schema coverage is 100%, so the description adds no extra meaning beyond what is already in the parameter descriptions. Baseline of 3 is appropriate.

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 uses a specific verb 'Get' and resource 'keyword ideas' for a given keyword. It clearly distinguishes from sibling tools like seo_keyword_difficulty and seo_traffic.

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?

No guidance on when to use this tool versus alternatives, no exclusions, and no context on prerequisites or typical use cases.

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

seo_trafficC

Check traffic for a domain or URL using ReviewWeb.site API.

ParametersJSON Schema

Name	Required	Description
`domainOrUrl`	Yes	The domain or URL to check traffic for
`mode`	No	Mode to use (default: subdomains)
`country`	No	Country code (default: None)
`api_key`	No	Your ReviewWebsite API key

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations, the description carries full burden. It only states it uses ReviewWeb.site API but does not disclose any behavioral traits like rate limits, authentication requirements (though api_key param exists), or what the output represents. Lacks transparency for a non-trivial tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, efficient but perhaps too brief for a tool with four parameters. It is front-loaded and has no wasted words, but could benefit from a bit more detail without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given four parameters, no output schema, and complex sibling context, the description is insufficient. It does not explain the output format, required authentication (api_key), or how mode/country affect results. The tool feels underspecified.

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?

Schema coverage is 100%, so the schema already documents all parameters. The description adds minimal context (e.g., 'Check traffic') but does not provide additional meaning beyond what the schema offers. Baseline 3 is appropriate.

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 it checks traffic for a domain or URL. The verb 'Check' and resource 'traffic' are specific. It distinguishes from sibling tools like seo_backlinks or seo_keyword_difficulty, which focus on different metrics.

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 provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as having an API key, or scenarios where this tool is preferable over other SEO tools.

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

summarize_multiple_urlsC

Summarize multiple web page URLs using AI via ReviewWeb.site API.

ParametersJSON Schema

Name	Required	Description
`urls`	Yes	List of URLs to summarize
`instructions`	No	Custom instructions for the AI on how to summarize the content
`systemPrompt`	No	Custom system prompt to guide the AI
`model`	No	AI model to use for summarization
`delayAfterLoad`	No	Optional delay after page load in milliseconds
`maxLinks`	No	Maximum number of URLs to process
`maxLength`	No	Maximum length of each summary in words
`format`	No	Format of the summary (bullet points or paragraph)
`debug`	No	Whether to enable debug mode
`api_key`	No	Your ReviewWebsite API key

TDQS

C2.7/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It does not mention any behavioral aspects like API key requirement (though present in schema), rate limits, storage of content, or whether operation is read-only. The word 'summarize' implies generation, but no disclosure of potential costs or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise at one sentence, but lacks structure. Does not use front-loading of key info (e.g., what it returns). Every word is necessary but the sentence is incomplete for decision-making.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 10 parameters and no output schema, the description is severely incomplete. It fails to explain return format, error handling, whether summaries are returned as text or file, or any limits on URL count. A tool with such complexity needs far more context.

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?

Schema covers all 10 parameters with descriptions (100% coverage). Description adds no extra meaning beyond 'using AI', which is already implied by parameters like 'instructions' and 'systemPrompt'. Baseline score of 3 is appropriate as schema does the heavy lifting.

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?

Description clearly states verb 'summarize', resource 'multiple web page URLs', and names the API (ReviewWeb.site). However, it doesn't distinguish from sibling tools like 'summarize_url' or 'summarize_website' explicitly, which could cause confusion.

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?

No guidance on when to use this tool instead of siblings (e.g., single vs multiple URLs, vs extracting data or converting to markdown). Lacks any when-to-use, prerequisites, or exclusion criteria.

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

summarize_urlB

Summarize a web page URL using AI via ReviewWeb.site API.

ParametersJSON Schema

Name	Required	Description
`url`	Yes	The URL to summarize
`instructions`	No	Custom instructions for the AI on how to summarize the content
`systemPrompt`	No	Custom system prompt to guide the AI
`model`	No	AI model to use for summarization
`delayAfterLoad`	No	Optional delay after page load in milliseconds
`maxLength`	No	Maximum length of the summary in words
`format`	No	Format of the summary (bullet points or paragraph)
`debug`	No	Enable debug mode for detailed logging
`api_key`	No	Your ReviewWebsite API key

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided; description only mentions 'using AI via ReviewWeb.site API' without disclosing rate limits, authentication requirements (though api_key parameter exists), error handling, or behavioral traits beyond basic function.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that is clear and to the point, stating the core action. However, it could be slightly more efficient by integrating context about the API.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 9 parameters, no output schema, and no annotations, the description is insufficient. It doesn't explain return values, error scenarios, or how to properly use optional parameters for effective summarization.

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?

Schema description coverage is 100%, so baseline is 3. Description adds no extra parameter-level information beyond the schema; it doesn't elaborate on the purpose of 'instructions', 'systemPrompt', or 'model' in the summarization context.

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's function: summarizing a single web page URL using AI. It distinguishes from siblings like 'summarize_multiple_urls' and 'summarize_website' by focusing on a single URL.

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?

No guidance on when to use this tool versus alternatives such as 'scrape_url' or 'extract_data'. No when-not or prerequisites mentioned.

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

summarize_websiteC

Summarize a website (and its internal links) using AI via ReviewWeb.site API.

ParametersJSON Schema

Name	Required	Description
`url`	Yes	The main URL of the website to summarize
`instructions`	No	Custom instructions for the AI on how to summarize the content
`systemPrompt`	No	Custom system prompt to guide the AI
`model`	No	AI model to use for summarization
`delayAfterLoad`	No	Optional delay after page load in milliseconds
`maxLinks`	No	Maximum number of pages to process
`maxLength`	No	Maximum length of the summary in words
`format`	No	Format of the summary (bullet points or paragraph)
`debug`	No	Enable debug mode for detailed logging
`api_key`	No	Your ReviewWebsite API key

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are present, so the description carries the full burden for behavioral disclosure. It mentions 'using AI via ReviewWeb.site API' but does not describe side effects, cost implications, synchronous/asynchronous behavior, or how internal links are followed. The tool appears read-only, but this is not explicitly stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the core purpose. No redundant information, though it could benefit from expanding on key behavioral aspects without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 10 parameters, no output schema, and no annotations, the description is too lean. It does not explain return format, error handling, or authentication requirements beyond the api_key parameter, leaving significant gaps for the agent.

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?

Schema coverage is 100%, so the baseline is 3. The description adds no extra semantic context beyond the schema's parameter descriptions, such as clarifying how 'internal links' relate to maxLinks or how instructions/systemPrompt interact.

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 summarizes a website including its internal links using an AI API, distinguishing it from sibling tools like summarize_url (single URL) and summarize_multiple_urls (multiple URLs). However, it does not explicitly differentiate from scrape_url or extract_data, which could also produce summaries.

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?

No guidance is provided on when to use this tool versus alternatives like summarize_url or scrape_url. There is no mention of prerequisites, limitations, or best practices, leaving the agent to infer usage context.

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

url_get_after_redirectsC

Get URL after redirects using ReviewWeb.site API.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	URL to get after redirects
`api_key`	No	Your ReviewWebsite API key

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries full responsibility for behavioral disclosure. It only mentions the basic action of getting the URL after redirects but does not explain error handling (e.g., timeouts, 404s), whether it follows all redirect types, or the format of the response. This gap impairs the agent's ability to anticipate outcomes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no filler, which is concise. However, it lacks any structural elements like bullet points or emphasis, and the brevity may omit necessary details. It earns points for no wasted words but loses for potential under-specification.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of an output schema, the description should explain what the tool returns (e.g., the final URL string, a status code, or an error message). It does not, nor does it clarify the role of the optional api_key parameter. For a simple tool with two parameters, this is insufficient for complete understanding.

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?

Parameter descriptions in the schema are clear ('URL to get after redirects', 'Your ReviewWebsite API key'), achieving 100% schema coverage. However, the tool description adds no additional meaning beyond what the schema already provides, so it meets the baseline without exceeding it.

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 verb 'Get' and the resource 'URL after redirects', making the tool's purpose unambiguous. It distinguishes itself from sibling tools like scrape_url and url_is_alive by its specific focus on resolving redirects, though it does not explicitly name them.

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?

No guidance is provided on when to use this tool instead of alternatives such as 'url_is_alive' or 'scrape_url'. There is no mention of prerequisites, preferred scenarios, or exclusions, leaving the agent to guess based on the name alone.

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

url_is_aliveC

Check if a URL is alive using ReviewWeb.site API.

ParametersJSON Schema

Name	Required	Description
`url`	Yes	URL to check if it's alive
`timeout`	No	Request timeout in milliseconds (default: 10000)
`proxyUrl`	No	Proxy URL to use for the request
`api_key`	No	Your ReviewWebsite API key

TDQS

C2.9/5.0

Behavior2/5

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

The description lacks disclosure of behavioral traits like handling of unreachable URLs, timeout implications, or error responses. Since no annotations are provided, the description fails to convey essential operational behavior beyond the basic function.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at one sentence, which is efficient. However, it may be too brief to fully inform an AI agent, but it is not verbose or redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema and annotations, the description should provide more context about what 'alive' means (e.g., HTTP status, response time). It is too minimal to fully prepare an agent for appropriate use, especially with multiple parameters.

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 input schema already provides 100% coverage with descriptions for all parameters, so the tool description adds no new semantic value. It does not clarify usage nuances or relationships between parameters beyond what is in the schema.

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 checks if a URL is alive, specifying the verb and resource. However, it does not explicitly differentiate itself from sibling tools like 'url_get_after_redirects' or 'scrape_url', leaving some ambiguity about when this tool is preferred.

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?

No guidance is provided on when to use this tool versus alternatives, such as other URL-checking tools. There is no mention of prerequisites, limitations, or context for effective use.

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. Dates show when Glama detected each change.

3 tool updatesv1.3.1May 3, 2026
- Changedconvert_multiple_to_markdown1 field changed
  - addedInput schema / properties / instructions
```
Added value: +{
+  "description": "Optional custom conversion guidance for the AI",
+  "type": "string"
+}
```
- Changedconvert_to_markdown1 field changed
  - addedInput schema / properties / instructions
```
Added value: +{
+  "description": "Optional custom conversion guidance for the AI",
+  "type": "string"
+}
```
- Addedhtml_to_screenshot
15 tool updatesv1.0.0Aug 18, 2025
- First observedconvert_multiple_to_markdown
- First observedconvert_to_markdown
- First observedextract_data
- First observedextract_data_multiple
- First observedextract_links
- First observedscrape_url
- First observedseo_backlinks
- First observedseo_keyword_difficulty
- First observedseo_keyword_ideas
- First observedseo_traffic
- First observedsummarize_multiple_urls
- First observedsummarize_url
- First observedsummarize_website
- First observedurl_get_after_redirects
- First observedurl_is_alive

Install Server

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

TDQS

B3.2/5.0

Disambiguation4/5

Tools are mostly distinct in purpose, but some overlap exists (e.g., convert_to_markdown and extract_data both take URLs and produce AI-generated content). However, descriptions clarify the output format (markdown vs JSON), so ambiguity is low.

Naming Consistency3/5

Naming conventions vary: some tools use 'convert_', 'extract_', 'summarize_', while SEO tools prefix with 'seo_' and URL tools with 'url_'. This grouping is helpful but not fully uniform across the set.

Tool Count4/5

With 16 tools, the server covers a broad range of web page analysis features (scraping, AI conversion, SEO, URL utilities). The number is slightly above the typical 3-15 range but justified by the breadth of functionality.

Completeness4/5

The tool surface covers major web page operations: scraping, AI summarization, data extraction, SEO metrics, and URL checks. Minor gaps include no tool for batch extraction of links or more granular customization, but core workflows are supported.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

OneSchema MCP Server
co.oneschema
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Data Platforms App Automation
1
Orivox AI Website Builder AOAuth
org.orivox
Build, edit, host, and publish websites from AI assistants. Setup: https://mcp.orivox.org/
Content Management Systems Browser Automation App Automation
381
UnifAPIOAuth
com.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Open Data Search AI & Machine Learning
2
ZapierOAuth
com.zapier
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
App Automation Workplace & Productivity
2297

Related MCP Servers

Tripadvisor MCP
Search Travel & Transportation
pab1it0
A
license
B
quality
B
maintenance
MCP server that enables LLMs to interact with Tripadvisor API, supporting location data, reviews, and photos through standardized MCP interfaces
Updated a year ago (2025-04-13 20:47 UTC)
5
63
MIT
WebforAI Text Extractor
Web Scraping Browser Automation RAG Systems
MCP-Mirror
A
license
Not graded
quality
Not graded
maintenance
An MCP server that extracts clean, structured Markdown content from web page URLs using the WebforAI library. It simplifies feeding web content into AI models by removing HTML noise and intelligently processing tables and links.
Updated a year ago (2025-06-25 18:57 UTC)
-
Crawl4AI MCP Server
Web Scraping Browser Automation Search
stevenzxs
F
license
Not graded
quality
D
maintenance
A locally-hosted MCP server that provides AI assistants with advanced web crawling capabilities, including structured data extraction, deep site crawling, and page screenshots. It enables users to convert single or multiple URLs into clean Markdown content for processing by LLMs without requiring external API keys for basic features.
Updated 6 months ago (2026-02-26 04:36 UTC)
-
mult-fetch-mcp-server
Browser Automation Web Scraping
lmcc-dev
A
license
A
quality
C
maintenance
An MCP server that enables AI assistants to fetch web content in multiple formats (HTML, JSON, text, Markdown) with intelligent content extraction, chunk management, and browser automation support.
Updated a year ago (2025-08-28 02:39 UTC)
5
52
15
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mrgoonie/reviewwebsite-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

ReviewWebsite.com - MCP Server

Available Features

ReviewWeb.site

Supported Transports

How to use

CLI

MCP Setup

Source Code Overview

What is MCP?

Why Use This Boilerplate?

Getting Started

Prerequisites

Step 1: Clone and Install

Step 2: Run Development Server

Step 3: Test the ReviewWebsite API Tools

Architecture

Project Structure

Layers and Responsibilities

CLI Layer (src/cli/*.cli.ts)

Tools Layer (src/tools/*.tool.ts)

Controllers Layer (src/controllers/*.controller.ts)

Services Layer (src/services/*.service.ts)

Utils Layer (src/utils/*.util.ts)

Development Guide

Development Scripts

Testing

Code Quality

Building Custom Tools

1. Define Service Layer

2. Create Controller

3. Implement MCP Tool

4. Add CLI Support

5. Register Components

Debugging Tools

MCP Inspector

Server Logs

Publishing Your MCP Server

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

CLI Layer (`src/cli/*.cli.ts`)

Tools Layer (`src/tools/*.tool.ts`)

Controllers Layer (`src/controllers/*.controller.ts`)

Services Layer (`src/services/*.service.ts`)

Utils Layer (`src/utils/*.util.ts`)