Decodo MCP Server
Decodo MCP 服务器
使用 MCP(模型上下文协议)将 LLM 和 AI 代理连接到实时网络数据。Decodo MCP 服务器让您可以直接从 Claude、Cursor 和 Windsurf 等 AI 工具中抓取网站、搜索引擎、电商平台和社交媒体,无需从头构建抓取基础设施。
结构化输出,支持 JSON、Markdown 和截图
服务端 JavaScript 渲染和反机器人处理
覆盖 195+ 个地区的 1.25 亿+ IP
什么是 Decodo MCP 服务器?
Decodo MCP 服务器是面向 AI 代理的网络抓取层。它将兼容 MCP 的客户端连接到 Decodo 的 Web 抓取 API,支持:
面向 LLM 的网络抓取
用于 RAG 的实时数据检索
AI 代理浏览和研究
从动态网站提取结构化数据
无需维护代理、解析器和重试逻辑,您只需一个集成点即可获得可靠的网络数据访问。
Related MCP server: FreeCrawl MCP Server
为什么使用 MCP 进行网络抓取?
模型上下文协议(MCP)是将 AI 代理连接到外部工具和数据源的新兴标准。使用 MCP:
代理可以动态调用工具
集成保持标准化
工作流可跨环境扩展
Decodo MCP 服务器通过这一标准为您的代理提供可靠、生产级的网络访问能力。
主要特性
面向 AI 代理的网络抓取,无需基础设施。 抓取任何网站,包括 JavaScript 密集型页面,无需处理代理轮换、CAPTCHA 验证或反机器人系统。
面向 LLM 工作流的结构化输出。 Markdown(LLM 就绪)、JSON(用于结构化管道)和 截图(用于视觉上下文),专为 RAG 管道、AI 研究代理和自动化流程而构建。
内置对热门目标的支持。 为 Google 和 Bing(搜索引擎结果页)、Amazon、 Walmart 和 Target(电商)、Reddit、TikTok 和 YouTube(社交媒体)以及 ChatGPT 和 Perplexity(AI 搜索)提供现成工具。
全球代理基础设施。 1.25 亿+ 住宅 IP、195+ 地理位置,即使面对保护最严密的 目标也能实现 99.99% 的成功率。
模块化 MCP 工具集。 只启用您需要的功能:web、search、ecommerce、social_media、
ai,实现更简洁的工具选择和更好的代理性能。
快速见效。 从获取 API 密钥到首次抓取只需几分钟,无需任何设置开销。
使用场景
当您需要面向 AI 代理的网络抓取、大规模结构化数据提取、对动态网站的可靠访问、用于 RAG 的实时数据,或希望替代从头构建抓取基础设施时,请使用 Decodo MCP 服务器。常见场景:
AI 驱动的网络抓取 – 让 LLM 能够收集新鲜数据,而不是依赖静态训练数据。
带实时数据的 RAG – 将实时的 Google、Bing 和 AI 搜索结果拉入检索管道。
电商情报 – 跨市场跟踪产品价格、列表和卖家,而不会被屏蔽。
社交媒体数据收集 – 从 Reddit、TikTok 和 YouTube 收集帖子、频道和互动数据。
旅行和价格聚合 – 构建跨网站收集实时定价和可用性的工具。
快速开始
创建免费账户,访问 dashboard.decodo.com – 最高 2K 次免费请求,无需信用卡。
获取您的 API 密钥。 从仪表板获取 Web 抓取 API 基本认证令牌。
下载 Node.js 18+,从 https://nodejs.org。
获取 MCP 客户端,如 Claude Desktop、Cursor、Windsurf 或其他兼容 MCP 的 工具。
在您的 AI 客户端中配置 MCP 服务器(请参阅下面的配置示例)。
连接到 Decodo 的 MCP 服务器
打开您首选的 MCP 客户端并添加以下配置(请参阅下面 Claude Code、Cursor、Windsurf 的示例):
{
"mcpServers": {
"Decodo": {
"url": "https://mcp.decodo.com/mcp",
"headers": {
"Authorization": "Basic <basic_auth_token>"
}
}
}
}Claude Desktop
打开 Claude Desktop → 设置 → 开发者 → 编辑配置。
添加到 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
打开设置 → MCP。
点击添加新的全局 MCP 服务器(打开 mcp.json)。
添加上面的相同配置。
保存 — 在 Decodo 旁边查找绿色状态指示器。
Windsurf
打开设置 → Windsurf 设置。
滚动到 Cascade → 添加自定义服务器 +(打开 mcp_config.json)。
添加上面的相同配置。
保存并重启 Windsurf。
测试您的设置
连接后,在您的客户端中尝试以下提示:
▎ "抓取 Hacker News 上排名前 5 的文章标题"
您应该在几秒钟内收到结构化列表。如果看到认证错误,请从仪表板仔细检查您的令牌。
可选:启用特定工具集
本地运行 MCP 服务器
前提条件
Node.js 18.0+
一个 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 格式返回结果。 | 从美国 IP 地址抓取 peacock.com 并告诉我定价。 |
| 捕获任意网页的截图,并以 PNG 图片形式返回。 | 从美国 IP 地址截取 github.com 的截图。 |
| 抓取 Google 搜索的给定查询,并返回解析后的结果。 | 抓取 Google 搜索“鞋子”并告诉我排名第一的位置。 |
| 抓取 Google Ads 搜索结果。 | 抓取 Google Ads 中“笔记本电脑”的广告并展示排名靠前的广告。 |
| 抓取 Google Lens 图片搜索结果。 | 在 Google Lens 中搜索此图片:https://example.com/image.jpg |
| 抓取 Google AI 模式(AI 搜索)的结果。 | 询问 Google AI 模式:最受欢迎的三种犬种是什么? |
| 抓取 Google Travel Hotels 搜索结果。 | 在 Google Travel Hotels 中搜索巴黎的酒店。 |
| 抓取 Amazon 搜索的给定查询,并返回解析后的结果。 | 抓取 Amazon 搜索“无线键盘”。 |
| 抓取 Amazon 产品页面。 | 抓取 Amazon 产品 B09H74FXNW 并展示详细信息。 |
| 抓取 Amazon 产品定价信息。 | 获取 Amazon 产品 B09H74FXNW 的定价。 |
| 抓取 Amazon 卖家信息。 | 获取 Amazon 卖家 A1R0Z7FJGTKESH 的信息。 |
| 抓取 Amazon 畅销榜列表。 | 展示 Amazon 电子产品类畅销榜。 |
| 抓取 Walmart 搜索的给定查询,并返回解析后的结果。 | 抓取 Walmart 搜索“露营帐篷”。 |
| 抓取 Walmart 产品页面。 | 抓取 Walmart 产品 15296401808。 |
| 抓取 Target 搜索的给定查询,并返回解析后的结果。 | 抓取 Target 搜索“厨房电器”。 |
| 抓取 Target 产品页面。 | 抓取 Target 产品 92186007。 |
| 抓取 TikTok 帖子 URL 以获取结构化数据(例如互动量、标题、标签)。 | 抓取此 TikTok 帖子:https://www.tiktok.com/@nba/video/7393013274725403950 |
| 抓取 TikTok Shop 搜索的给定查询,并返回解析后的结果。 | 抓取 TikTok Shop 搜索“手机壳”。 |
| 抓取 TikTok Shop 产品页面。 | 抓取 TikTok Shop 产品 1731541214379741272。 |
| 通过 URL 抓取 TikTok Shop 页面。 | 抓取此 TikTok Shop URL: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 子版块结果。 | 抓取本周 r/Python 上排名前 5 的帖子。 |
| 抓取 Reddit 用户个人资料及其帖子和评论。 | 抓取此 Reddit 用户:https://www.reddit.com/user/IWasRightOnce/ |
| 抓取 Bing 搜索结果。 | 在 Bing 上搜索笔记本电脑评测。 |
| 搜索并与 ChatGPT 交互,获取 AI 驱动的回复和对话。 | 让 ChatGPT 用简单术语解释量子计算。 |
| 搜索并与 Perplexity 交互,获取 AI 驱动的回复和对话。 | 询问 Perplexity 网页开发的最新趋势是什么。 |
参数
以下参数根据用户提示推断:
参数 | 描述 |
| 在无头浏览器中渲染目标 URL。 |
| 设置请求来源国家。 |
| 设置请求的区域设置。 |
| 将响应内容截断到此限制。当上下文窗口较小时很有用。 |
| 发送给 AI 工具( |
| 激活 ChatGPT 的网页搜索功能(仅限 |
| 当为 true 时,在支持的抓取结果中包含 XHR 或 fetch 响应(例如 |
| 请求模拟的设备类型( |
| 请求使用的域名(例如 |
| 分页的起始页码。 |
| 配送地点的邮政编码(Target、Walmart)。 |
| 本地库存的商店 ID(Target、Walmart)。 |
| TikTok Shop 请求的国家。 |
| 返回的最大结果数(例如 YouTube 频道视频)。 |
| 字幕的语言代码(例如 |
示例
抓取受地理限制的内容
使用以下提示查询你的 AI 代理:
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.如果你的代理上下文窗口较大,告诉它返回 full content:
Scrape hacker news, return full content.与 Decodo 代理技能配合使用
此服务器为你的代理提供抓取 工具。Decodo/agent-skills
教它何时使用这些工具、哪个界面以及如何调用——这样代理就能自行选择正确的工具和参数,而不是猜测。
这些技能可跨 decodo CLI、此托管的 MCP 服务器以及原始 HTTP API 使用,并在没有 shell 可用时自动回退到 MCP 服务器。将两者结合,你的代理就能在单一设置中同时获得执行层(此服务器)和决策层(技能)。
快速开始(Claude Code):
/plugin marketplace add Decodo/agent-skills
/plugin install decodo@decodo-skills有关手动安装和其他代理(Cursor、Codex、Gemini CLI、Windsurf)的信息,请参阅 agent-skills README。
相关仓库
Web Scraping API、 Decodo agent skills、 Decodo OpenClaw skill
试用
只需点击几下,即可将 Decodo MCP Server 集成到你的 AI 工作流中,让你的 AI 代理能够从任何网站获取实时数据。
许可证
所有代码均根据 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.
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
Scored across 30 tools
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
Related MCP Connectors
Crawl, scrape, search the web, and automate browsers at scale with anti-bot bypass.
Web scraping, SERP search, crawl/map and 74 Collectors through residential proxies. 25 tools.
Scraping API for Google Search, Maps, Flights, Jobs, YouTube, LinkedIn, Trustpilot and more.
Scrape any web page, search Google/Amazon/Walmart/YouTube and extract data via the ScrapingBee API.
181
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).451,920 npm10MIT
- 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.5207 npm60 PyPIMIT
- AlicenseAqualityAmaintenanceEnables web scraping, structured data extraction, and screenshot capture with automatic anti-bot bypass, supporting JavaScript rendering, proxy rotation, and tiered pricing.25198 npmMIT