Decodo MCP Server
Сервер Decodo MCP
Подключайте LLM и AI-агентов к живым веб-данным с помощью MCP (Model Context Protocol). Сервер Decodo MCP позволяет извлекать данные с веб-сайтов, поисковых систем, eCommerce-платформ и социальных сетей напрямую из AI-инструментов, таких как Claude, Cursor и Windsurf, без необходимости создавать инфраструктуру для скрапинга с нуля.
Структурированные выходные данные в форматах JSON, Markdown и скриншоты
Серверный рендеринг JavaScript и обработка анти-бот защиты
125M+ IP-адресов в 195+ локациях
Что такое сервер Decodo MCP?
Сервер Decodo MCP — это слой веб-скрапинга для AI-агентов. Он подключает MCP-совместимые клиенты к Web Scraping API Decodo, что позволяет:
Веб-скрапинг для LLM
Получение данных в реальном времени для RAG
Просмотр и исследование с помощью AI-агентов
Извлечение структурированных данных с динамических веб-сайтов
Вместо поддержки прокси, парсеров и логики повторов вы получаете единую точку интеграции для надежного доступа к веб-данным.
Related MCP server: FreeCrawl MCP Server
Зачем использовать MCP для веб-скрапинга?
Model Context Protocol (MCP) — это новый стандарт для подключения AI-агентов к внешним инструментам и источникам данных. С MCP:
Агенты могут динамически вызывать инструменты
Интеграции остаются стандартизированными
Рабочие процессы масштабируются в разных средах
Сервер Decodo MCP предоставляет вашим агентам надежный, готовый к продакшену веб-доступ через этот стандарт.
Ключевые возможности
Веб-скрапинг для AI-агентов без необходимости в инфраструктуре. Извлекайте данные с любого веб-сайта, включая страницы с большим количеством JavaScript, без управления ротацией прокси, решения CAPTCHA или обхода анти-бот систем.
Структурированные выходные данные для LLM-рабочих процессов. Markdown (готов к использованию LLM), JSON (для структурированных конвейеров) и скриншоты (для визуального контекста), созданные для RAG-конвейеров, AI-исследовательских агентов и автоматизированных процессов.
Встроенная поддержка популярных целей. Готовые инструменты для Google и Bing (SERP), Amazon, Walmart и Target (eCommerce), Reddit, TikTok и YouTube (социальные сети), а также ChatGPT и Perplexity (AI-поиск).
Глобальная прокси-инфраструктура. 125M+ резидентных IP-адресов, 195+ геолокаций и 99.99% успешных запросов даже на самых защищенных целях.
Модульные наборы инструментов MCP. Включайте только то, что нужно: web, search, ecommerce, social_media,
ai для более чистой выборки инструментов и лучшей производительности агентов.
Быстрый результат. От API-ключа до первого скрапинга за считанные минуты, без лишних настроек.
Варианты использования
Используйте сервер Decodo MCP, когда вам нужен веб-скрапинг для AI-агентов, извлечение структурированных данных в масштабе, надежный доступ к динамическим веб-сайтам, данные в реальном времени для RAG или альтернатива созданию инфраструктуры скрапинга с нуля. Типичные сценарии:
Веб-скрапинг на основе AI – дайте LLM возможность собирать свежие данные вместо использования статических обучающих данных.
RAG с живыми данными – получайте результаты поиска Google, Bing и AI в реальном времени в конвейеры поиска.
Аналитика eCommerce – отслеживайте цены на товары, списки и продавцов на маркетплейсах без блокировок.
Сбор данных из социальных сетей – собирайте посты, каналы и данные о вовлеченности из Reddit, TikTok и YouTube.
Агрегация путешествий и цен – создавайте инструменты для сбора актуальных цен и наличия на веб-сайтах.
Быстрый старт
Создайте бесплатный аккаунт на dashboard.decodo.com – до 2K бесплатных запросов, без кредитной карты.
Получите свой API-ключ. Получите токен базовой аутентификации Web Scraping API в панели управления.
Скачайте Node.js 18+ с https://nodejs.org.
Получите MCP-клиент, например Claude Desktop, Cursor, Windsurf или другие MCP-совместимые инструменты.
Настройте MCP-сервер в вашем AI-клиенте (см. примеры конфигурации ниже).
Подключение к MCP-серверу Decodo
Откройте предпочитаемый MCP-клиент и добавьте следующую конфигурацию (см. примеры для Claude Code, Cursor, Windsurf ниже):
{
"mcpServers": {
"Decodo": {
"url": "https://mcp.decodo.com/mcp",
"headers": {
"Authorization": "Basic <basic_auth_token>"
}
}
}
}Claude Desktop
Откройте Claude Desktop → Settings → Developer → Edit Config.
Добавьте в claude_desktop_config.json:
{
"mcpServers": {
"Decodo": {
"command": "npx",
"args": ["-y", "@decodo/mcp-server"],
"env": {
"SCRAPER_API_TOKEN": "<basic_auth_token>",
"TOOLSETS": "web,ai"
}
}
}
}Сохраните и перезапустите Claude Desktop.
Cursor
Откройте Settings → MCP.
Нажмите Add a new global MCP server (откроется mcp.json).
Добавьте ту же конфигурацию, что и выше.
Сохраните — обратите внимание на зеленый индикатор статуса рядом с Decodo.
Windsurf
Откройте Settings → Windsurf Settings.
Прокрутите до Cascade → Add custom server + (откроется mcp_config.json).
Добавьте ту же конфигурацию, что и выше.
Сохраните и перезапустите Windsurf.
Проверьте свою настройку
После подключения попробуйте этот промпт в вашем клиенте:
▎ "Извлеките заголовки 5 лучших статей с Hacker News"
Вы должны получить структурированный список в течение нескольких секунд. Если вы видите ошибку аутентификации, перепроверьте свой токен в панели управления.
Опционально: включите определенные наборы инструментов
Запуск MCP-сервера локально
Предварительные требования
Node.js 18+
MCP-клиент — популярные варианты: Claude Desktop и Cursor
Пошаговое руководство
Клонируйте этот репозиторий:
git clone https://github.com/Decodo/mcp-serverВыполните следующие команды в терминале:
cd decodo-mcp-server
npm install
npm run buildОбратите внимание на расположение сборки:
cd build/
pwdДобавив index.js в конец этого каталога, расположение вашего файла сборки должно выглядеть примерно
так:
/Users/your.user/projects/decodo-mcp/build/index.jsОбновите ваш MCP-клиент с информацией о сервере:
{
"mcpServers": {
"decodo-mcp": {
"command": "node",
"args": ["/Users/your.user/projects/decodo-mcp/build/index.js"],
"env": {
"SCRAPER_API_TOKEN": "<web_scraping_api_base64_token>"
}
}
}
}Наборы инструментов
Инструменты организованы в наборы. Вы можете выборочно включать определенные наборы, передавая
список через запятую в параметре запроса toolsets:
"Decodo MCP Server": {
"url": "https://mcp.decodo.com/mcp?toolsets=web,ai",
"headers": {
"Authorization": "Basic <your_auth_token>"
}
}Если наборы не указаны, регистрируются все инструменты.
Набор | Инструменты |
|
|
|
|
|
|
|
|
|
|
Инструменты
Сервер предоставляет следующие инструменты:
Инструмент | Описание | Пример запроса |
| Извлекает содержимое любого целевого URL, ожидает URL в запросе. Возвращает результаты в Markdown. | Извлеки peacock.com с IP-адреса в США и расскажи мне о ценах. |
| Делает снимок экрана любой веб-страницы и возвращает его в формате PNG. | Сделай снимок экрана github.com с IP-адреса в США. |
| Извлекает результаты Google Search по заданному запросу и возвращает разобранные результаты. | Извлеки Google Search по запросу «обувь» и скажи, какая позиция первая. |
| Извлекает результаты поиска Google Ads. | Извлеки Google Ads по запросу «ноутбук» и покажи лучшие объявления. |
| Извлекает результаты поиска по изображениям Google Lens. | Поищи в Google Lens это изображение: https://example.com/image.jpg |
| Извлекает результаты Google AI Mode (Поиск с ИИ). | Спроси Google AI Mode: Какие три лучшие породы собак? |
| Извлекает результаты поиска Google Travel Hotels. | Поищи в Google Travel Hotels отели в Париже. |
| Извлекает результаты Amazon Search по заданному запросу и возвращает разобранные результаты. | Извлеки Amazon Search по запросу «беспроводная клавиатура». |
| Извлекает страницу товара Amazon. | Извлеки товар Amazon B09H74FXNW и покажи подробности. |
| Извлекает информацию о ценах на товары Amazon. | Получи цены на товар Amazon B09H74FXNW. |
| Извлекает информацию о продавцах Amazon. | Получи информацию о продавце Amazon A1R0Z7FJGTKESH. |
| Извлекает список бестселлеров Amazon. | Покажи бестселлеры Amazon в категории электроники. |
| Извлекает результаты Walmart Search по заданному запросу и возвращает разобранные результаты. | Извлеки Walmart Search по запросу «палатка для кемпинга». |
| Извлекает страницу товара Walmart. | Извлеки товар Walmart 15296401808. |
| Извлекает результаты Target Search по заданному запросу и возвращает разобранные результаты. | Извлеки Target Search по запросу «кухонная техника». |
| Извлекает страницу товара Target. | Извлеки товар Target 92186007. |
| Извлекает данные из поста TikTok по URL (например, вовлечённость, подпись, хэштеги). | Извлеки этот пост TikTok: https://www.tiktok.com/@nba/video/7393013274725403950 |
| Извлекает результаты TikTok Shop Search по заданному запросу и возвращает разобранные результаты. | Извлеки TikTok Shop Search по запросу «чехлы для телефона». |
| Извлекает страницу товара TikTok Shop. | Извлеки товар TikTok Shop 1731541214379741272. |
| Извлекает страницу TikTok Shop по URL. | Извлеки этот URL TikTok Shop: https://www.tiktok.com/shop/s?q=HEADPHONES |
| Извлекает метаданные видео YouTube. | Получи метаданные для видео YouTube dFu9aKJoqGg. |
| Извлекает видео канала YouTube. | Извлеки канал YouTube @decodo_official. |
| Извлекает субтитры видео YouTube. | Получи субтитры для видео YouTube L8zSWbQN-v8. |
| Поиск видео на YouTube. | Поищи на YouTube «Как ухаживать за шиншиллами». |
| Извлекает конкретный пост Reddit. | Извлеки следующий пост Reddit: https://www.reddit.com/r/horseracing/comments/1nsrn3/ |
| Извлекает результаты по сабреддиту Reddit. | Извлеки 5 лучших постов в r/Python за эту неделю. |
| Извлекает профиль пользователя Reddit и его посты/комментарии. | Извлеки этого пользователя Reddit: https://www.reddit.com/user/IWasRightOnce/ |
| Извлекает результаты Bing Search. | Поищи в Bing обзоры ноутбуков. |
| Поиск и взаимодействие с ChatGPT для ответов и диалогов на основе ИИ. | Попроси ChatGPT объяснить квантовые вычисления простыми словами. |
| Поиск и взаимодействие с Perplexity для ответов и диалогов на основе ИИ. | Спроси Perplexity, каковы последние тренды в веб-разработке. |
Параметры
Следующие параметры выводятся из запросов пользователя:
Параметр | Описание |
| Отрисовывает целевой URL в headless-браузере. |
| Задаёт страну, из которой будет исходить запрос. |
| Задаёт локаль запроса. |
| Обрезает содержимое ответа до этого предела. Полезно, если контекстное окно небольшое. |
| Запрос для отправки в ИИ-инструменты ( |
| Активирует веб-поиск ChatGPT (только для |
| Если true, включает ответы XHR или fetch в результат извлечения там, где это поддерживается (например, |
| Тип устройства для эмуляции запроса ( |
| Домен для запроса (например, |
| Начальный номер страницы для пагинации. |
| Почтовый индекс для доставки (Target, Walmart). |
| Идентификатор магазина для локального наличия (Target, Walmart). |
| Страна для запросов TikTok Shop. |
| Максимальное количество возвращаемых результатов (например, видео канала YouTube). |
| Код языка для субтитров (например, |
Примеры
Извлечение гео-ограниченного контента
Задайте вашему ИИ-агенту следующий запрос:
Scrape peacock.com from a German IP address and tell me the pricing.Этот запрос сообщит, что peacock.com является гео-ограниченным. Чтобы обойти гео-ограничение:
Scrape peacock.com from a US IP address and tell me the pricing.Ограничение количества токенов в ответе
Если у вашего агента небольшое контекстное окно, содержимое, возвращаемое при извлечении, будет автоматически обрезано, чтобы избежать переполнения контекста. Вы можете увеличить количество возвращаемых токенов в своём запросе:
Scrape hacker news, return 50k tokens.Если у вашего агента большое контекстное окно, скажите ему вернуть полное содержимое:
Scrape hacker news, return full content.Использование с навыками агента Decodo
Этот сервер даёт вашему агенту инструменты для извлечения данных. Decodo/agent-skills
обучает его когда обращаться к ним, какую поверхность использовать и как вызывать её — так
агент сам выбирает правильный инструмент и параметры, а не угадывает.
Навыки работают через CLI decodo, этот размещённый MCP-сервер и сырой HTTP API, и автоматически
переключаются на MCP-сервер, когда оболочка недоступна. Объединение этих двух компонентов даёт вашему
агенту и уровень выполнения (этот сервер), и уровень принятия решений (навыки) в одной настройке.
Быстрый старт (Claude Code):
/plugin marketplace add Decodo/agent-skills
/plugin install decodo@decodo-skillsСм. README agent-skills для ручной установки и других агентов (Cursor, Codex, Gemini CLI, Windsurf).
Связанные репозитории
Web Scraping API, Decodo agent skills, Decodo OpenClaw skill
Попробуйте
Подключите Decodo MCP Server к вашему ИИ-рабочему процессу всего за несколько кликов и оснастите своих ИИ-агентов данными в реальном времени с любого сайта.
Начать бесплатно | Документация | Discord
Лицензия
Весь код выпущен под лицензией MIT.
Available Tools
30 toolsamazon_bestsellersBRead-only
Scrape Amazon Bestsellers list with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Amazon category (e.g., "mobile-apps", "electronics") | |
| domain | No | Amazon domain (e.g., amazon.com, amazon.co.uk) | |
| deviceType | No | Device type to emulate for the request | |
| pageFrom | No | Starting page number for pagination |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and openWorldHint=true, but the description adds minimal behavioral details beyond 'automatic parsing.' It does not explain parsing behavior, rate limits, or pagination mechanics, leaving significant 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 a single sentence that efficiently conveys the core action, but it could include more detail without becoming lengthy. It is front-loaded but slightly too terse.
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 four parameters and no output schema, the description is insufficient. It does not describe return values, pagination behavior, or potential issues, making it hard for an agent to anticipate outcomes.
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?
All four parameters have descriptions in the schema (100% coverage). The description does not add any extra meaning or clarify parameter usage beyond what the schema already provides.
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 action ('Scrape Amazon Bestsellers list') and resource, and it is distinct from sibling tools like amazon_search or amazon_product, which focus on different aspects.
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 such as amazon_search or amazon_product. The description omits context about suitable scenarios or when to avoid using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
amazon_pricingCRead-only
Scrape Amazon Product pricing information with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Amazon product ASIN (e.g., "B09H74FXNW") | |
| jsRender | No | Should the request be opened in a headless browser, false by default | |
| domain | No | Amazon domain (e.g., amazon.com, amazon.co.uk) | |
| deviceType | No | Device type to emulate for the request | |
| pageFrom | No | Starting page number for pagination | |
| geo | No | Amazon geo location (e.g., 10001 for US ZIP code) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, which cover the read-only and dynamic nature. The description adds no additional behavioral context such as rate limits, error handling, or parsing specifics.
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?
A single sentence that is efficient and contains no extraneous information, making it easy to read and understand.
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 has six parameters, no output schema, and numerous sibling tools, the description is too minimal. It does not explain the output format, pagination behavior (despite pageFrom parameter), or how automatic parsing works, leaving the agent to infer crucial details.
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 six parameters thoroughly. The description adds no extra meaning beyond what is in the schema, resulting in a baseline score of 3.
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 scrapes Amazon Product pricing information with automatic parsing, which distinguishes it from siblings like amazon_product (full product details) and amazon_search (general search). However, it does not explicitly contrast with these alternatives.
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 other Amazon-related tools like amazon_product or amazon_search, nor are there any exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
amazon_productARead-only
Scrape Amazon Product page with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Amazon product ASIN (e.g., "B09H74FXNW") | |
| jsRender | No | Should the request be opened in a headless browser, false by default | |
| domain | No | Amazon domain (e.g., amazon.com, amazon.co.uk) | |
| deviceType | No | Device type to emulate for the request | |
| geo | No | Amazon geo location (e.g., 10001 for US ZIP code) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds 'automatic parsing' which hints at structured output, but doesn't disclose potential issues like invalid ASIN handling, rate limits, or that it fetches live data from Amazon.
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 sentence with no wasted words. It is front-loaded with the key action and resource. However, it could include one more detail about output without harming 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 absence of an output schema, the description should compensate by explaining what the tool returns (e.g., parsed product data fields). It does not. Also, no mention of error handling or query format validation, making it incomplete for a scraping tool with 5 parameters.
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. The description does not add new meaning beyond the schema; it only restates the overall purpose.
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 'scrape' and the resource 'Amazon Product page', with added context 'automatic parsing'. It distinguishes from sibling tools like amazon_search (lists) and amazon_pricing (prices).
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 does not explicitly state when to use this tool versus alternatives. The context of siblings suggests usage (single product vs. search), but no explicit when-to-use or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
amazon_searchBRead-only
Scrape Amazon Search results with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for Amazon products (e.g., "wireless keyboard") | |
| geo | No | Geolocation of the desired request, expressed as a country name | |
| jsRender | No | Should the request be opened in a headless browser, false by default | |
| domain | No | Amazon domain (e.g., amazon.com, amazon.co.uk) | |
| deviceType | No | Device type to emulate for the request | |
| pageFrom | No | Starting page number for pagination |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and openWorldHint, but the description adds minimal behavioral context. It mentions 'automatic parsing' but does not explain what that entails, rate limits, or error handling.
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?
Single sentence with no redundancy, front-loading the core action. Every word contributes to understanding.
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 tool with 6 parameters and no output schema, the description is too brief. It does not explain output format, pagination behavior, or how 'automatic parsing' works, leaving significant gaps.
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?
All 6 parameters are fully described in the input schema (100% coverage). The description adds no extra semantic meaning beyond the schema.
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 'scrape' and the resource 'Amazon Search results', with 'automatic parsing' adding specificity. It distinguishes from sibling tools like amazon_product and amazon_bestsellers.
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 on when to use this tool vs. alternatives (e.g., amazon_bestsellers, amazon_product). No mention of prerequisites or scenarios where other tools are preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
amazon_sellersBRead-only
Scrape Amazon Seller information with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Amazon seller ID (e.g., "A1R0Z7FJGTKESH") | |
| jsRender | No | Should the request be opened in a headless browser, false by default | |
| domain | No | Amazon domain (e.g., amazon.com, amazon.co.uk) | |
| deviceType | No | Device type to emulate for the request | |
| geo | No | Amazon geo location (e.g., 10001 for US ZIP code) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and openWorldHint, but the description adds no additional behavioral details (e.g., error handling, data freshness, or limits). It merely restates the scraping intent.
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, concise sentence with no wasted words. It front-loads the key action and resource, making it easy to parse.
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 (5 parameters, no output schema), the description is too sparse. It lacks information about return format, error conditions, or usage nuances, leaving gaps despite helpful annotations.
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. The description adds no extra meaning beyond what's in 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Scrape Amazon Seller information with automatic parsing', using a specific verb and resource. It distinguishes from sibling tools like amazon_product or amazon_search, which target different data types.
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 on when to use this tool versus alternatives, nor any mention of prerequisites or exclusions. With many sibling tools, explicit usage context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bing_searchBRead-only
Scrape Bing Search results with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for Bing (e.g., "laptop") | |
| geo | No | Geolocation of the desired request, expressed as a country name | |
| locale | No | Locale of the desired request | |
| jsRender | No | Should the request be opened in a headless browser, false by default | |
| domain | No | Bing domain (e.g., bing.com, bing.co.uk) | |
| deviceType | No | Device type to emulate for the request | |
| pageFrom | No | Starting page number for pagination |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=true. The description adds 'automatic parsing' but no further behavioral details like rate limits, anti-scraping risks, or result structure.
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?
Extremely concise single sentence with no excess words. The most important information (verb, resource, key feature) is front-loaded.
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 7 parameters (including pagination, device type, geo, locale) and no output schema, the description is too minimal. It does not explain how parameters affect results, return format, or pagination behavior.
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?
All 7 parameters have descriptions in the schema (100% coverage). The tool description does not add meaning beyond what the schema already provides, so baseline score of 3 applies.
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?
Description clearly states the specific verb 'Scrape', resource 'Bing Search results', and 'automatic parsing'. It distinguishes from sibling tools like google_search by naming Bing explicitly.
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 on when to use Bing over other search tools (e.g., google_search, amazon_search). No mention of scenarios, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
chatgptBRead-only
Search and interact with ChatGPT for AI-powered responses and conversations
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Prompt to send to ChatGPT | |
| search | No | Activates ChatGPT's web search functionality | |
| geo | No | Geolocation of the desired request, expressed as a country name |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint, which indicate the tool is read-only and may return dynamic results. The description adds no additional behavioral context beyond 'interact', which could be misinterpreted as modifying state but does not contradict annotations.
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 sentence that is concise and to the point. However, it could be more front-loaded with the core function (querying ChatGPT) rather than 'search and interact'.
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?
There is no output schema, and the description does not detail what the tool returns (e.g., format, type of response). Given the openWorldHint, more context about possible outputs would be helpful.
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?
Input schema has 100% description coverage, so the schema already explains each parameter. The description does not add any extra meaning or usage tips for the prompt, search, or geo parameters.
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 is for interacting with ChatGPT to get AI-powered responses. However, it does not differentiate from siblings like 'perplexity' or other search tools, which also offer AI responses.
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 on when to use this tool versus alternatives such as google_search or perplexity. There are no explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
google_adsBRead-only
Scrape Google Ads search results with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for Google Ads (e.g., "laptop") | |
| geo | No | Geolocation of the desired request, expressed as a country name | |
| locale | No | Locale of the desired request | |
| jsRender | No | Should the request be opened in a headless browser, false by default | |
| deviceType | No | Device type to emulate for the request | |
| pageFrom | No | Starting page number for pagination |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds 'with automatic parsing', indicating structured output. No contradictions, but no additional behavioral details (e.g., pagination, rate limits).
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 concise sentence with no wasted words. It is front-loaded with the core purpose.
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?
The description explains the core function but does not specify return format or pagination behavior, despite having no output schema. With openWorldHint, results are dynamic; some elaboration on what 'automatic parsing' yields would improve completeness.
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 coverage is 100% with descriptions for all 6 parameters. The description adds no further meaning beyond the schema, so baseline 3 is appropriate.
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 'Scrape' and the resource 'Google Ads search results', and distinguishes from siblings like google_search by adding 'with automatic parsing'.
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 (e.g., google_search for organic results). It only states what it does, without any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
google_ai_modeARead-only
Scrape Google AI Mode (Search with AI) results with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for Google AI Mode (e.g., "What are the top three dog breeds?") | |
| geo | No | Geo location for AI mode search (e.g., "us", "uk") | |
| deviceType | No | Device type to emulate for the request |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and openWorld. Description adds 'automatic parsing' but no further behavioral traits like rate limits or output structure. Adequate but not rich.
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?
Single sentence, front-loaded with key action, no redundant words. Extremely concise.
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?
Tool is simple with 1 required param and annotations present. Description covers core purpose and parsing feature. Lacks output format info, but acceptable given no 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?
Schema coverage is 100%, so description adds no parameter-level meaning beyond schema. Baseline score of 3 applies.
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?
Describes verb 'scrape' and resource 'Google AI Mode results', with added detail 'automatic parsing'. Clear differentiation from sibling google_search tool.
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 on when to use this tool vs alternatives like google_search. Lacks context for appropriate use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
google_lensARead-only
Scrape Google Lens image search results with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Image URL for Google Lens search (e.g., "https://example.com/image.jpg") | |
| jsRender | No | Should the request be opened in a headless browser, false by default | |
| deviceType | No | Device type to emulate for the request |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds 'automatic parsing' implying structured output but does not detail behavioral traits like rate limits, auth requirements, or error handling. It does not contradict annotations.
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, front-loaded sentence that efficiently conveys the core purpose without extraneous words.
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 output schema and high schema coverage, the description is adequate but does not address output format, limitations, or tips. It leaves some gaps for an agent to infer.
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 already documented. The tool description adds no additional meaning or context beyond what the schema provides.
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 action (scrape), the target resource (Google Lens image search results), and adds a specific qualifier (automatic parsing). It distinguishes itself from sibling tools like google_search and other image tools.
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 on when to use this tool over alternatives like google_search or other scraping tools. The description does not specify context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
google_searchARead-only
Scrape Google Search results with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| geo | No | Geolocation of the desired request, expressed as a country name | |
| locale | No | Locale of the desired request | |
| jsRender | No | Should the request be opened in a headless browser, false by default |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true and openWorldHint=true, indicating safe read operation. Description adds 'automatic parsing' but no further behavioral details. No contradiction.
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?
Single sentence, no redundancy, fully front-loaded with essential purpose. Every word contributes.
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?
No output schema, but description hints at parsed results. For a simple scraper with good annotations, it is adequate but lacks explicit return format details.
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 coverage is 100%, so baseline is 3. Description does not add any parameter-level explanation beyond what the schema provides.
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 'Scrape Google Search results', using a specific verb and resource. It distinguishes from siblings like bing_search or google_ads by explicitly naming Google Search.
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 on when to use this tool over alternatives (e.g., bing_search, google_ads). The description does not provide context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
google_travel_hotelsBRead-only
Scrape Google Travel Hotels search results
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Hotel search query (e.g., "trivago", "hotels in Paris") | |
| jsRender | No | Should the request be opened in a headless browser, false by default | |
| locale | No | Locale of the desired request | |
| deviceType | No | Device type to emulate for the request | |
| pageFrom | No | Starting page number for pagination |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and variability. The description adds no further behavioral context (e.g., pagination, headless browser usage, rate limits) but does not contradict the annotations. Given annotation coverage, a 3 is appropriate.
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 sentence with no wasted words, demonstrating high conciseness. However, it is so brief that it sacrifices informativeness; still, it is well-structured and front-loaded.
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 has 5 parameters, no output schema, and multiple siblings, a single-sentence description is insufficient. It fails to explain return format, pagination, or the effect of optional parameters like jsRender, locale, and deviceType, 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?
All 5 parameters have descriptions in the input schema, achieving 100% schema description coverage. The tool description adds no new meaning beyond the schema, so the baseline score of 3 is correct.
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 'Scrape Google Travel Hotels search results' clearly identifies the tool's action (scrape) and resource (Google Travel Hotels search results). It distinguishes it from sibling tools like google_search (general web search) by specifying 'Travel Hotels', but could be more explicit about its unique scope.
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 such as google_search or other travel-related tools. There is no mention of context, prerequisites, or when not to use it, 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.
perplexityBRead-only
Search and interact with Perplexity for AI-powered responses and conversations
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Prompt to send to Perplexity | |
| geo | No | Geolocation of the desired request, expressed as a country name |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating safe, nondeterministic behavior. The description adds 'AI-powered responses and conversations' but does not elaborate on other traits like rate limits or output format.
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 concise sentence, but could be slightly improved by removing redundancy ('responses and conversations') and adding sibling differentiation without increasing length.
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 simplicity and the presence of annotations and full schema coverage, the description lacks contextual cues for an agent to distinguish it from similar AI tools, especially without output schema details.
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 coverage is 100% with descriptions for both parameters. The description does not add additional meaning beyond the schema, such as how to format the prompt or when geo is useful.
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 identifies the resource (Perplexity) and action (search and interact), but it does not differentiate from sibling tools like chatgpt or google_ai_mode, which also provide AI-powered responses.
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 Perplexity versus alternatives, such as when AI-powered search is preferred over traditional search (bing_search, google_search) or other AI chatbots (chatgpt).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reddit_postARead-only
Scrape a specific Reddit post
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | reddit post URL (eg. https://www.reddit.com/r/hometheater/comments/1jz9xk5/lg_ubk90_only_works_when_plugged_into_tv_via) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile and open-ended return are covered. The description adds no behavioral context beyond 'Scrape', which is acceptable but not additive given the annotations.
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?
Single concise sentence with no extraneous text. Every word is necessary.
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 simple one-parameter tool with no output schema, the description is largely sufficient. It could optionally hint at the type of data returned (e.g., title, content) but openWorldHint implies variety, so 4 is reasonable.
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 has 100% description coverage for the 'url' parameter, including an example. The description does not add further meaning or format details, so baseline 3 is appropriate.
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 'Scrape a specific Reddit post' uses a clear verb ('scrape') and specifies the exact resource ('specific Reddit post'). It distinguishes from sibling tools like 'reddit_subreddit' and 'reddit_user', which target different Reddit entities.
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 'reddit_subreddit' or 'reddit_user'. The description lacks context for preferred usage or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reddit_subredditBRead-only
Scrape Reddit subreddit results with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to subreddit |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint (true) and openWorldHint (true), covering safety and openness. The description adds 'with automatic parsing' but provides no additional behavioral details (e.g., rate limits, data freshness, or what parsing entails).
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?
One short sentence that is efficient and front-loaded. However, it could be slightly more informative without losing 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?
No output schema exists, yet the description does not hint at what the tool returns (e.g., list of posts, post details). For a scraping tool, this omission is significant. Annotations help but do not fulfill the need for expected output.
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% (parameter 'url' documented). The tool description adds 'subreddit results' context but does not enrich the parameter meaning beyond the schema's 'URL to subreddit'. Baseline score of 3 is appropriate.
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 action 'Scrape Reddit subreddit results' with a specific verb and resource. It distinguishes from siblings like 'reddit_post' (single post) and 'reddit_user', making its purpose unambiguous.
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 on when to use this tool versus alternatives (e.g., reddit_post, reddit_search). The description does not provide context for selecting this tool among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reddit_userARead-only
Scrape a Reddit user profile and their posts/comments
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Reddit user profile URL (eg. https://www.reddit.com/user/IWasRightOnce/) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds context by specifying that it scrapes profile and posts/comments, providing valuable behavioral detail beyond annotations.
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, clear sentence that efficiently conveys the tool's purpose without unnecessary words.
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 simple one-parameter schema, no output schema, and annotations covering safety, the description sufficiently informs the agent. However, it could detail what data is returned (e.g., list of posts vs full content).
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% coverage with a description for the single parameter 'url'. The description does not add additional parameter meaning beyond the schema.
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?
Description uses specific verb 'scrape' and resource 'Reddit user profile and their posts/comments', clearly distinguishing it from siblings like reddit_post and reddit_subreddit.
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 when-to-use or alternatives guidance is given. The description implies scraping user data but lacks direction compared to sibling tools that target specific content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scrape_as_markdownBRead-only
Scrape the contents of a website and return Markdown-formatted results
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to scrape | |
| geo | No | Geolocation of the desired request, expressed as a country name | |
| locale | No | Locale of the desired request | |
| jsRender | No | Should the request be opened in a headless browser, false by default | |
| tokenLimit | No | The number of tokens to return in the response - anything above this limit will be truncated |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds no behavioral info beyond the purpose. It does not mention truncation via tokenLimit, potential rate limits, or any side effects. The description is adequate but not enhanced.
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 sentence that front-loads the main purpose. It is concise but arguably too brief; could include more detail without losing conciseness. Still, it's efficient.
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?
The tool has 5 parameters but no output schema. The description only mentions 'Markdown-formatted results' without details on structure, errors, or truncation behavior. For a web scraper used by an AI agent, more completeness would be beneficial. The annotations help but the description is lacking.
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?
Input schema has 100% description coverage for all 5 parameters, so the schema itself explains each parameter. The description does not add further meaning or usage context for the parameters. Baseline score of 3 is appropriate.
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 action (scrape) and resource (website contents) and output format (Markdown). It distinguishes from siblings like google_search or amazon_product by being a general-purpose web scraper. However, it could be more specific about the scope of content scraped (e.g., full page vs text).
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 the specialized scrapers (e.g., amazon_bestsellers, target_product). An agent would not know if this tool is appropriate for a given site or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
screenshotARead-only
Capture a screenshot of any webpage and return it as a PNG image
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to screenshot | |
| geo | No | Geolocation of the desired request, expressed as a country name |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint (safe read) and openWorldHint (may fetch external content). The description confirms it captures screenshots from any webpage, which is consistent. However, it does not disclose potential issues like website blocking, timeouts, or output encoding (e.g., base64 vs binary).
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?
Single sentence with no unnecessary words. Front-loaded with the key action and output format.
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?
The description is sufficient for a simple screenshot tool but lacks details about return format (e.g., whether PNG is returned as base64 or binary blob). No output schema exists to compensate. Adequate but not comprehensive.
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 covers 100% of parameters with brief descriptions. The tool description adds no additional meaning beyond what the schema provides. Baseline score of 3 is appropriate.
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 action ('Capture a screenshot'), the resource ('any webpage'), and the output format ('PNG image'). It distinguishes from sibling tools which are primarily search or text extraction tools.
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 provided on when to use this tool versus alternatives like scrape_as_markdown or google_lens. The description does not mention limitations or contexts where screenshot might be inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
target_productBRead-only
Scrape Target Product page with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | Target product ID (e.g., "1003921355") | |
| jsRender | No | Should the request be opened in a headless browser, false by default | |
| deviceType | No | Device type to emulate for the request | |
| deliveryZip | No | ZIP code for delivery location | |
| storeId | No | Target store ID for local inventory |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true, so the description's addition of 'automatic parsing' adds minimal behavioral context. No contradiction, but no elaboration on scraping behavior (e.g., rate limits, page structure).
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?
Single sentence is concise and front-loaded. No unnecessary words; every phrase earns its place.
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?
With 5 parameters and no output schema, the description is too minimal. It does not explain what data is returned (e.g., price, title) or how 'automatic parsing' works, leaving significant gaps for an agent.
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 all parameters are documented in the schema. The description does not repeat or add value beyond that; baseline of 3 is appropriate.
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 'Scrape Target Product page with automatic parsing' clearly states the tool's function (scraping a specific product page) and distinguishes it from siblings like target_search (which searches) and other product scraping tools.
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 on when to use this tool versus alternatives (e.g., target_search for multiple products). The description does not mention prerequisites or context like requiring a valid product_id, which is only evident from the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
target_searchBRead-only
Scrape Target Search results with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for Target products | |
| jsRender | No | Should the request be opened in a headless browser, false by default | |
| deviceType | No | Device type to emulate for the request | |
| deliveryZip | No | ZIP code for delivery location | |
| storeId | No | Target store ID for local inventory |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint, so the description adds limited behavioral context. 'Automatic parsing' hints at structured output, but details like data freshness, rate limits, or result format are absent. Adequate given annotations but not exceptional.
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 concise sentence that delivers the core purpose without wasted words. It is efficient but could benefit from additional context without becoming verbose.
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 tool with no output schema and 5 parameters, the description does not elaborate on return values, pagination, or error handling. Siblings are similar, but the description lacks completeness for an agent to understand expected results fully.
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?
Input schema has 100% coverage with descriptions for all 5 parameters. The description adds no new semantic detail beyond what the schema provides, resulting in a baseline score of 3.
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 scrapes Target search results with automatic parsing, specifying both the action (scrape) and the resource (Target search results). This distinguishes it from sibling tools like 'target_product' which focus on specific products, and from other retailer search tools.
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 'amazon_search' or 'walmart_search'. There is no mention of scenarios where this tool is preferred or any conditions to avoid using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_postARead-only
Scrape a TikTok post URL for structured data such as engagement, captions, and hashtags
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | TikTok post URL, e.g. https://www.tiktok.com/@user/video/1234567890 | |
| xhr | No | When true, includes XHR/fetch responses in the scrape result where supported by the target |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds that the tool extracts structured data (engagement, captions, hashtags), but does not disclose additional behavioral traits like error handling, rate limits, or response format. It is consistent with annotations, adding modest context.
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, clear sentence that front-loads the purpose. No redundant or unnecessary words.
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 simple scrape tool with two parameters and annotations, the description is adequate but incomplete. It does not explain the output structure or error conditions, though annotations partially compensate. An output schema would improve completeness.
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 coverage is 100% with both parameters well-described. The description does not add meaning beyond the schema, such as clarifying the 'xhr' parameter's effect. Baseline 3 is appropriate.
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 'scrape' and the resource 'TikTok post URL', and lists specific data types (engagement, captions, hashtags). It distinguishes the tool from siblings like tiktok_shop_product by targeting post URLs specifically.
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 (e.g., tiktok_shop_product for shop data). It lacks explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_shop_productARead-only
Scrape TikTok Shop Product page
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | TikTok Shop product ID (e.g., "1731541214379741272") | |
| jsRender | No | Should the request be opened in a headless browser, false by default | |
| deviceType | No | Device type to emulate for the request | |
| country | No | Country code for the request (e.g., US, GB, DE) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, openWorldHint=true) already indicate a safe read operation. The description adds no further behavioral details beyond 'scrape', which is consistent. No additional context like rate limits or data format is provided.
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 sentence, which is concise and front-loaded. Every word serves a purpose, but could be expanded with minimal additional context without losing 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 four parameters and no output schema, the description should ideally mention what data is returned or any significant constraints. It lacks such details, making it incomplete for a scraping tool.
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 for all four parameters. The description does not add any additional meaning or nuance beyond what the schema already provides, so baseline score of 3 is appropriate.
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 'Scrape TikTok Shop Product page' uses a specific verb and resource, clearly indicating the tool's function. It is distinguishable from sibling tools like tiktok_shop_search and tiktok_post.
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 (scraping product details) but provides no explicit guidance on when to use this tool versus alternatives or any exclusions. The context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_shop_searchARead-only
Scrape TikTok Shop Search results with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for TikTok Shop products | |
| geo | No | Geolocation of the desired request, expressed as a country name | |
| jsRender | No | Should the request be opened in a headless browser, false by default | |
| country | No | Country code for the request (e.g., US, GB, DE) | |
| deviceType | No | Device type to emulate for the request |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world behavior. 'Scrape' and 'automatic parsing' add minimal extra context but do not cover rate limits, result formatting, or error handling.
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?
A single, well-structured sentence that is front-loaded with the action and resource, containing no superfluous words.
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 search tool with 5 parameters and no output schema, the description lacks details on result format, pagination, or usage constraints, making it minimally adequate.
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?
Input schema has 100% description coverage, so the description adds no additional meaning to the parameters beyond what the schema already provides.
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 specifies the action (scrape) and resource (TikTok Shop Search results) and differentiates from sibling tools like tiktok_shop_product and tiktok_shop_url.
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 such as other search tools or product-specific TikTok Shop tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_shop_urlBRead-only
Scrape TikTok Shop page by URL
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | TikTok Shop URL (e.g., "https://www.tiktok.com/shop/s?q=HEADPHONES") | |
| jsRender | No | Should the request be opened in a headless browser, false by default |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already confirm readOnlyHint and openWorldHint, so the description adds minimal behavioral context. It does not disclose what 'scrape' entails (e.g., rate limits, data format, or side effects), but annotations cover the safety profile adequately.
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, short sentence with no filler. Every word is informative and structurally efficient.
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 (2 params, no output schema), the description omits important details like return format or how jsRender affects scraping. It is insufficient for an agent to fully understand tool behavior.
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 coverage is 100%, so the input schema already explains both parameters. The description adds no additional parameter-level information beyond what is in the schema, hence baseline score.
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 'Scrape TikTok Shop page by URL' clearly states the action (scrape) and resource (TikTok Shop page). However, it does not differentiate between related sibling tools like tiktok_shop_product or tiktok_shop_search, which may cause confusion.
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. The sibling tools exist but are not mentioned, and there is no discussion of prerequisites or usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
walmart_productARead-only
Scrape Walmart Product page with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | Walmart product ID (e.g., "15296401808") | |
| jsRender | No | Should the request be opened in a headless browser, false by default | |
| deliveryZip | No | ZIP code for delivery location | |
| storeId | No | Walmart store ID for local inventory |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a read-only operation (readOnlyHint=true) and potential open-world effects (openWorldHint=true). The description adds 'automatic parsing' but omits other behavioral traits such as rate limits, authentication needs, or error handling. With annotations present, the description adds some value but leaves 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 extremely concise—one sentence that front-loads the core action and resource. It contains no fluff or repetition, making it easy for an agent 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?
While the schema and annotations cover basic details, the lack of an output schema places burden on the description. 'Automatic parsing' is vague about the return format. For a scraping tool, more context about what data is extracted or error conditions would improve completeness.
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. The description does not add meaning beyond the schema; 'automatic parsing' hints at output format but not parameter-specific details. Baseline 3 is appropriate.
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 action ('Scrape'), the resource ('Walmart Product page'), and adds 'with automatic parsing' hinting at structured output. It effectively distinguishes from sibling tools like walmart_search.
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 for scraping a single product page but provides no explicit when-to-use or when-not-to-use guidance. No alternatives or exclusions are mentioned, leaving the agent to infer context 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.
walmart_searchBRead-only
Scrape Walmart Search results with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for Walmart products (e.g., "camping tent") | |
| jsRender | No | Should the request be opened in a headless browser, false by default | |
| deviceType | No | Device type to emulate for the request | |
| deliveryZip | No | ZIP code for delivery location | |
| storeId | No | Walmart store ID for local inventory |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds 'automatic parsing' but does not elaborate on behavior (e.g., result structure, pagination, rate limits). With annotations covering safety, the description provides minimal additional transparency.
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?
Single sentence, no redundancy, efficiently conveys the core function.
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?
No output schema exists, yet the description omits details about return values (e.g., fields returned, format, pagination). For a tool with 5 parameters and no output schema, the description is insufficiently complete.
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 input schema already documents all parameters. The tool description does not add further meaning beyond what the schema provides, thus baseline score of 3.
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 specifies the verb 'Scrape' and the resource 'Walmart Search results' with 'automatic parsing', clearly distinguishing it from sibling tools like walmart_product (product details) and other search tools (amazon_search, target_search).
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 on when to use this tool versus alternatives (e.g., walmart_product, target_search) or when not to use it. The description lacks any context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
youtube_channelBRead-only
Scrape YouTube channel videos with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | YouTube channel handle or ID (e.g., "@decodo_official") | |
| limit | No | Maximum number of videos to return |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral details beyond annotations (readOnlyHint, openWorldHint). It does not disclose rate limits, pagination, or output format.
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?
Single sentence, no wasted words, but could provide more context without sacrificing brevity.
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 output schema, the description is too minimal. Missing details on results, pagination, or parsing behavior.
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 covers both parameters with descriptions; the description adds no extra meaning, 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 tool scrapes YouTube channel videos with automatic parsing, distinguishing it from siblings like youtube_metadata, youtube_search, and youtube_subtitles.
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 on when to use this tool versus alternatives like youtube_search or youtube_metadata. Missing context for optimal usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
youtube_metadataBRead-only
Scrape YouTube video metadata
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | YouTube video ID (e.g., "dFu9aKJoqGg") |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations readOnlyHint and openWorldHint indicate safe, read-only operation. The description adds minimal behavioral context beyond confirming read-only scraping. No mention of rate limits, authentication, error handling, or return types.
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?
Single sentence is concise, but it is a phrase rather than a full sentence. Could be improved with a more structured description like 'Retrieves metadata for a YouTube video given its ID.' Still efficient.
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?
No output schema is present, and the description does not specify what metadata fields are returned (e.g., title, views, likes). Given the tool's simplicity and lack of output schema, the description is incomplete for an agent to determine usefulness.
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 covers 100% of parameters and describes the single required 'query' parameter as a YouTube video ID with an example. The description adds no further meaning, so baseline 3 applies.
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 states the tool scrapes YouTube video metadata, which is a specific verb+resource. However, it doesn't detail what metadata fields are included, leaving some ambiguity. It is clearly distinct from siblings like youtube_search or youtube_subtitles.
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 indication of when to use this tool versus alternatives such as youtube_search or youtube_channel. No explicit usage context, prerequisites, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
youtube_searchBRead-only
Search YouTube videos
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | YouTube search query (e.g., "How to care for chinchillas") |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and openWorldHint=true, implying the tool is safe and results may vary. The description does not add behavioral details beyond annotations, but there is no contradiction. It meets the minimum added value for a tool with such annotations.
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, succinct sentence that directly states the tool's purpose. It is front-loaded and contains no unnecessary words, earning a perfect score 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?
With no output schema, the description should explain what the tool returns (e.g., list of video IDs, titles). It only states the action, leaving agents to infer the output format. Basic contextual information is missing, making it incomplete.
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 fully describes the single parameter 'query' with a clear description and example. The description adds no further semantic value beyond the schema, but the schema coverage is 100%, so a baseline of 3 is appropriate.
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 action ('Search') and resource ('YouTube videos'), making the purpose unambiguous. While the name itself conveys the tool's domain, the description does not differentiate it from sibling search tools like 'google_search' or 'bing_search', but the resource specificity is sufficient.
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 (e.g., 'google_search' for general web search, 'youtube_metadata' for specific video details). The description lacks explicit context for choosing this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
youtube_subtitlesBRead-only
Scrape YouTube video subtitles
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | YouTube video ID (e.g., "L8zSWbQN-v8") | |
| language_code | No | Language code for subtitles (e.g., "en", "es") |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint, but the description adds no further behavioral context (e.g., rate limits, required format for video ID).
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?
Single sentence with no unnecessary words, effectively communicates the tool's purpose.
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 simplicity and schema coverage, the description is adequate but lacks mention of return format (no output schema) and usage context.
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?
Input schema covers 100% of parameters with descriptions, so the description adds no additional meaning beyond the schema.
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?
Description 'Scrape YouTube video subtitles' clearly states the verb and resource, distinguishing it from siblings like youtube_metadata and youtube_search.
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 on when to use this tool versus alternatives such as youtube_search or youtube_metadata, nor any conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
30 tool updates
- First observed
amazon_bestsellers - First observed
amazon_pricing - First observed
amazon_product - First observed
amazon_search - First observed
amazon_sellers - First observed
bing_search - First observed
chatgpt - First observed
google_ads - First observed
google_ai_mode - First observed
google_lens - First observed
google_search - First observed
google_travel_hotels - First observed
perplexity - First observed
reddit_post - First observed
reddit_subreddit - First observed
reddit_user - First observed
scrape_as_markdown - First observed
screenshot - First observed
target_product - First observed
target_search - First observed
tiktok_post - First observed
tiktok_shop_product - First observed
tiktok_shop_search - First observed
tiktok_shop_url - First observed
walmart_product - First observed
walmart_search - First observed
youtube_channel - First observed
youtube_metadata - First observed
youtube_search - First observed
youtube_subtitles
TDQS
Tools are mostly distinct by platform and data type, but some overlap exists within Google (search, ads, AI mode, Lens) and between AI chat tools (chatgpt, perplexity). Descriptions help differentiate.
Naming follows a consistent 'platform_what' pattern for most tools, but a few outliers like 'scrape_as_markdown', 'screenshot', 'chatgpt', and 'perplexity' break the pattern.
30 tools is at the high end of reasonable. The server covers many scraping targets, but could be split into per-platform servers. Not excessive, but bordering on heavy.
Covers major platforms (Amazon, Google, Reddit, TikTok, Walmart, YouTube) but missing others (Facebook, Twitter, Instagram) and some common scraping operations (reviews, comments, posts). Decent but not exhaustive.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Crawl, scrape, search the web, and automate browsers at scale with anti-bot bypass.
ScrapeUnblocker: ScrapeUnblocker allows to bypass anti-bot services and scrape the full page source.
The most accurate web access API. Stop getting blocked.
Hundreds of scraping & data APIs through one key. USD pay-per-request, normalized schemas, failover.
Related MCP Servers
- AlicenseBqualityDmaintenanceAnthropic's github MCP server, but better. Support for more endpoints. Including releases and tags, pull request reviews, statuses, rate limit, gists, projects, packages, and even pull request diffs. Indented to be used with MissionSquad's MCP API for secret management (aka your access token).4586110MIT
- AlicenseNot gradedqualityDmaintenanceEnables web scraping and document processing with JavaScript execution, anti-detection measures, batch processing, and structured data extraction. Supports multiple formats including markdown, HTML, screenshots, and handles PDFs with OCR capabilities.4MIT
- AlicenseAqualityBmaintenanceEnables AI agents to scrape any website by providing tools for JavaScript rendering, antibot bypass, and automatic captcha solving. It supports synchronous, asynchronous, and batch scraping operations with built-in proxy rotation.5207MIT
- AlicenseAqualityAmaintenanceEnables web scraping, structured data extraction, and screenshot capture with automatic anti-bot bypass, supporting JavaScript rendering, proxy rotation, and tiered pricing.252181MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Decodo/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server