Docker Hub Версия npm Лицензия: ISC
Реализация сервера Model Context Protocol (MCP), которая интегрируется с Olostep для веб-скрейпинга, извлечения контента и возможностей поиска. Для настройки MCP-сервера Olostep вам понадобится API-ключ. Вы можете получить его, зарегистрировавшись на сайте Olostep.
Скрейпинг контента веб-сайтов в форматах HTML, Markdown, JSON или обычного текста (с дополнительными парсерами)
Веб-поиск на основе парсеров со структурированными результатами
AI-ответы с цитатами и опциональным выводом в формате JSON
Пакетный скрейпинг до 10 тыс. URL-адресов
Автономный обход сайтов, начиная с заданного URL
Обнаружение и отображение URL-адресов веб-сайтов (с фильтрами включения/исключения)
Маршрутизация запросов по странам для получения геотаргетированного контента
Настраиваемое время ожидания для сайтов с активным использованием JavaScript
Комплексная обработка ошибок и отчетность
Простая настройка API-ключа
Related MCP server: Parallel Task MCP
Существует несколько способов подключения к MCP-серверу Olostep. Выберите тот, который лучше всего подходит для вашего рабочего процесса.
Самый простой способ — локальная установка не требуется. Подключайтесь напрямую к нашему размещенному MCP-серверу:
https://mcp.olostep.com/mcpАутентификация выполняется через токен Bearer в заголовке Authorization с использованием вашего API-ключа Olostep. Примеры конфигурации см. в разделе Настройка клиента ниже.
Скачайте и запустите официальный образ Docker:
docker pull olostep/mcp-server
docker run -i --rm \
-e OLOSTEP_API_KEY="your-api-key" \
olostep/mcp-serverЕсли вы предпочитаете собирать образ самостоятельно из исходного кода:
git clone https://github.com/olostep/olostep-mcp-server.git
cd olostep-mcp-server
npm install
npm run build
docker build -t olostep/mcp-server:local .
docker run -i --rm -e OLOSTEP_API_KEY="your-api-key" olostep/mcp-server:localЗапуск без установки с помощью npx:
env OLOSTEP_API_KEY=your-api-key npx -y olostep-mcpВ Windows (PowerShell):
$env:OLOSTEP_API_KEY = "your-api-key"; npx -y olostep-mcpВ Windows (CMD):
set OLOSTEP_API_KEY=your-api-key && npx -y olostep-mcpИли установите глобально:
npm install -g olostep-mcpСамый простой способ — использовать удаленную конечную точку. Создайте или отредактируйте файл .cursor/mcp.json в корне вашего проекта:
{
"mcpServers": {
"olostep": {
"url": "https://mcp.olostep.com/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_KEY_HERE"
}
}
}
}Альтернатива (локально): Перейдите в Cursor Settings > Features > MCP Servers, нажмите «+ Add New MCP Server»:
Name: olostep
Type: command
Command: env OLOSTEP_API_KEY=your-api-key npx -y olostep-mcp
Добавьте это в ваш claude_desktop_config.json:
{
"mcpServers": {
"mcp-server-olostep": {
"command": "npx",
"args": ["-y", "olostep-mcp"],
"env": {
"OLOSTEP_API_KEY": "YOUR_API_KEY_HERE"
}
}
}
}Альтернатива (Docker):
{
"mcpServers": {
"olostep": {
"command": "docker",
"args": [
"run", "-i", "--rm",
"-e", "OLOSTEP_API_KEY=YOUR_API_KEY_HERE",
"olostep/mcp-server"
]
}
}
}Или установите через Smithery CLI в терминале вашего устройства:
npx -y @smithery/cli install @olostep/olostep-mcp-server --client claudeДобавьте удаленную конечную точку в конфигурацию MCP Claude Code:
{
"mcpServers": {
"olostep": {
"url": "https://mcp.olostep.com/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_KEY_HERE"
}
}
}
}Альтернатива (локально):
{
"mcpServers": {
"olostep": {
"command": "npx",
"args": ["-y", "olostep-mcp"],
"env": {
"OLOSTEP_API_KEY": "YOUR_API_KEY_HERE"
}
}
}
}Добавьте это в ваш ./codeium/windsurf/model_config.json:
{
"mcpServers": {
"olostep": {
"serverUrl": "https://mcp.olostep.com/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_KEY_HERE"
}
}
}
}Альтернатива (локально):
{
"mcpServers": {
"mcp-server-olostep": {
"command": "npx",
"args": ["-y", "olostep-mcp"],
"env": {
"OLOSTEP_API_KEY": "YOUR_API_KEY_HERE"
}
}
}
}Добавьте это в ваш .vscode/mcp.json:
{
"servers": {
"olostep": {
"type": "http",
"url": "https://mcp.olostep.com/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_KEY_HERE"
}
}
}
}Альтернатива (локально):
{
"servers": {
"olostep": {
"type": "stdio",
"command": "npx",
"args": ["-y", "olostep-mcp"],
"env": {
"OLOSTEP_API_KEY": "YOUR_API_KEY_HERE"
}
}
}
}Вариант 1: Установка в один клик (рекомендуется)
Откройте панель управления Metorial
Перейдите в каталог MCP Servers
Найдите "Olostep"
Нажмите "Install" и введите свой API-ключ
Вариант 2: Ручная настройка
Добавьте это в конфигурацию MCP-сервера Metorial:
{
"olostep": {
"command": "npx",
"args": ["-y", "olostep-mcp"],
"env": {
"OLOSTEP_API_KEY": "YOUR_API_KEY_HERE"
}
}
}Инструменты Olostep станут доступны в ваших чатах с ИИ в Metorial.
OLOSTEP_API_KEY: Ваш API-ключ Olostep (обязательно)
ORBIT_KEY: Дополнительный ключ для использования Orbit при маршрутизации запросов.
scrape_website)Извлечение контента с одного URL. Поддерживает несколько форматов и рендеринг JavaScript.
{
"name": "scrape_website",
"arguments": {
"url_to_scrape": "https://example.com",
"output_format": "markdown",
"country": "US",
"wait_before_scraping": 1000,
"parser": "@olostep/amazon-product"
}
}url_to_scrape: URL веб-сайта, который вы хотите проскрейпить (обязательно)
output_format: Выберите формат (html, markdown, json или text) — по умолчанию: markdown
country: Дополнительный код страны (например, US, GB, CA) для скрейпинга с учетом местоположения
wait_before_scraping: Время ожидания в миллисекундах перед скрейпингом (0-10000)
parser: Дополнительный ID парсера для специализированного извлечения
{
"content": [
{
"type": "text",
"text": "{\n \"id\": \"scrp_...\",\n \"url\": \"https://example.com\",\n \"markdown_content\": \"# ...\",\n \"html_content\": null,\n \"json_content\": null,\n \"text_content\": null,\n \"status\": \"succeeded\",\n \"timestamp\": \"2025-11-14T12:34:56Z\",\n \"screenshot_hosted_url\": null,\n \"page_metadata\": { }\n}"
}
]
}search_web)Поиск в Интернете по заданному запросу и получение структурированных результатов (не ИИ, на основе парсера).
{
"name": "search_web",
"arguments": {
"query": "your search query",
"country": "US"
}
}query: Поисковый запрос (обязательно)
country: Дополнительный код страны для локализованных результатов (по умолчанию: US)
Структурированный JSON (в виде текста), представляющий результаты на основе парсера
answers)Поиск в Интернете и получение ответов от ИИ в нужной вам структуре JSON, с источниками и цитатами.
{
"name": "answers",
"arguments": {
"task": "Who are the top 5 competitors to Acme Inc. in the EU?",
"json": "Return a list of the top 5 competitors with name and homepage URL"
}
}task: Вопрос или задача для ответа с использованием веб-данных (обязательно)
json: Дополнительная схема/объект JSON или краткое описание желаемой структуры вывода
answer_id, object, task, result (JSON, если предоставлен), sources, created
batch_scrape_urls)Скрейпинг до 10 тыс. URL-адресов одновременно. Идеально подходит для крупномасштабного извлечения данных.
{
"name": "batch_scrape_urls",
"arguments": {
"urls_to_scrape": [
{"url": "https://example.com/a", "custom_id": "a"},
{"url": "https://example.com/b", "custom_id": "b"}
],
"output_format": "markdown",
"country": "US",
"wait_before_scraping": 500,
"parser": "@olostep/amazon-product"
}
}batch_id, status, total_urls, created_at, formats, country, parser, urls
create_crawl)Запуск асинхронного обхода, который автономно обнаруживает и скрейпит целые веб-сайты, переходя по ссылкам. Возвращает crawl_id — обход выполняется в фоновом режиме и не возвращает контент в этом ответе. Затем вы должны вызвать get_crawl_results с crawl_id, чтобы опросить статус и получить проскрейпленные страницы (та же схема из двух шагов, что и batch_scrape_urls + get_batch_results).
{
"name": "create_crawl",
"arguments": {
"start_url": "https://example.com/docs",
"max_pages": 25,
"follow_links": true,
"output_format": "markdown",
"country": "US",
"parser": "@olostep/doc-parser"
}
}crawl_id, object, status, start_url, max_pages, follow_links, created, formats, country, parser
Сочетайте этот вызов с
get_crawl_results— не передавайтеcrawl_idвget_batch_results(обходы и пакеты — это разные ресурсы).
create_map)Получение всех URL-адресов на веб-сайте. Извлечение всех URL для обнаружения и анализа.
{
"name": "create_map",
"arguments": {
"website_url": "https://example.com",
"search_query": "blog",
"top_n": 200,
"include_url_patterns": ["/blog/**"],
"exclude_url_patterns": ["/admin/**"]
}
}map_id, object, url, total_urls, urls, search_query, top_n
get_webpage_content)Извлекает контент веб-страницы в чистом формате markdown с поддержкой рендеринга JavaScript.
{
"name": "get_webpage_content",
"arguments": {
"url_to_scrape": "https://example.com",
"wait_before_scraping": 1000,
"country": "US"
}
}url_to_scrape: URL веб-страницы для скрейпинга (обязательно)
wait_before_scraping: Время ожидания в миллисекундах перед началом скрейпинга (по умолчанию: 0)
country: Страна проживания, из которой выполняется запрос (например, US, CA, GB) (опционально)
{
"content": [
{
"type": "text",
"text": "# Example Website\n\nThis is the markdown content of the webpage..."
}
]
}get_website_urls)Поиск и получение релевантных URL-адресов с веб-сайта, отсортированных по релевантности вашему запросу.
{
"name": "get_website_urls",
"arguments": {
"url": "https://example.com",
"search_query": "your search term"
}
}url: URL веб-сайта для отображения (обязательно)
search_query: Поисковый запрос для сортировки URL-адресов (обязательно)
{
"content": [
{
"type": "text",
"text": "Found 42 URLs matching your query:\n\nhttps://example.com/page1\nhttps://example.com/page2\n..."
}
]
}get_batch_results)Получение результатов ранее отправленного задания пакетного скрейпинга с использованием его batch_id.
{
"name": "get_batch_results",
"arguments": {
"batch_id": "batch_abc123"
}
}batch_id: ID пакета, возвращенный из batch_scrape_urls (обязательно)
batch_id, status (processing или completed), total_urls, completed_urls, items (массив проскрейпленных результатов для каждого URL с url, custom_id, markdown_content, html_content, json_content, text_content, status, page_metadata)
get_crawl_results)Получение статуса и проскрейпленных страниц для асинхронного обхода, запущенного с помощью create_crawl. Это обязательный компаньон для create_crawl — create_crawl только запускает задание и возвращает crawl_id; этот инструмент — способ, которым вы фактически получаете обнаруженные страницы и их контент.
{
"name": "get_crawl_results",
"arguments": {
"crawl_id": "crawl_abc123",
"formats": ["markdown"],
"items_limit": 20,
"cursor": 0
}
}crawl_id: ID обхода, возвращенный из create_crawl (обязательно)
formats: Массив форматов для получения каждой страницы — markdown, html, json, text (по умолчанию: ["markdown"])
items_limit: Максимальное количество страниц для получения контента, 1–100 (по умолчанию: 20)
cursor: Курсор пагинации для списка обнаруженных страниц (по умолчанию: 0)
search_query: Дополнительный фильтр для ранжирования/выбора страниц по релевантности запросу
В процессе: crawl_id, status (in_progress), pages_completed, pages_total и message с предложением повторить вызов примерно через 10 секунд.
После завершения: crawl_id, status (completed), pages_returned, next_cursor, has_more и массив pages, где каждая запись содержит url, custom_id и запрошенные поля контента (markdown_content, html_content, json_content, text_content).
Сервер обеспечивает надежную обработку ошибок:
Подробные сообщения об ошибках для проблем с API
Отчеты о сетевых ошибках
Обработка сбоев аутентификации
Информация об ограничении скорости (rate limit)
Пример ответа с ошибкой:
{
"isError": true,
"content": [
{
"type": "text",
"text": "Olostep API Error: 401 Unauthorized. Details: {\"error\":\"Invalid API key\"}"
}
]
}MCP-сервер доступен в виде образа Docker:
Docker Hub: [olostep/mcp-server](https://hub.docker.com/r/olostep/mcp-server)
Официальный реестр Docker MCP: mcp/olostep (скоро — повышенная безопасность с подписями и SBOM)
Реестр контейнеров GitHub: ghcr.io/olostep/olostep-mcp-server
MCP-сервер Olostep добавляется в официальный набор инструментов MCP Toolkit для Docker Desktop, что означает, что пользователи смогут:
Обнаруживать его в пользовательском интерфейсе MCP Toolkit в Docker Desktop
Устанавливать его в один клик
Настраивать его визуально
Использовать его с любым MCP-совместимым клиентом (Claude Desktop, Cursor и т. д.)
Статус: Отправка на рассмотрение в Docker MCP Registry
linux/amd64
linux/arm64
# Clone the repository
git clone https://github.com/olostep/olostep-mcp-server.git
cd olostep-mcp-server
# Build the image
npm install
npm run build
docker build -t olostep/mcp-server .
# Run locally
docker run -i --rm -e OLOSTEP_API_KEY="your-key" olostep/mcp-serverЛицензия ISC
Search the web and return AI-powered answers in the JSON structure you want, with sources and citations.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Question or task to answer using web data. | |
| json | No | Optional JSON schema/object or a short description of the desired output shape. Example object: { "book_title": "", "author": "", "release_date": "" } |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'AI-powered answers' and 'sources and citations', which hints at synthesis and attribution, but lacks details on behavioral traits like rate limits, authentication needs, response format beyond JSON, or whether it performs web searches in real-time. For a tool with no annotations, this leaves significant gaps in understanding its operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the core functionality in one sentence. Every phrase ('Search the web', 'return AI-powered answers', 'JSON structure you want, with sources and citations') contributes meaning without redundancy. It could be slightly more structured by separating usage hints, but it's efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a tool that performs web searches and AI synthesis, the description is incomplete. It doesn't cover critical aspects like response format details, error handling, limitations (e.g., search depth), or how 'sources and citations' are structured in the output. For a complex tool with 2 parameters, this leaves too much undefined for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('task' and 'json') well. The description adds minimal value beyond the schema, mentioning 'JSON structure you want' which aligns with the 'json' parameter but doesn't provide additional semantics like examples or constraints. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search the web and return AI-powered answers' with specific outputs ('JSON structure you want, with sources and citations'). It distinguishes from siblings like 'google_search' or 'scrape_website' by emphasizing AI-powered answer generation rather than raw search results or content extraction. However, it doesn't explicitly contrast with 'search_web' which might be similar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'google_search', 'search_web', or 'get_webpage_content'. The description implies usage for AI-powered answers with structured JSON output, but doesn't specify scenarios where this is preferred over simpler search tools or when not to use it (e.g., for raw data vs. synthesized answers).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scrape up to 10k URLs at the same time. Perfect for large-scale data extraction.
| Name | Required | Description | Default |
|---|---|---|---|
| urls_to_scrape | Yes | JSON array of objects with "url" and optional "custom_id". | |
| output_format | No | Choose format for all URLs. Default: "markdown". | markdown |
| country | No | Optional country code for location-specific scraping. | |
| wait_before_scraping | No | Wait time in milliseconds before scraping each URL. | |
| parser | No | Optional parser ID for specialized extraction. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral disclosure. It mentions scale ('up to 10k URLs') but doesn't cover critical aspects like rate limits, authentication needs, error handling, or what 'scrape' entails (e.g., does it extract text, metadata, full HTML?). The phrase 'at the same time' hints at concurrency but lacks specifics. For a batch operation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) and front-loaded with the core functionality. Every word earns its place: first sentence defines the tool, second provides usage context. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (batch scraping with 5 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what 'scrape' returns (e.g., content, status codes), how errors are handled for partial failures, or performance considerations. For a tool that could involve significant processing and network usage, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no parameter-specific information beyond implying the 'urls_to_scrape' parameter supports batch operations. No additional semantics, constraints, or usage examples are provided. Baseline 3 is appropriate when schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Scrape up to 10k URLs at the same time' specifies the verb (scrape) and resource (URLs) with a quantitative limit. It distinguishes from siblings like 'scrape_website' (singular) and 'get_webpage_content' (single page) by emphasizing batch capability. However, it doesn't explicitly differentiate from 'create_crawl' which might also handle multiple URLs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context: 'Perfect for large-scale data extraction' suggests when to use this tool (for bulk operations). However, it lacks explicit guidance on when NOT to use it or alternatives (e.g., use 'scrape_website' for single URLs, 'get_webpage_content' for simpler extraction). No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Autonomously discover and scrape entire websites by following links from a start URL.
| Name | Required | Description | Default |
|---|---|---|---|
| start_url | Yes | Starting URL for the crawl. | |
| max_pages | No | Maximum number of pages to crawl. | |
| follow_links | No | Whether to follow links found on pages. | |
| output_format | No | Format for scraped content. Default: "markdown". | markdown |
| country | No | Optional country code for location-specific crawling. | |
| parser | No | Optional parser ID for specialized content extraction. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions autonomous discovery and link-following, it lacks critical behavioral details like rate limits, authentication requirements, potential for being blocked by websites, or what happens when max_pages is reached. The description doesn't explain what 'scrape' entails beyond content extraction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core functionality without unnecessary words. It's front-loaded with the main action and resource, making it immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex crawling tool with 6 parameters and no annotations or output schema, the description is insufficient. It doesn't address important contextual aspects like what the tool returns (scraped content format, error handling), performance characteristics, or limitations of autonomous website discovery.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema. The baseline score of 3 reflects adequate parameter documentation through the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('discover and scrape entire websites') and resource ('websites'), distinguishing it from siblings like 'scrape_website' or 'get_webpage_content' by emphasizing autonomous link-following behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'scrape_website' or 'batch_scrape_urls'. It mentions following links but doesn't specify scenarios where this comprehensive crawling approach is preferred over targeted scraping.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all URLs on a website. Extract URLs for discovery and site analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| website_url | Yes | Website URL to extract links from. | |
| search_query | No | Optional search query to filter URLs (e.g., "blog"). | |
| top_n | No | Optional limit for number of URLs returned. | |
| include_url_patterns | No | Optional glob patterns to include (e.g., "/blog/**"). | |
| exclude_url_patterns | No | Optional glob patterns to exclude (e.g., "/admin/**"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool extracts URLs but doesn't describe how it works (e.g., crawling depth, handling of dynamic content, rate limits, authentication needs, or error conditions). The phrase 'Get all URLs' might imply comprehensive extraction, but without behavioral details, the agent lacks transparency about what to expect from the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: the first sentence 'Get all URLs on a website' directly states the core purpose. The second sentence adds context about use cases without redundancy. Every word earns its place, making it efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no annotations, no output schema), the description is insufficient. It doesn't explain what the tool returns (e.g., list structure, error formats), behavioral constraints, or how it differs from similar siblings. For a URL extraction tool with multiple filtering options, more context is needed to guide effective use, especially without annotations or output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, providing clear documentation for all 5 parameters. The description adds minimal value beyond this, only implying URL extraction without detailing parameter interactions or usage examples. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, though the description could have enhanced understanding with practical context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get all URLs on a website' specifies the verb (get/extract) and resource (URLs from a website). It distinguishes from some siblings like 'get_webpage_content' (which gets content rather than URLs) and 'google_search' (which searches the web rather than extracting from a specific site). However, it doesn't explicitly differentiate from 'get_website_urls' (which might have similar functionality), keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 mentions 'discovery and site analysis' as general use cases, but doesn't specify when to choose this over siblings like 'get_website_urls', 'scrape_website', or 'create_crawl'. There's no mention of prerequisites, limitations, or comparative advantages, leaving the agent with minimal usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve content of a webpage in markdown
| Name | Required | Description | Default |
|---|---|---|---|
| url_to_scrape | Yes | The URL of the webpage to scrape. | |
| wait_before_scraping | No | Time to wait in milliseconds before starting the scrape. | |
| country | No | Residential country to load the request from (e.g., US, CA, GB). Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'retrieve' and 'scrape', implying a read-only operation, but doesn't address potential issues like rate limits, authentication needs, error handling, or what happens with dynamic content. This is inadequate for a scraping tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and includes the output format, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a scraping tool with no annotations and no output schema, the description is incomplete. It doesn't explain return values (e.g., structure of markdown content), error conditions, or behavioral traits like handling of JavaScript-rendered pages. This leaves significant gaps for an AI agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema fully documents all three parameters. The description adds no additional meaning beyond what's in the schema, such as explaining why 'wait_before_scraping' might be needed or how 'country' affects the scrape. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve' and resource 'content of a webpage', specifying the output format 'in markdown'. However, it doesn't differentiate from sibling tools like 'scrape_website' or 'batch_scrape_urls', which likely 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.
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 'scrape_website' or 'batch_scrape_urls'. The description lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and retrieve relevant URLs from a website
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the website to map. | |
| search_query | Yes | The search query to sort URLs by. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'search and retrieve' but doesn't explain how the search works (e.g., depth, scope, or limitations), what 'relevant' means, potential rate limits, or authentication needs. This leaves significant gaps for a tool that interacts with external websites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded and appropriately sized for its purpose, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of web interaction tools and the lack of annotations and output schema, the description is incomplete. It doesn't cover behavioral aspects like error handling, return format, or limitations, which are crucial for an agent to use this tool effectively in real-world scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('url' and 'search_query') adequately. The description implies these parameters are used for searching and retrieving, but doesn't add meaningful semantic context beyond what the schema provides, such as examples or constraints on the search query.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('search and retrieve') and resource ('relevant URLs from a website'). However, it doesn't explicitly distinguish this tool from sibling tools like 'scrape_website' or 'search_web', which might have overlapping functionality, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. With multiple sibling tools like 'scrape_website', 'google_search', and 'search_web', there's no indication of context, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve structured data from Google search results
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query to perform | |
| country | No | Country code for localized results (e.g., US, GB) | US |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves structured data, implying a read-only operation, but doesn't cover critical aspects like rate limits, authentication needs, error handling, or what 'structured data' entails (e.g., format, fields). This leaves significant gaps for a tool interacting with an external service.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part earns its place by specifying the action, data type, and source. No fluff or redundancy is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a search tool with no annotations and no output schema, the description is incomplete. It doesn't explain the return values (what 'structured data' includes), error conditions, or operational constraints like rate limits. For a tool that likely involves external API calls, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters ('query' and 'country'). The description adds no additional meaning beyond what's in the schema, such as query formatting examples or country code implications. Baseline 3 is appropriate when the schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieve') and resource ('structured data from Google search results'), making the purpose immediately understandable. It distinguishes this from siblings like 'search_web' by specifying Google as the source and structured data as the output. However, it doesn't explicitly contrast with all siblings (e.g., 'answers' might also retrieve information).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'search_web' or 'answers'. It doesn't mention prerequisites, constraints, or typical use cases. The agent must infer usage from the name and description alone without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract content from a single URL. Supports multiple formats and JavaScript rendering.
| Name | Required | Description | Default |
|---|---|---|---|
| url_to_scrape | Yes | The URL of the website you want to scrape. | |
| output_format | No | Choose format ("html", "markdown", "json", or "text"). Default: "markdown" | markdown |
| country | No | Optional country code (e.g., US, GB, CA) for location-specific scraping. | |
| wait_before_scraping | No | Wait time in milliseconds before scraping (0-10000). Useful for dynamic content. | |
| parser | No | Optional parser ID for specialized extraction (e.g., "@olostep/amazon-product"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'JavaScript rendering' (useful context) and 'Supports multiple formats' (output behavior), but lacks critical details: whether scraping respects robots.txt, rate limits, authentication needs, error handling, or what 'extract content' specifically means. For a scraping tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two short sentences) and front-loaded with the core purpose. Every sentence adds value: first states the main action, second adds key capabilities. No wasted words, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, and no output schema, the description is moderately complete. It covers the basic purpose and key features (formats, JavaScript), but lacks details on scraping behavior, error cases, or output structure. For a tool with this complexity and no structured safety/behavior annotations, it should provide more context about limitations or typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds minimal value beyond the schema: it implies format support ('Supports multiple formats') and JavaScript capability, but doesn't explain parameter interactions or provide additional semantic context. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Extract content from a single URL' specifies the verb and resource. It distinguishes from sibling 'batch_scrape_urls' by emphasizing 'single URL' and from 'get_webpage_content' by mentioning format support and JavaScript rendering. However, it doesn't explicitly contrast with all siblings like 'google_search' or 'search_web'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'single URL' (vs. batch) and 'JavaScript rendering' (for dynamic content), but doesn't provide explicit when-to-use guidance or alternatives. It mentions 'Supports multiple formats' which suggests format flexibility, but no clear exclusions or comparisons to siblings like 'get_webpage_content' are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the web for a given query and return structured results (non-AI, parser-based).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| country | No | Optional country code for localized results (e.g., US, GB). | US |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'parser-based' and 'non-AI' which adds some behavioral context, but fails to disclose critical traits like rate limits, authentication needs, result format, pagination, or error handling for a web search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words, clearly front-loading the core functionality. Every part earns its place by specifying the action, resource, and method.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of web search and lack of annotations or output schema, the description is incomplete. It omits details on result structure, limitations, error cases, and how it differs from siblings, leaving significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('query' and 'country'). The description adds no additional meaning beyond what the schema provides, such as query formatting tips or country code examples, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Search') and resource ('the web'), specifying it returns structured results via parser-based (non-AI) methods. It distinguishes from AI-based search tools but doesn't explicitly differentiate from sibling tools like 'google_search' or 'answers'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'google_search' or 'answers', nor does it mention prerequisites or exclusions. The description implies a general web search context but lacks explicit usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0answersbatch_scrape_urlscreate_crawlcreate_mapget_webpage_content2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseget_website_urls2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsegoogle_search2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsescrape_websitesearch_webget_webpage_contentget_website_urlsgoogle_searchScored across 9 tools
There is significant overlap between tools like 'answers', 'google_search', and 'search_web' for web search functionality, and between 'scrape_website', 'get_webpage_content', and 'batch_scrape_urls' for content extraction. However, the descriptions help clarify some distinctions, such as AI-powered vs. parser-based search or single vs. batch scraping.
Most tools follow a consistent verb_noun pattern (e.g., 'create_crawl', 'get_webpage_content', 'scrape_website'), with only minor deviations like 'answers' (a noun alone) and 'google_search' (noun_verb). The naming is generally readable and predictable across the set.
With 9 tools, the count is reasonable for a web data extraction and search server. It covers multiple aspects of the domain without being overwhelming, though some overlap suggests potential consolidation could refine the scope slightly.
The toolset provides comprehensive coverage for web search, content scraping, and URL discovery, including batch operations and autonomous crawling. Minor gaps might include more advanced filtering or data processing tools, but core workflows are well-supported without dead ends.
Stealth scraping & search. Bypasses Cloudflare, DataDome & LinkedIn via Cyborg HITL approach.
B2B and local lead gen: verified emails, site contacts, Maps and Yellow Pages leads.
Search the web and extract clean, readable text from webpages. Process multiple URLs at once to sp…
Local business leads from Google Maps, 7 directories, DuckDuckGo and OpenStreetMap, with contacts
