MCP（Model Context Protocol）を使用して、LLM や AI エージェントをライブ Web データに接続します。Decodo MCP Server を使用すると、Claude、Cursor、Windsurf などの AI ツールから直接、Web サイト、検索エンジン、eコマースプラットフォーム、ソーシャルメディアをスクレイピングできます。スクレイピングインフラをゼロから構築する必要はありません。
JSON、Markdown、スクリーンショットでの構造化出力
サーバーサイドの JavaScript レンダリングとアンチボット処理
195以上のロケーションにわたる 1億2,500万以上の IP
Decodo MCP Server は、AI エージェント向けの Web スクレイピングレイヤーです。MCP 互換クライアントを Decodo の Web Scraping API に接続し、以下を可能にします：
LLM 向け Web スクレイピング
RAG 向けリアルタイムデータ取得
AI エージェントによるブラウジングとリサーチ
動的 Web サイトからの構造化データ抽出
プロキシ、パーサー、リトライロジックを維持する代わりに、信頼性の高い Web データアクセスのための単一の統合ポイントを利用できます。
Related MCP server: FreeCrawl MCP Server
Model Context Protocol（MCP）は、AI エージェントを外部ツールやデータソースに接続するための新たな標準規格です。MCP を使用すると：
エージェントがツールを動的に呼び出せる
統合が標準化される
ワークフローが環境を超えてスケールする
Decodo MCP Server は、この標準を通じて、エージェントに信頼性の高い本番環境対応の Web アクセスを提供します。
AI エージェント向け Web スクレイピング、インフラ不要。 プロキシローテーション、CAPTCHA 解決、アンチボットシステムを処理することなく、JavaScript を多用したページを含むあらゆる Web サイトをスクレイピングできます。
LLM ワークフロー向けの構造化出力。 Markdown（LLM 対応）、JSON（構造化パイプライン用）、スクリーンショット（視覚的コンテキスト用）を提供。RAG パイプライン、AI リサーチエージェント、自動化フロー向けに設計されています。
人気ターゲット向けの組み込みサポート。 Google と Bing（SERP）、Amazon、Walmart、Target（eコマース）、Reddit、TikTok、YouTube（ソーシャルメディア）、ChatGPT と Perplexity（AI 検索）向けのすぐ使えるツールを用意。
グローバルプロキシインフラ。 1億2,500万以上の住宅用 IP、195以上の地理的ロケーション、そして最も保護されたターゲットでも 99.99% の成功率を実現。
モジュール式 MCP ツールセット。 必要なものだけを有効化：web、search、ecommerce、social_media、ai。ツール選択がクリーンになり、エージェントのパフォーマンスが向上します。
すぐに価値を実現。 API キーから最初のスクレイピングまで数分。セットアップのオーバーヘッドはありません。
AI エージェント向け Web スクレイピング、大規模な構造化データ抽出、動的 Web サイトへの信頼性の高いアクセス、RAG 向けリアルタイムデータ、またはスクレイピングインフラをゼロから構築する代替手段が必要な場合に、Decodo MCP Server を使用します。一般的なシナリオ：
AI 搭載 Web スクレイピング – 静的トレーニングデータに依存する代わりに、LLM に新鮮なデータを収集する能力を提供。
ライブデータによる RAG – リアルタイムの Google、Bing、AI 検索結果を検索パイプラインに取り込む。
eコマースインテリジェンス – ブロックされることなく、マーケットプレイス全体の商品価格、リスト、販売者を追跡。
ソーシャルメディアデータ収集 – Reddit、TikTok、YouTube から投稿、チャンネル、エンゲージメントデータを収集。
旅行・価格アグリゲーション – 複数の Web サイトにわたるライブ価格と在庫を収集するツールを構築。
無料アカウントを作成 dashboard.decodo.com で – 最大 2K リクエスト無料、クレジットカード不要。
API キーを取得。 ダッシュボードから Web Scraping API の Basic 認証トークンを取得します。
Node.js 18+ をダウンロード https://nodejs.org から。
MCP クライアントを入手 Claude Desktop、Cursor、Windsurf、その他の MCP 互換 ツールなど。
AI クライアントで MCP サーバーを設定（以下の設定例を参照）。
お好みの MCP クライアントを開き、以下の設定を追加します（Claude Code、Cursor、Windsurf の例は以下を参照）：
{
"mcpServers": {
"Decodo": {
"url": "https://mcp.decodo.com/mcp",
"headers": {
"Authorization": "Basic <basic_auth_token>"
}
}
}
}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 を再起動。
設定 → MCP を開く。
新しいグローバル MCP サーバーを追加（mcp.json が開きます）。
上記と同じ設定を追加。
保存 – Decodo の横に緑色のステータスインジケーターが表示されることを確認。
設定 → Windsurf 設定を開く。
Cascade までスクロール → カスタムサーバーを追加 +（mcp_config.json が開きます）。
上記と同じ設定を追加。
保存して Windsurf を再起動。
接続後、クライアントで次のプロンプトを試してください：
▎ "Hacker News の上位5記事のタイトルをスクレイピングしてください"
数秒以内に構造化されたリストが返されます。認証エラーが表示された場合は、ダッシュボードのトークンを再確認してください。
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.jsMCP クライアントをサーバー情報で更新：
{
"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>"
}
}ツールセットが指定されていない場合、すべてのツールが登録されます。
ツールセット | ツール |
|
|
|
|
|
|
|
|
|
|
サーバーは以下のツールを公開しています：
Tool | Description | Example prompt |
| 任意のターゲットURLをスクレイピングし、プロンプトでURLを指定する必要があります。結果はMarkdownで返します。 | 米国IPアドレスからpeacock.comをスクレイピングして、価格を教えてください。 |
| 任意のWebページのスクリーンショットを撮影し、PNG画像として返します。 | 米国IPアドレスからgithub.comのスクリーンショットを撮ってください。 |
| 指定されたクエリでGoogle検索をスクレイピングし、解析結果を返します。 | Google検索でshoesをスクレイピングして、トップの順位を教えてください。 |
| Google広告の検索結果をスクレイピングします。 | Google広告でlaptopをスクレイピングして、上位の広告を表示してください。 |
| Googleレンズの画像検索結果をスクレイピングします。 | この画像でGoogleレンズを検索してください: https://example.com/image.jpg |
| Google AIモード（AI検索）の結果をスクレイピングします。 | Google AIモードに質問: 犬のトップ3の品種は何ですか？ |
| 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にウェブ開発の最新トレンドを尋ねてください。 |
次のパラメータはユーザーのプロンプトから推測されます:
Parameter | Description |
| ターゲットURLをヘッドレスブラウザでレンダリングします。 |
| リクエストの発信元となる国を設定します。 |
| リクエストのロケールを設定します。 |
| レスポンスコンテンツをこの上限まで切り詰めます。コンテキストウィンドウが小さい場合に便利です。 |
| AIツール（ |
| ChatGPTのウェブ検索機能を有効にします（ |
| trueの場合、サポートされている場所（例: |
| リクエストでエミュレートするデバイスタイプ（ |
| リクエストに使用するドメイン（例: |
| ページネーションの開始ページ番号。 |
| 配信先のZIPコード（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/agent-skills は、いつそれらを使うべきか、どのサーフェスを使うべきか、どのように呼び出すかを教えます。これにより、エージェントは推測する代わりに、適切なツールとパラメータを自分で選択します。
スキルはdecodo CLI、このホスト型MCPサーバー、および生のHTTP APIを横断してルーティングされ、シェルが利用できない場合は自動的にMCPサーバーにフォールバックします。この2つを組み合わせることで、エージェントに実行レイヤー（このサーバー）と意思決定レイヤー（スキル）の両方を単一のセットアップで提供します。
クイックスタート（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エージェントに任意のウェブサイトからのリアルタイムデータを提供します。
Start for free | Docs | Discord
すべてのコードはMITライセンスの下で公開されています。
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 |
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.
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) |
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.
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) |
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.
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 |
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.
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) |
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.
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 |
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.
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 |
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.
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 |
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.
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 |
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.
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 |
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.
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 |
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.
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 |
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.
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 |
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.
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) |
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.
Scrape Reddit subreddit results with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to subreddit |
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.
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/) |
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 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 |
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.
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 |
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.
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 |
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.
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 |
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.
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 |
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.
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) |
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.
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 |
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.
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 |
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.
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 |
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.
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 |
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.
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 |
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.
Scrape YouTube video metadata
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | YouTube video ID (e.g., "dFu9aKJoqGg") |
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.
Search YouTube videos
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | YouTube search query (e.g., "How to care for chinchillas") |
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.
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") |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
amazon_bestsellersamazon_pricingamazon_productamazon_searchamazon_sellersbing_searchchatgptgoogle_adsgoogle_ai_modegoogle_lensgoogle_searchgoogle_travel_hotelsperplexityreddit_postreddit_subredditreddit_userscrape_as_markdownscreenshottarget_producttarget_searchtiktok_posttiktok_shop_producttiktok_shop_searchtiktok_shop_urlwalmart_productwalmart_searchyoutube_channelyoutube_metadatayoutube_searchyoutube_subtitlesScored 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.
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.
