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 - MCP 서버

이 프로젝트는 AI 어시스턴트를 ReviewWebsite.com API에 연결하여 웹사이트 리뷰를 생성 및 관리하고, 데이터를 추출하고, URL을 마크다운으로 변환하는 등의 작업을 수행하는 MCP(Model Context Protocol) 서버를 제공합니다.

사용 가능한 기능

[x] 웹사이트 리뷰 생성, 읽기, 업데이트 및 삭제
[x] 사용 가능한 AI 모델 가져오기
[x] AI를 사용하여 URL을 마크다운으로 변환
[x] AI를 사용하여 URL에서 구조화된 데이터 추출
[x] URL 스크래핑 및 콘텐츠 추출
[x] 웹사이트에서 링크 추출
[x] AI를 활용한 URL 및 웹사이트 요약
[x] SEO 통찰력(키워드 아이디어, 키워드 난이도, 트래픽 분석, 백링크)
[x] AI 모델 및 매개변수 사용자 정의
[x] 대기 동작 및 타이밍 제어

리뷰웹사이트

Related MCP server: WebforAI Text Extractor

지원되는 전송

[x] "stdio" 전송 - CLI 사용을 위한 기본 전송
[x]"스트리밍 가능한 HTTP" 전송 - 웹 기반 클라이언트용
- [ ] Bearer <token> 포함한 auth("Authorization" 헤더) 구현
[ ] ~~"sse" 운송~~ (더 이상 사용되지 않음)
[ ] 테스트 작성

사용 방법

CLI

지엑스피1

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(Model Context Protocol)는 AI 시스템이 외부 도구 및 데이터 소스와 안전하고 상황에 맞게 연결할 수 있도록 하는 개방형 표준입니다.

이 보일러플레이트는 모든 API나 데이터 소스에 대한 사용자 정의 MCP 서버를 구축하기 위해 확장 가능한 깔끔하고 계층화된 아키텍처로 MCP 사양을 구현합니다.

왜 이 보일러플레이트를 사용해야 하나요?

프로덕션 준비 아키텍처 : CLI, 도구, 컨트롤러 및 서비스를 명확하게 구분하여 게시된 MCP 서버에서 사용되는 것과 동일한 패턴을 따릅니다.
유형 안전성 : 개발자 경험, 코드 품질, 유지 관리 용이성을 개선하기 위해 TypeScript로 구축되었습니다.
실제 예제 : CLI에서 API 통합까지의 전체 패턴을 보여주는 완전히 구현된 IP 조회 도구가 포함되어 있습니다.
테스트 프레임워크 : 커버리지 보고를 포함하여 단위 및 CLI 통합 테스트를 위한 테스트 인프라가 제공됩니다.
개발 도구 : MCP 서버 개발을 위해 사전 구성된 ESLint, Prettier, TypeScript 및 기타 고품질 도구가 포함되어 있습니다.

시작하기

필수 조건

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` )

목적 : AI 어시스턴트에 대한 스키마와 설명을 포함하는 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 : 마크다운 서식 도우미

개발 가이드

개발 스크립트

# 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. 서비스 계층 정의

외부 API와 상호 작용하려면 src/services/ 에 새 서비스를 만드세요.

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

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 - MCP 서버

사용 가능한 기능

리뷰웹사이트

지원되는 전송

사용 방법

CLI

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

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` )