de en es ja ko ru zh

ReviewWebsite MCP Server

Name: ReviewWebsite MCP Server
Author: mrgoonie

by mrgoonie

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

ReviewWebsite.com - Servidor MCP

Este proyecto proporciona un servidor de Protocolo de Contexto de Modelo (MCP) que conecta a los asistentes de IA con la API de ReviewWebsite.com para crear y administrar reseñas de sitios web, extraer datos, convertir URL a Markdown y más.

Funciones disponibles

[x] Crear, leer, actualizar y eliminar reseñas de sitios web
[x] Obtenga modelos de IA disponibles
[x] Convertir URL a Markdown usando IA
[x] Extraer datos estructurados de URL mediante IA
[x] Extraer URL y contenido
[x] Extraer enlaces de sitios web
[x] Resumir URL y sitios web usando IA
[x] Información SEO (ideas de palabras clave, dificultad de palabras clave, análisis de tráfico, vínculos de retroceso)
[x] Personalizar modelos y parámetros de IA
[x] Controlar el comportamiento y el tiempo de espera

ReviewWeb.site

Related MCP server: WebforAI Text Extractor

Transportes soportados

[x] Transporte "stdio" : transporte predeterminado para el uso de CLI
[x] Transporte"HTTP transmitible" : para clientes web
- [ ] Implementar autenticación (encabezados "Autorización" con Bearer <token> )
[ ] ~~transporte "sse"~~ (Obsoleto)
[ ] Escribir pruebas

Cómo utilizar

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"

Configuración de MCP

Para la configuración local con transporte stdio:

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

Para la configuración HTTP remota:

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

Variables de entorno para el transporte HTTP:

Puede configurar el servidor HTTP utilizando estas variables de entorno:

MCP_HTTP_HOST : El host al que vincularse (predeterminado: 127.0.0.1 )
MCP_HTTP_PORT : El puerto para escuchar (predeterminado: 8080 )
MCP_HTTP_PATH : La ruta del punto final (predeterminado: /mcp )

Descripción general del código fuente

¿Qué es MCP?

El Protocolo de Contexto de Modelo (MCP) es un estándar abierto que permite a los sistemas de IA conectarse de forma segura y contextual con herramientas y fuentes de datos externas.

Esta plantilla implementa la especificación MCP con una arquitectura limpia y en capas que puede ampliarse para crear servidores MCP personalizados para cualquier API o fuente de datos.

¿Por qué utilizar este texto estándar?

Arquitectura lista para producción : sigue el mismo patrón utilizado en los servidores MCP publicados, con una clara separación entre CLI, herramientas, controladores y servicios.
Seguridad de tipos : creado con TypeScript para mejorar la experiencia del desarrollador, la calidad del código y la facilidad de mantenimiento.
Ejemplo de trabajo : incluye una herramienta de búsqueda de IP completamente implementada que demuestra el patrón completo desde la CLI hasta la integración de API.
Marco de pruebas : incluye infraestructura de pruebas para pruebas de integración unitarias y CLI, incluidos informes de cobertura.
Herramientas de desarrollo : incluye ESLint, Prettier, TypeScript y otras herramientas de calidad preconfiguradas para el desarrollo de servidores MCP.

Empezando

Prerrequisitos

Node.js (>=18.x): Descargar
Git : para el control de versiones

Paso 1: Clonar e instalar

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

# Install dependencies
npm install

Paso 2: Ejecutar el servidor de desarrollo

Inicie el servidor en modo de desarrollo con el transporte stdio (predeterminado):

npm run dev:server

O con el transporte HTTP Streamable:

npm run dev:server:http

Esto inicia el servidor MCP con recarga activa y habilita el Inspector MCP en http://localhost:5173 .

⚙️ El servidor proxy escucha en el puerto 6277 🔍 MCP Inspector está en funcionamiento en http://127.0.0.1:6274

Al utilizar el transporte HTTP, el servidor estará disponible en http://127.0.0.1:8080/mcp de forma predeterminada.

Paso 3: Pruebe las herramientas de la API de ReviewWebsite

Utilice las herramientas de la API de ReviewWebsite a través de 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"

Arquitectura

Este modelo sigue un patrón de arquitectura limpio y en capas que separa las preocupaciones y promueve la capacidad de mantenimiento.

Estructura del proyecto

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

Capas y responsabilidades

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

Propósito : Definir interfaces de línea de comandos que analizan argumentos y llaman a controladores.
Nombre : Los archivos deben llamarse <feature>.cli.ts
Pruebas : pruebas de integración de CLI en <feature>.cli.test.ts

Capa de herramientas ( `src/tools/*.tool.ts` )

Propósito : Definir herramientas MCP con esquemas y descripciones para asistentes de IA.
Nombre : Los archivos deben llamarse <feature>.tool.ts con tipos en <feature>.types.ts
Patrón : Cada herramienta debe usar zod para la validación de argumentos

Capa de controladores ( `src/controllers/*.controller.ts` )

Propósito : Implementar lógica empresarial, manejar errores y dar formato a respuestas.
Nombre : Los archivos deben llamarse <feature>.controller.ts
Patrón : Debe devolver objetos ControllerResponse estandarizados

Capa de servicios ( `src/services/*.service.ts` )

Propósito : Interactuar con API externas o fuentes de datos
Nombre : Los archivos deben llamarse <feature>.service.ts
Patrón : Interacciones de API puras con lógica mínima

Capa de utilidades ( `src/utils/*.util.ts` )

Propósito : Proporcionar funcionalidad compartida en toda la aplicación.
Utilidades clave :
- logger.util.ts : Registro estructurado
- error.util.ts : Manejo de errores y estandarización
- formatter.util.ts : ayudantes de formato Markdown

Guía de desarrollo

Scripts de desarrollo

# 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]

Pruebas

# Run all tests
npm test

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

# Generate test coverage report
npm run test:coverage

Calidad del código

# Lint code
npm run lint

# Format code with Prettier
npm run format

# Check types
npm run typecheck

Creación de herramientas personalizadas

Siga estos pasos para agregar sus propias herramientas al servidor:

1. Definir la capa de servicio

Cree un nuevo servicio en src/services/ para interactuar con su API externa:

// 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. Crear controlador

Agregue un controlador en src/controllers/ para manejar la lógica empresarial:

// 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. Implementar la herramienta MCP

Crea una definición de herramienta en 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. Agregar compatibilidad con CLI

Cree un comando CLI en 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. Registrar componentes

Actualice los puntos de entrada para registrar sus nuevos componentes:

// 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);

Herramientas de depuración

Inspector de MCP

Acceda al Inspector visual de MCP para probar sus herramientas y ver los detalles de la solicitud/respuesta:

Ejecutar npm run dev:server
Abra http://localhost:5173 en su navegador
Pruebe sus herramientas y vea los registros directamente en la interfaz de usuario

Registros del servidor

Habilitar registros de depuración para el desarrollo:

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

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

Publicación de su servidor MCP

Cuando esté listo para publicar su servidor MCP personalizado:

Actualice package.json con sus datos
Actualice README.md con la documentación de su herramienta
Construya el proyecto: npm run build
Pruebe la compilación de producción: npm run start:server
Publicar en npm: npm publish

Licencia

Licencia MIT

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

Nota: Para compatibilidad con versiones anteriores, el servidor también reconocerá las configuraciones con el nombre completo del paquete ( reviewwebsite-mcp-server ) o con el nombre sin ámbito ( reviewwebsite-mcp-server ) si no se encuentra la clave reviewwebsite . Sin embargo, se recomienda usar la clave reviewwebsite corta para las nuevas configuraciones.

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.

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

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.2/5.0

Scored 2026-05-03 01:10 across 16 tools

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

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
Site MCP A
dev.sitemcp
Turn any public website into an MCP server for agents to search, read and navigate.
Browser Automation Web Scraping Search
61
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

Related MCP Servers

Tripadvisor MCP
Search Travel & Transportation
pab1it0
A
license
B
quality
C
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
64
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 7 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
27 npm
15
MIT

ReviewWebsite.com - Servidor MCP

Funciones disponibles

ReviewWeb.site

Transportes soportados

Cómo utilizar

CLI

Configuración de MCP

Descripción general del código fuente

¿Qué es MCP?

¿Por qué utilizar este texto estándar?

Empezando

Prerrequisitos

Paso 1: Clonar e instalar

Paso 2: Ejecutar el servidor de desarrollo

Paso 3: Pruebe las herramientas de la API de ReviewWebsite

Arquitectura

Estructura del proyecto

Capas y responsabilidades

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

Capa de herramientas ( src/tools/*.tool.ts )

Capa de controladores ( src/controllers/*.controller.ts )

Capa de servicios ( src/services/*.service.ts )

Capa de utilidades ( src/utils/*.util.ts )

Guía de desarrollo

Scripts de desarrollo

Pruebas

Calidad del código

Creación de herramientas personalizadas

1. Definir la capa de servicio

2. Crear controlador

3. Implementar la herramienta MCP

4. Agregar compatibilidad con CLI

5. Registrar componentes

Herramientas de depuración

Inspector de MCP

Registros del servidor

Publicación de su servidor MCP

Licencia

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

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

Capa de herramientas ( `src/tools/*.tool.ts` )

Capa de controladores ( `src/controllers/*.controller.ts` )

Capa de servicios ( `src/services/*.service.ts` )

Capa de utilidades ( `src/utils/*.util.ts` )