# 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 设置

对于使用 stdio 传输的本地配置：

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

对于远程 HTTP 配置：

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

HTTP 传输的环境变量：

您可以使用以下环境变量配置 HTTP 服务器：

MCP_HTTP_HOST ：绑定到的主机（默认值： 127.0.0.1 ）
MCP_HTTP_PORT ：监听的端口（默认值： 8080 ）
MCP_HTTP_PATH ：端点路径（默认值： /mcp ）

源代码概述

什么是 MCP？

模型上下文协议 (MCP) 是一种开放标准，允许 AI 系统安全且上下文地与外部工具和数据源连接。

该样板通过清晰的分层架构实现了 MCP 规范，可以扩展以构建任何 API 或数据源的自定义 MCP 服务器。

为什么要使用这个样板？

生产就绪架构：遵循已发布的 MCP 服务器中使用的相同模式，CLI、工具、控制器和服务之间有明确的分离。
类型安全：使用 TypeScript 构建，以改善开发人员体验、代码质量和可维护性。
工作示例：包括一个完全实现的 IP 查找工具，演示从 CLI 到 API 集成的完整模式。
测试框架：配备单元和 CLI 集成测试的测试基础设施，包括覆盖率报告。
开发工具：包括 ESLint、Prettier、TypeScript 和其他为 MCP 服务器开发预先配置的质量工具。

入门

先决条件

Node.js （>=18.x）：下载
Git ：用于版本控制

步骤 1：克隆并安装

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

# Install dependencies
npm install

第 2 步：运行开发服务器

使用 stdio 传输（默认）以开发模式启动服务器：

npm run dev:server

或者使用 Streamable HTTP 传输：

npm run dev:server:http

这将以热重载方式启动 MCP 服务器，并在http://localhost:5173启用 MCP 检查器。

⚙️ 代理服务器正在监听 6277 端口 🔍 MCP Inspector 已启动并运行于http://127.0.0.1:6274

当使用 HTTP 传输时，服务器默认在http://127.0.0.1:8080/mcp上可用。

步骤 3：测试 ReviewWebsite API 工具

通过 CLI 使用 ReviewWebsite API 工具：

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

建筑学

该样板遵循清晰的分层架构模式，可分离关注点并提高可维护性。

项目结构

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

层次和职责

CLI 层（ `src/cli/*.cli.ts` ）

目的：定义解析参数和调用控制器的命令行接口
命名：文件应命名为<feature>.cli.ts
测试： <feature>.cli.test.ts中的 CLI 集成测试

工具层（ `src/tools/*.tool.ts` ）

目的：为人工智能助手定义带有模式和描述的 MCP 工具
命名：文件应命名为<feature>.tool.ts ，类型为<feature>.types.ts
模式：每个工具都应该使用 zod 进行参数验证

控制器层（ `src/controllers/*.controller.ts` ）

目的：实现业务逻辑、处理错误和格式化响应
命名：文件应命名为<feature>.controller.ts
模式：应返回标准化的ControllerResponse对象

服务层（ `src/services/*.service.ts` ）

目的：与外部 API 或数据源交互
命名：文件应命名为<feature>.service.ts
模式：纯 API 交互，逻辑最少

实用程序层 ( `src/utils/*.util.ts` )

目的：提供跨应用程序的共享功能
主要用途：
- logger.util.ts ：结构化日志记录
- error.util.ts ：错误处理和标准化
- formatter.util.ts ：Markdown 格式化助手

开发指南

开发脚本

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

测试

# Run all tests
npm test

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

# Generate test coverage report
npm run test:coverage

代码质量

# Lint code
npm run lint

# Format code with Prettier
npm run format

# Check types
npm run typecheck

构建自定义工具

按照以下步骤将您自己的工具添加到服务器：

1.定义服务层

在src/services/中创建一个新服务来与您的外部 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.创建控制器

在src/controllers/中添加一个控制器来处理业务逻辑：

// 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. 实现MCP工具

在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.添加CLI支持

在src/cli/中创建一个 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. 注册组件

更新入口点以注册新组件：

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

调试工具

MCP 检查器

访问可视化 MCP 检查器来测试您的工具并查看请求/响应详细信息：

运行npm run dev:server
在浏览器中打开http://localhost:5173
测试您的工具并直接在 UI 中查看日志

服务器日志

启用开发调试日志：

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

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

发布您的 MCP 服务器

准备发布您的自定义 MCP 服务器时：

使用您的详细信息更新 package.json
使用您的工具文档更新 README.md
构建项目： npm run build
测试生产版本： npm run start:server
发布到 npm： npm publish

执照

MIT 许可证

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

**注意：**为了向后兼容，如果未找到reviewwebsite键，服务器也会识别完整软件包名称 ( reviewwebsite-mcp-server ) 或未指定范围的软件包名称 ( reviewwebsite-mcp-server ) 下的配置。但是，建议对新配置使用短reviewwebsite键。

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.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

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
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
52
15
MIT

ReviewWebsite.com - MCP 服务器

可用功能

评论网站

支持的传输

如何使用

命令行界面

MCP 设置

源代码概述

什么是 MCP？

为什么要使用这个样板？

入门

先决条件

步骤 1：克隆并安装

第 2 步：运行开发服务器

步骤 3：测试 ReviewWebsite API 工具

建筑学

项目结构

层次和职责

CLI 层（ src/cli/*.cli.ts ）

工具层（ src/tools/*.tool.ts ）

控制器层（ src/controllers/*.controller.ts ）

服务层（ src/services/*.service.ts ）

实用程序层 ( src/utils/*.util.ts )

开发指南

开发脚本

测试

代码质量

构建自定义工具

1.定义服务层

2.创建控制器

3. 实现MCP工具

4.添加CLI支持

5. 注册组件

调试工具

MCP 检查器

服务器日志

发布您的 MCP 服务器

执照

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

CLI 层（ `src/cli/*.cli.ts` ）

工具层（ `src/tools/*.tool.ts` ）

控制器层（ `src/controllers/*.controller.ts` ）

服务层（ `src/services/*.service.ts` ）

实用程序层 ( `src/utils/*.util.ts` )