Decodo MCP Server
The Decodo MCP Server is a web scraping and data retrieval layer for AI agents, providing real-time access to structured data from websites, search engines, eCommerce platforms, social media, and AI tools — without building custom scraping infrastructure.
Web Scraping
Scrape any website (including JavaScript-heavy pages) as Markdown or capture screenshots as PNG
Handles anti-bot bypass and proxy rotation automatically
Search Engines
Google Search, Google Ads, Google Lens, Google AI Mode, Google Travel Hotels
Bing Search
eCommerce
Amazon: search, product details, pricing, sellers, bestsellers
Walmart: search, product pages (with store ID & delivery ZIP support)
Target: search, product pages (with local inventory support)
TikTok Shop: search, product pages, scrape by URL
Social Media
Reddit: posts, subreddits, user profiles
TikTok: post data including engagement, captions, and hashtags
YouTube: video metadata, channel videos, subtitles, search results
AI Tools
ChatGPT: interact with optional web search
Perplexity: AI-powered responses
Advanced Customization
Geo-targeting (originate requests from specific countries/locations)
JavaScript rendering via headless browser
Device type emulation (desktop, mobile, tablet)
Locale and language configuration
Pagination support
Token limiting for context window management
Modular toolsets: selectively enable
web,search,ecommerce,social_media, oraicategories
Enables scraping and parsing of Amazon Search results for product queries, returning structured data from Amazon's platform.
Enables scraping and parsing of Google Search results for queries, returning structured data including search rankings and results.
Provides web scraping capabilities for Google Maps data through related repository integration.
Enables scraping and parsing of Reddit content including specific posts and subreddit feeds, returning structured data from Reddit's platform.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Decodo MCP Serverscrape Amazon Search for wireless headphones and show me the top 3 results"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Decodo MCP Server
Connect LLMs and AI agents to live web data using MCP (Model Context Protocol). The Decodo MCP Server lets you scrape websites, search engines, eCommerce platforms, and social media directly from AI tools like Claude, Cursor, and Windsurf, all without the need to build scraping infrastructure from scratch.
Structured outputs in JSON, Markdown, and screenshots
Server-side JavaScript rendering and anti-bot handling
125M+ IPs across 195+ locations
What is Decodo MCP server?
The Decodo MCP Server is a web scraping layer for AI agents. It connects MCP-compatible clients to Decodo's Web Scraping API, enabling:
Web scraping for LLMs
Real-time data retrieval for RAG
AI agent browsing and research
Structured data extraction from dynamic websites
Instead of maintaining proxies, parsers, and retry logic, you get a single integration point for reliable web data access.
Related MCP server: FreeCrawl MCP Server
Why use MCP for web scraping?
Model Context Protocol (MCP) is the emerging standard for connecting AI agents to external tools and data sources. With MCP:
Agents can call tools dynamically
Integrations stay standardized
Workflows scale across environments
The Decodo MCP Server gives your agents reliable, production-ready web access through this standard.
Key features
Web scraping for AI agents, no infrastructure required. Scrape any website, including JavaScript-heavy pages, without handling proxy rotation, CAPTCHA solving, or anti-bot systems.
Structured outputs for LLM workflows. Markdown (LLM-ready), JSON (for structured pipelines), and screenshots (for visual context), built for RAG pipelines, AI research agents, and automation flows.
Built-in support for popular targets. Ready-made tools for Google and Bing (SERPs), Amazon, Walmart, and Target (eCommerce), Reddit, TikTok, and YouTube (social media), and ChatGPT and Perplexity (AI search).
Global proxy infrastructure. 125M+ residential IPs, 195+ geo-locations, and a 99.99% success rate on even the most protected targets.
Modular MCP toolsets. Enable only what you need: web, search, ecommerce, social_media,
ai for cleaner tool selection and better agent performance.
Fast time to value. From API key to first scrape in minutes, no setup overhead.
Use cases
Use the Decodo MCP Server when you need web scraping for AI agents, structured data extraction at scale, reliable access to dynamic websites, real-time data for RAG, or an alternative to building scraping infrastructure from scratch. Common scenarios:
AI-powered web scraping – give LLMs the ability to collect fresh data instead of relying on static training data.
RAG with live data – pull real-time Google, Bing, and AI search results into retrieval pipelines.
eCommerce intelligence – track product prices, listings, and sellers across marketplaces without getting blocked.
Social media data collection – gather posts, channels, and engagement data from Reddit, TikTok, and YouTube.
Travel and price aggregation – build tools that collect live pricing and availability across websites.
Quick start
Create a free account at dashboard.decodo.com – up to 2K free requests, no credit card required.
Get your API key. Obtain a Web Scraping API basic authentication token from the dashboard.
Download Node.js 18+ from https://nodejs.org.
Get MCP client like Claude Desktop, Cursor, Windsurf or other MCP-compatible tools.
Configure the MCP server in your AI client (see configuration examples below).
Connecting to Decodo's MCP server
Open your preferred MCP client and add the following configuration (see examples for Claude Code, Cursor, Windsurf bellow):
{
"mcpServers": {
"Decodo": {
"url": "https://mcp.decodo.com/mcp",
"headers": {
"Authorization": "Basic <basic_auth_token>"
}
}
}
}Claude Desktop
Open Claude Desktop → Settings → Developer → Edit Config.
Add to claude_desktop_config.json:
{
"mcpServers": {
"Decodo": {
"command": "npx",
"args": ["-y", "@decodo/mcp-server"],
"env": {
"SCRAPER_API_TOKEN": "<basic_auth_token>",
"TOOLSETS": "web,ai"
}
}
}
}Save and restart Claude Desktop.
Cursor
Open Settings → MCP.
Click Add a new global MCP server (opens mcp.json).
Add the same configuration as above.
Save — look for a green status indicator next to Decodo.
Windsurf
Open Settings → Windsurf Settings.
Scroll to Cascade → Add custom server + (opens mcp_config.json).
Add the same configuration as above.
Save and restart Windsurf.
Test your setup
Once connected, try this prompt in your client:
▎ "Scrape the titles of the top 5 articles from Hacker News"
You should get a structured list back within seconds. If you see an auth error, double-check your token from the dashboard.
Optional: enable specific toolsets
Running the MCP server locally
Prerequisites
Node.js 18.0+
An MCP client - popular choices are Claude Desktop and Cursor
Step-by-step guide
Clone this repository:
git clone https://github.com/Decodo/mcp-serverRun the following commands in the terminal:
cd decodo-mcp-server
npm install
npm run buildTake note of your build location:
cd build/
pwdAdding index.js to the end of this directory, your build file location should look something like
this:
/Users/your.user/projects/decodo-mcp/build/index.jsUpdate your MCP client with the server information:
{
"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
Tools are organized into toolsets. You can selectively enable specific toolsets by passing a
comma-separated list via the toolsets query parameter:
"Decodo MCP Server": {
"url": "https://mcp.decodo.com/mcp?toolsets=web,ai",
"headers": {
"Authorization": "Basic <your_auth_token>"
}
}When no toolsets are specified, all tools are registered.
Toolset | Tools |
|
|
|
|
|
|
|
|
|
|
Tools
The server exposes the following tools:
Tool | Description | Example prompt |
| Scrapes any target URL, expects a URL to be given via prompt. Returns results in Markdown. | Scrape peacock.com from a US IP address and tell me the pricing. |
| Captures a screenshot of any webpage and returns it as a PNG image. | Take a screenshot of github.com from a US IP address. |
| Scrapes Google Search for a given query, and returns parsed results. | Scrape Google Search for shoes and tell me the top position. |
| Scrapes Google Ads search results. | Scrape Google Ads for laptop and show me the top ads. |
| Scrapes Google Lens image search results. | Search Google Lens for this image: https://example.com/image.jpg |
| Scrapes Google AI Mode (Search with AI) results. | Ask Google AI Mode: What are the top three dog breeds? |
| Scrapes Google Travel Hotels search results. | Search Google Travel Hotels for hotels in Paris. |
| Scrapes Amazon Search for a given query, and returns parsed results. | Scrape Amazon Search for wireless keyboard. |
| Scrapes Amazon Product page. | Scrape Amazon product B09H74FXNW and show me the details. |
| Scrapes Amazon Product pricing information. | Get pricing for Amazon product B09H74FXNW. |
| Scrapes Amazon Seller information. | Get information about Amazon seller A1R0Z7FJGTKESH. |
| Scrapes Amazon Bestsellers list. | Show me Amazon bestsellers in electronics. |
| Scrapes Walmart Search for a given query, and returns parsed results. | Scrape Walmart Search for camping tent. |
| Scrapes Walmart Product page. | Scrape Walmart product 15296401808. |
| Scrapes Target Search for a given query, and returns parsed results. | Scrape Target Search for kitchen appliances. |
| Scrapes Target Product page. | Scrape Target product 92186007. |
| Scrapes a TikTok post URL for structured data (e.g. engagement, caption, hashtags). | Scrape this TikTok post: https://www.tiktok.com/@nba/video/7393013274725403950 |
| Scrapes TikTok Shop Search for a given query, and returns parsed results. | Scrape TikTok Shop Search for phone cases. |
| Scrapes TikTok Shop Product page. | Scrape TikTok Shop product 1731541214379741272. |
| Scrapes TikTok Shop page by URL. | Scrape this TikTok Shop URL: https://www.tiktok.com/shop/s?q=HEADPHONES |
| Scrapes YouTube video metadata. | Get metadata for YouTube video dFu9aKJoqGg. |
| Scrapes YouTube channel videos. | Scrape YouTube channel @decodo_official. |
| Scrapes YouTube video subtitles. | Get subtitles for YouTube video L8zSWbQN-v8. |
| Search YouTube videos. | Search YouTube for "How to care for chinchillas". |
| Scrapes a specific Reddit post. | Scrape the following Reddit post: https://www.reddit.com/r/horseracing/comments/1nsrn3/ |
| Scrapes Reddit subreddit results. | Scrape the top 5 posts on r/Python this week. |
| Scrapes a Reddit user profile and their posts/comments. | Scrape this Reddit user: https://www.reddit.com/user/IWasRightOnce/ |
| Scrapes Bing Search results. | Search Bing for laptop reviews. |
| Search and interact with ChatGPT for AI-powered responses and conversations. | Ask ChatGPT to explain quantum computing in simple terms. |
| Search and interact with Perplexity for AI-powered responses and conversations. | Ask Perplexity what the latest trends in web development are. |
Parameters
The following parameters are inferred from user prompts:
Parameter | Description |
| Renders target URL in a headless browser. |
| Sets the country from which the request will originate. |
| Sets the locale of the request. |
| Truncates the response content up to this limit. Useful if the context window is small. |
| Prompt to send to AI tools ( |
| Activates ChatGPT's web search functionality ( |
| When true, includes XHR or fetch responses in the scrape result where supported (e.g. |
| Device type to emulate for the request ( |
| Domain to use for the request (e.g., |
| Starting page number for pagination. |
| ZIP code for delivery location (Target, Walmart). |
| Store ID for local inventory (Target, Walmart). |
| Country for TikTok Shop requests. |
| Maximum number of results to return (e.g., YouTube channel videos). |
| Language code for subtitles (e.g., |
Examples
Scraping geo-restricted content
Query your AI agent with the following prompt:
Scrape peacock.com from a German IP address and tell me the pricing.This prompt will say that peacock.com is geo-restricted. To bypass the geo-restriction:
Scrape peacock.com from a US IP address and tell me the pricing.Limiting number of response tokens
If your agent has a small context window, the content returned from scraping will be automatically truncated, in order to avoid context-overflow. You can increase the number of tokens returned within your prompt:
Scrape hacker news, return 50k tokens.If your agent has a big context window, tell it to return full content:
Scrape hacker news, return full content.Use with Decodo agent skills
This server gives your agent the scraping tools. Decodo/agent-skills
teaches it when to reach for them, which surface to use, and how to call it — so the agent
picks the right tool and parameters on its own instead of guessing.
The skills route across the decodo CLI, this hosted MCP server, and the raw HTTP API, and fall back
to the MCP server automatically when no shell is available. Pairing the two gives your agent both the
execution layer (this server) and the decision layer (the skills) in a single setup.
Quick start (Claude Code):
/plugin marketplace add Decodo/agent-skills
/plugin install decodo@decodo-skillsSee the agent-skills README for manual install and other agents (Cursor, Codex, Gemini CLI, Windsurf).
Related repositories
Web Scraping API, Decodo agent skills, Decodo OpenClaw skill
Try it
Plug Decodo MCP Server into your AI workflow in just a few clicks and equip your AI agents with real-time data from any website.
Start for free | Docs | Discord
License
All code is released under the MIT License.
Available Tools
30 toolsamazon_bestsellersBRead-only
Scrape Amazon Bestsellers list with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Amazon category (e.g., "mobile-apps", "electronics") | |
| domain | No | Amazon domain (e.g., amazon.com, amazon.co.uk) | |
| deviceType | No | Device type to emulate for the request | |
| pageFrom | No | Starting page number for pagination |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and openWorldHint=true, but the description adds minimal behavioral details beyond 'automatic parsing.' It does not explain parsing behavior, rate limits, or pagination mechanics, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the core action, but it could include more detail without becoming lengthy. It is front-loaded but slightly too terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a scraping tool with four parameters and no output schema, the description is insufficient. It does not describe return values, pagination behavior, or potential issues, making it hard for an agent to anticipate outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters have descriptions in the schema (100% coverage). The description does not add any extra meaning or clarify parameter usage beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Scrape Amazon Bestsellers list') and resource, and it is distinct from sibling tools like amazon_search or amazon_product, which focus on different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as amazon_search or amazon_product. The description omits context about suitable scenarios or when to avoid using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
amazon_pricingCRead-only
Scrape Amazon Product pricing information with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Amazon product ASIN (e.g., "B09H74FXNW") | |
| jsRender | No | Should the request be opened in a headless browser, false by default | |
| domain | No | Amazon domain (e.g., amazon.com, amazon.co.uk) | |
| deviceType | No | Device type to emulate for the request | |
| pageFrom | No | Starting page number for pagination | |
| geo | No | Amazon geo location (e.g., 10001 for US ZIP code) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, which cover the read-only and dynamic nature. The description adds no additional behavioral context such as rate limits, error handling, or parsing specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is efficient and contains no extraneous information, making it easy to read and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has six parameters, no output schema, and numerous sibling tools, the description is too minimal. It does not explain the output format, pagination behavior (despite pageFrom parameter), or how automatic parsing works, leaving the agent to infer crucial details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all six parameters thoroughly. The description adds no extra meaning beyond what is in the schema, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scrapes Amazon Product pricing information with automatic parsing, which distinguishes it from siblings like amazon_product (full product details) and amazon_search (general search). However, it does not explicitly contrast with these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other Amazon-related tools like amazon_product or amazon_search, nor are there any exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
amazon_productARead-only
Scrape Amazon Product page with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Amazon product ASIN (e.g., "B09H74FXNW") | |
| jsRender | No | Should the request be opened in a headless browser, false by default | |
| domain | No | Amazon domain (e.g., amazon.com, amazon.co.uk) | |
| deviceType | No | Device type to emulate for the request | |
| geo | No | Amazon geo location (e.g., 10001 for US ZIP code) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds 'automatic parsing' which hints at structured output, but doesn't disclose potential issues like invalid ASIN handling, rate limits, or that it fetches live data from Amazon.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the key action and resource. However, it could include one more detail about output without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should compensate by explaining what the tool returns (e.g., parsed product data fields). It does not. Also, no mention of error handling or query format validation, making it incomplete for a scraping tool with 5 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description does not add new meaning beyond the schema; it only restates the overall purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'scrape' and the resource 'Amazon Product page', with added context 'automatic parsing'. It distinguishes from sibling tools like amazon_search (lists) and amazon_pricing (prices).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. The context of siblings suggests usage (single product vs. search), but no explicit when-to-use or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
amazon_searchBRead-only
Scrape Amazon Search results with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for Amazon products (e.g., "wireless keyboard") | |
| geo | No | Geolocation of the desired request, expressed as a country name | |
| jsRender | No | Should the request be opened in a headless browser, false by default | |
| domain | No | Amazon domain (e.g., amazon.com, amazon.co.uk) | |
| deviceType | No | Device type to emulate for the request | |
| pageFrom | No | Starting page number for pagination |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and openWorldHint, but the description adds minimal behavioral context. It mentions 'automatic parsing' but does not explain what that entails, rate limits, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundancy, front-loading the core action. Every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no output schema, the description is too brief. It does not explain output format, pagination behavior, or how 'automatic parsing' works, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 6 parameters are fully described in the input schema (100% coverage). The description adds no extra semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'scrape' and the resource 'Amazon Search results', with 'automatic parsing' adding specificity. It distinguishes from sibling tools like amazon_product and amazon_bestsellers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives (e.g., amazon_bestsellers, amazon_product). No mention of prerequisites or scenarios where other tools are preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
amazon_sellersBRead-only
Scrape Amazon Seller information with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Amazon seller ID (e.g., "A1R0Z7FJGTKESH") | |
| jsRender | No | Should the request be opened in a headless browser, false by default | |
| domain | No | Amazon domain (e.g., amazon.com, amazon.co.uk) | |
| deviceType | No | Device type to emulate for the request | |
| geo | No | Amazon geo location (e.g., 10001 for US ZIP code) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and openWorldHint, but the description adds no additional behavioral details (e.g., error handling, data freshness, or limits). It merely restates the scraping intent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It front-loads the key action and resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no output schema), the description is too sparse. It lacks information about return format, error conditions, or usage nuances, leaving gaps despite helpful annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no extra meaning beyond what's in the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Scrape Amazon Seller information with automatic parsing', using a specific verb and resource. It distinguishes from sibling tools like amazon_product or amazon_search, which target different data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any mention of prerequisites or exclusions. With many sibling tools, explicit usage context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bing_searchBRead-only
Scrape Bing Search results with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for Bing (e.g., "laptop") | |
| geo | No | Geolocation of the desired request, expressed as a country name | |
| locale | No | Locale of the desired request | |
| jsRender | No | Should the request be opened in a headless browser, false by default | |
| domain | No | Bing domain (e.g., bing.com, bing.co.uk) | |
| deviceType | No | Device type to emulate for the request | |
| pageFrom | No | Starting page number for pagination |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=true. The description adds 'automatic parsing' but no further behavioral details like rate limits, anti-scraping risks, or result structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with no excess words. The most important information (verb, resource, key feature) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters (including pagination, device type, geo, locale) and no output schema, the description is too minimal. It does not explain how parameters affect results, return format, or pagination behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 7 parameters have descriptions in the schema (100% coverage). The tool description does not add meaning beyond what the schema already provides, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the specific verb 'Scrape', resource 'Bing Search results', and 'automatic parsing'. It distinguishes from sibling tools like google_search by naming Bing explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use Bing over other search tools (e.g., google_search, amazon_search). No mention of scenarios, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
chatgptBRead-only
Search and interact with ChatGPT for AI-powered responses and conversations
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Prompt to send to ChatGPT | |
| search | No | Activates ChatGPT's web search functionality | |
| geo | No | Geolocation of the desired request, expressed as a country name |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint, which indicate the tool is read-only and may return dynamic results. The description adds no additional behavioral context beyond 'interact', which could be misinterpreted as modifying state but does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and to the point. However, it could be more front-loaded with the core function (querying ChatGPT) rather than 'search and interact'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description does not detail what the tool returns (e.g., format, type of response). Given the openWorldHint, more context about possible outputs would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so the schema already explains each parameter. The description does not add any extra meaning or usage tips for the prompt, search, or geo parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for interacting with ChatGPT to get AI-powered responses. However, it does not differentiate from siblings like 'perplexity' or other search tools, which also offer AI responses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as google_search or perplexity. There are no explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
google_adsBRead-only
Scrape Google Ads search results with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for Google Ads (e.g., "laptop") | |
| geo | No | Geolocation of the desired request, expressed as a country name | |
| locale | No | Locale of the desired request | |
| jsRender | No | Should the request be opened in a headless browser, false by default | |
| deviceType | No | Device type to emulate for the request | |
| pageFrom | No | Starting page number for pagination |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds 'with automatic parsing', indicating structured output. No contradictions, but no additional behavioral details (e.g., pagination, rate limits).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the core function but does not specify return format or pagination behavior, despite having no output schema. With openWorldHint, results are dynamic; some elaboration on what 'automatic parsing' yields would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 6 parameters. The description adds no further meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Scrape' and the resource 'Google Ads search results', and distinguishes from siblings like google_search by adding 'with automatic parsing'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., google_search for organic results). It only states what it does, without any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
google_ai_modeARead-only
Scrape Google AI Mode (Search with AI) results with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for Google AI Mode (e.g., "What are the top three dog breeds?") | |
| geo | No | Geo location for AI mode search (e.g., "us", "uk") | |
| deviceType | No | Device type to emulate for the request |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and openWorld. Description adds 'automatic parsing' but no further behavioral traits like rate limits or output structure. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key action, no redundant words. Extremely concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with 1 required param and annotations present. Description covers core purpose and parsing feature. Lacks output format info, but acceptable given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds no parameter-level meaning beyond schema. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Describes verb 'scrape' and resource 'Google AI Mode results', with added detail 'automatic parsing'. Clear differentiation from sibling google_search tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like google_search. Lacks context for appropriate use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
google_lensARead-only
Scrape Google Lens image search results with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Image URL for Google Lens search (e.g., "https://example.com/image.jpg") | |
| jsRender | No | Should the request be opened in a headless browser, false by default | |
| deviceType | No | Device type to emulate for the request |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds 'automatic parsing' implying structured output but does not detail behavioral traits like rate limits, auth requirements, or error handling. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core purpose without extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and high schema coverage, the description is adequate but does not address output format, limitations, or tips. It leaves some gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already documented. The tool description adds no additional meaning or context beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (scrape), the target resource (Google Lens image search results), and adds a specific qualifier (automatic parsing). It distinguishes itself from sibling tools like google_search and other image tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives like google_search or other scraping tools. The description does not specify context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
google_searchARead-only
Scrape Google Search results with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| geo | No | Geolocation of the desired request, expressed as a country name | |
| locale | No | Locale of the desired request | |
| jsRender | No | Should the request be opened in a headless browser, false by default |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true and openWorldHint=true, indicating safe read operation. Description adds 'automatic parsing' but no further behavioral details. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy, fully front-loaded with essential purpose. Every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description hints at parsed results. For a simple scraper with good annotations, it is adequate but lacks explicit return format details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add any parameter-level explanation beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Scrape Google Search results', using a specific verb and resource. It distinguishes from siblings like bing_search or google_ads by explicitly naming Google Search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives (e.g., bing_search, google_ads). The description does not provide context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
google_travel_hotelsBRead-only
Scrape Google Travel Hotels search results
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Hotel search query (e.g., "trivago", "hotels in Paris") | |
| jsRender | No | Should the request be opened in a headless browser, false by default | |
| locale | No | Locale of the desired request | |
| deviceType | No | Device type to emulate for the request | |
| pageFrom | No | Starting page number for pagination |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and variability. The description adds no further behavioral context (e.g., pagination, headless browser usage, rate limits) but does not contradict the annotations. Given annotation coverage, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, demonstrating high conciseness. However, it is so brief that it sacrifices informativeness; still, it is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and multiple siblings, a single-sentence description is insufficient. It fails to explain return format, pagination, or the effect of optional parameters like jsRender, locale, and deviceType, leaving significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 5 parameters have descriptions in the input schema, achieving 100% schema description coverage. The tool description adds no new meaning beyond the schema, so the baseline score of 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Scrape Google Travel Hotels search results' clearly identifies the tool's action (scrape) and resource (Google Travel Hotels search results). It distinguishes it from sibling tools like google_search (general web search) by specifying 'Travel Hotels', but could be more explicit about its unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as google_search or other travel-related tools. There is no mention of context, prerequisites, or when not to use it, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
perplexityBRead-only
Search and interact with Perplexity for AI-powered responses and conversations
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Prompt to send to Perplexity | |
| geo | No | Geolocation of the desired request, expressed as a country name |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating safe, nondeterministic behavior. The description adds 'AI-powered responses and conversations' but does not elaborate on other traits like rate limits or output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but could be slightly improved by removing redundancy ('responses and conversations') and adding sibling differentiation without increasing length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of annotations and full schema coverage, the description lacks contextual cues for an agent to distinguish it from similar AI tools, especially without output schema details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description does not add additional meaning beyond the schema, such as how to format the prompt or when geo is useful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (Perplexity) and action (search and interact), but it does not differentiate from sibling tools like chatgpt or google_ai_mode, which also provide AI-powered responses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use Perplexity versus alternatives, such as when AI-powered search is preferred over traditional search (bing_search, google_search) or other AI chatbots (chatgpt).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reddit_postARead-only
Scrape a specific Reddit post
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | reddit post URL (eg. https://www.reddit.com/r/hometheater/comments/1jz9xk5/lg_ubk90_only_works_when_plugged_into_tv_via) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile and open-ended return are covered. The description adds no behavioral context beyond 'Scrape', which is acceptable but not additive given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence with no extraneous text. Every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is largely sufficient. It could optionally hint at the type of data returned (e.g., title, content) but openWorldHint implies variety, so 4 is reasonable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for the 'url' parameter, including an example. The description does not add further meaning or format details, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Scrape a specific Reddit post' uses a clear verb ('scrape') and specifies the exact resource ('specific Reddit post'). It distinguishes from sibling tools like 'reddit_subreddit' and 'reddit_user', which target different Reddit entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'reddit_subreddit' or 'reddit_user'. The description lacks context for preferred usage or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reddit_subredditBRead-only
Scrape Reddit subreddit results with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to subreddit |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint (true) and openWorldHint (true), covering safety and openness. The description adds 'with automatic parsing' but provides no additional behavioral details (e.g., rate limits, data freshness, or what parsing entails).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence that is efficient and front-loaded. However, it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description does not hint at what the tool returns (e.g., list of posts, post details). For a scraping tool, this omission is significant. Annotations help but do not fulfill the need for expected output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (parameter 'url' documented). The tool description adds 'subreddit results' context but does not enrich the parameter meaning beyond the schema's 'URL to subreddit'. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Scrape Reddit subreddit results' with a specific verb and resource. It distinguishes from siblings like 'reddit_post' (single post) and 'reddit_user', making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., reddit_post, reddit_search). The description does not provide context for selecting this tool among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reddit_userARead-only
Scrape a Reddit user profile and their posts/comments
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Reddit user profile URL (eg. https://www.reddit.com/user/IWasRightOnce/) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds context by specifying that it scrapes profile and posts/comments, providing valuable behavioral detail beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the tool's purpose without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter schema, no output schema, and annotations covering safety, the description sufficiently informs the agent. However, it could detail what data is returned (e.g., list of posts vs full content).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for the single parameter 'url'. The description does not add additional parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'scrape' and resource 'Reddit user profile and their posts/comments', clearly distinguishing it from siblings like reddit_post and reddit_subreddit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives guidance is given. The description implies scraping user data but lacks direction compared to sibling tools that target specific content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scrape_as_markdownBRead-only
Scrape the contents of a website and return Markdown-formatted results
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to scrape | |
| geo | No | Geolocation of the desired request, expressed as a country name | |
| locale | No | Locale of the desired request | |
| jsRender | No | Should the request be opened in a headless browser, false by default | |
| tokenLimit | No | The number of tokens to return in the response - anything above this limit will be truncated |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds no behavioral info beyond the purpose. It does not mention truncation via tokenLimit, potential rate limits, or any side effects. The description is adequate but not enhanced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the main purpose. It is concise but arguably too brief; could include more detail without losing conciseness. Still, it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters but no output schema. The description only mentions 'Markdown-formatted results' without details on structure, errors, or truncation behavior. For a web scraper used by an AI agent, more completeness would be beneficial. The annotations help but the description is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for all 5 parameters, so the schema itself explains each parameter. The description does not add further meaning or usage context for the parameters. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (scrape) and resource (website contents) and output format (Markdown). It distinguishes from siblings like google_search or amazon_product by being a general-purpose web scraper. However, it could be more specific about the scope of content scraped (e.g., full page vs text).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like the specialized scrapers (e.g., amazon_bestsellers, target_product). An agent would not know if this tool is appropriate for a given site or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
screenshotARead-only
Capture a screenshot of any webpage and return it as a PNG image
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to screenshot | |
| geo | No | Geolocation of the desired request, expressed as a country name |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint (safe read) and openWorldHint (may fetch external content). The description confirms it captures screenshots from any webpage, which is consistent. However, it does not disclose potential issues like website blocking, timeouts, or output encoding (e.g., base64 vs binary).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no unnecessary words. Front-loaded with the key action and output format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a simple screenshot tool but lacks details about return format (e.g., whether PNG is returned as base64 or binary blob). No output schema exists to compensate. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with brief descriptions. The tool description adds no additional meaning beyond what the schema provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Capture a screenshot'), the resource ('any webpage'), and the output format ('PNG image'). It distinguishes from sibling tools which are primarily search or text extraction tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives like scrape_as_markdown or google_lens. The description does not mention limitations or contexts where screenshot might be inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
target_productBRead-only
Scrape Target Product page with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | Target product ID (e.g., "1003921355") | |
| jsRender | No | Should the request be opened in a headless browser, false by default | |
| deviceType | No | Device type to emulate for the request | |
| deliveryZip | No | ZIP code for delivery location | |
| storeId | No | Target store ID for local inventory |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true, so the description's addition of 'automatic parsing' adds minimal behavioral context. No contradiction, but no elaboration on scraping behavior (e.g., rate limits, page structure).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded. No unnecessary words; every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters and no output schema, the description is too minimal. It does not explain what data is returned (e.g., price, title) or how 'automatic parsing' works, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description does not repeat or add value beyond that; baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Scrape Target Product page with automatic parsing' clearly states the tool's function (scraping a specific product page) and distinguishes it from siblings like target_search (which searches) and other product scraping tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., target_search for multiple products). The description does not mention prerequisites or context like requiring a valid product_id, which is only evident from the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
target_searchBRead-only
Scrape Target Search results with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for Target products | |
| jsRender | No | Should the request be opened in a headless browser, false by default | |
| deviceType | No | Device type to emulate for the request | |
| deliveryZip | No | ZIP code for delivery location | |
| storeId | No | Target store ID for local inventory |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint, so the description adds limited behavioral context. 'Automatic parsing' hints at structured output, but details like data freshness, rate limits, or result format are absent. Adequate given annotations but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that delivers the core purpose without wasted words. It is efficient but could benefit from additional context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and 5 parameters, the description does not elaborate on return values, pagination, or error handling. Siblings are similar, but the description lacks completeness for an agent to understand expected results fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for all 5 parameters. The description adds no new semantic detail beyond what the schema provides, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scrapes Target search results with automatic parsing, specifying both the action (scrape) and the resource (Target search results). This distinguishes it from sibling tools like 'target_product' which focus on specific products, and from other retailer search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'amazon_search' or 'walmart_search'. There is no mention of scenarios where this tool is preferred or any conditions to avoid using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_postARead-only
Scrape a TikTok post URL for structured data such as engagement, captions, and hashtags
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | TikTok post URL, e.g. https://www.tiktok.com/@user/video/1234567890 | |
| xhr | No | When true, includes XHR/fetch responses in the scrape result where supported by the target |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds that the tool extracts structured data (engagement, captions, hashtags), but does not disclose additional behavioral traits like error handling, rate limits, or response format. It is consistent with annotations, adding modest context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the purpose. No redundant or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple scrape tool with two parameters and annotations, the description is adequate but incomplete. It does not explain the output structure or error conditions, though annotations partially compensate. An output schema would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters well-described. The description does not add meaning beyond the schema, such as clarifying the 'xhr' parameter's effect. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'scrape' and the resource 'TikTok post URL', and lists specific data types (engagement, captions, hashtags). It distinguishes the tool from siblings like tiktok_shop_product by targeting post URLs specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., tiktok_shop_product for shop data). It lacks explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_shop_productARead-only
Scrape TikTok Shop Product page
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | TikTok Shop product ID (e.g., "1731541214379741272") | |
| jsRender | No | Should the request be opened in a headless browser, false by default | |
| deviceType | No | Device type to emulate for the request | |
| country | No | Country code for the request (e.g., US, GB, DE) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, openWorldHint=true) already indicate a safe read operation. The description adds no further behavioral details beyond 'scrape', which is consistent. No additional context like rate limits or data format is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and front-loaded. Every word serves a purpose, but could be expanded with minimal additional context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters and no output schema, the description should ideally mention what data is returned or any significant constraints. It lacks such details, making it incomplete for a scraping tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all four parameters. The description does not add any additional meaning or nuance beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Scrape TikTok Shop Product page' uses a specific verb and resource, clearly indicating the tool's function. It is distinguishable from sibling tools like tiktok_shop_search and tiktok_post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (scraping product details) but provides no explicit guidance on when to use this tool versus alternatives or any exclusions. The context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_shop_searchARead-only
Scrape TikTok Shop Search results with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for TikTok Shop products | |
| geo | No | Geolocation of the desired request, expressed as a country name | |
| jsRender | No | Should the request be opened in a headless browser, false by default | |
| country | No | Country code for the request (e.g., US, GB, DE) | |
| deviceType | No | Device type to emulate for the request |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world behavior. 'Scrape' and 'automatic parsing' add minimal extra context but do not cover rate limits, result formatting, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that is front-loaded with the action and resource, containing no superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 5 parameters and no output schema, the description lacks details on result format, pagination, or usage constraints, making it minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so the description adds no additional meaning to the parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (scrape) and resource (TikTok Shop Search results) and differentiates from sibling tools like tiktok_shop_product and tiktok_shop_url.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as other search tools or product-specific TikTok Shop tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_shop_urlBRead-only
Scrape TikTok Shop page by URL
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | TikTok Shop URL (e.g., "https://www.tiktok.com/shop/s?q=HEADPHONES") | |
| jsRender | No | Should the request be opened in a headless browser, false by default |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already confirm readOnlyHint and openWorldHint, so the description adds minimal behavioral context. It does not disclose what 'scrape' entails (e.g., rate limits, data format, or side effects), but annotations cover the safety profile adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no filler. Every word is informative and structurally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 params, no output schema), the description omits important details like return format or how jsRender affects scraping. It is insufficient for an agent to fully understand tool behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already explains both parameters. The description adds no additional parameter-level information beyond what is in the schema, hence baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Scrape TikTok Shop page by URL' clearly states the action (scrape) and resource (TikTok Shop page). However, it does not differentiate between related sibling tools like tiktok_shop_product or tiktok_shop_search, which may cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The sibling tools exist but are not mentioned, and there is no discussion of prerequisites or usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
walmart_productARead-only
Scrape Walmart Product page with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | Walmart product ID (e.g., "15296401808") | |
| jsRender | No | Should the request be opened in a headless browser, false by default | |
| deliveryZip | No | ZIP code for delivery location | |
| storeId | No | Walmart store ID for local inventory |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a read-only operation (readOnlyHint=true) and potential open-world effects (openWorldHint=true). The description adds 'automatic parsing' but omits other behavioral traits such as rate limits, authentication needs, or error handling. With annotations present, the description adds some value but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one sentence that front-loads the core action and resource. It contains no fluff or repetition, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema and annotations cover basic details, the lack of an output schema places burden on the description. 'Automatic parsing' is vague about the return format. For a scraping tool, more context about what data is extracted or error conditions would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description does not add meaning beyond the schema; 'automatic parsing' hints at output format but not parameter-specific details. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Scrape'), the resource ('Walmart Product page'), and adds 'with automatic parsing' hinting at structured output. It effectively distinguishes from sibling tools like walmart_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for scraping a single product page but provides no explicit when-to-use or when-not-to-use guidance. No alternatives or exclusions are mentioned, leaving the agent to infer context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
walmart_searchBRead-only
Scrape Walmart Search results with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for Walmart products (e.g., "camping tent") | |
| jsRender | No | Should the request be opened in a headless browser, false by default | |
| deviceType | No | Device type to emulate for the request | |
| deliveryZip | No | ZIP code for delivery location | |
| storeId | No | Walmart store ID for local inventory |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds 'automatic parsing' but does not elaborate on behavior (e.g., result structure, pagination, rate limits). With annotations covering safety, the description provides minimal additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy, efficiently conveys the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description omits details about return values (e.g., fields returned, format, pagination). For a tool with 5 parameters and no output schema, the description is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters. The tool description does not add further meaning beyond what the schema provides, thus baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'Scrape' and the resource 'Walmart Search results' with 'automatic parsing', clearly distinguishing it from sibling tools like walmart_product (product details) and other search tools (amazon_search, target_search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., walmart_product, target_search) or when not to use it. The description lacks any context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
youtube_channelBRead-only
Scrape YouTube channel videos with automatic parsing
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | YouTube channel handle or ID (e.g., "@decodo_official") | |
| limit | No | Maximum number of videos to return |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral details beyond annotations (readOnlyHint, openWorldHint). It does not disclose rate limits, pagination, or output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words, but could provide more context without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a scraping tool with no output schema, the description is too minimal. Missing details on results, pagination, or parsing behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions; the description adds no extra meaning, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scrapes YouTube channel videos with automatic parsing, distinguishing it from siblings like youtube_metadata, youtube_search, and youtube_subtitles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like youtube_search or youtube_metadata. Missing context for optimal usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
youtube_metadataBRead-only
Scrape YouTube video metadata
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | YouTube video ID (e.g., "dFu9aKJoqGg") |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations readOnlyHint and openWorldHint indicate safe, read-only operation. The description adds minimal behavioral context beyond confirming read-only scraping. No mention of rate limits, authentication, error handling, or return types.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise, but it is a phrase rather than a full sentence. Could be improved with a more structured description like 'Retrieves metadata for a YouTube video given its ID.' Still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is present, and the description does not specify what metadata fields are returned (e.g., title, views, likes). Given the tool's simplicity and lack of output schema, the description is incomplete for an agent to determine usefulness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters and describes the single required 'query' parameter as a YouTube video ID with an example. The description adds no further meaning, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool scrapes YouTube video metadata, which is a specific verb+resource. However, it doesn't detail what metadata fields are included, leaving some ambiguity. It is clearly distinct from siblings like youtube_search or youtube_subtitles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No indication of when to use this tool versus alternatives such as youtube_search or youtube_channel. No explicit usage context, prerequisites, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
youtube_searchBRead-only
Search YouTube videos
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | YouTube search query (e.g., "How to care for chinchillas") |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and openWorldHint=true, implying the tool is safe and results may vary. The description does not add behavioral details beyond annotations, but there is no contradiction. It meets the minimum added value for a tool with such annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that directly states the tool's purpose. It is front-loaded and contains no unnecessary words, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the tool returns (e.g., list of video IDs, titles). It only states the action, leaving agents to infer the output format. Basic contextual information is missing, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter 'query' with a clear description and example. The description adds no further semantic value beyond the schema, but the schema coverage is 100%, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search') and resource ('YouTube videos'), making the purpose unambiguous. While the name itself conveys the tool's domain, the description does not differentiate it from sibling search tools like 'google_search' or 'bing_search', but the resource specificity is sufficient.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., 'google_search' for general web search, 'youtube_metadata' for specific video details). The description lacks explicit context for choosing this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
youtube_subtitlesBRead-only
Scrape YouTube video subtitles
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | YouTube video ID (e.g., "L8zSWbQN-v8") | |
| language_code | No | Language code for subtitles (e.g., "en", "es") |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint, but the description adds no further behavioral context (e.g., rate limits, required format for video ID).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no unnecessary words, effectively communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and schema coverage, the description is adequate but lacks mention of return format (no output schema) and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions, so the description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description 'Scrape YouTube video subtitles' clearly states the verb and resource, distinguishing it from siblings like youtube_metadata and youtube_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as youtube_search or youtube_metadata, nor any conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Tools are mostly distinct by platform and data type, but some overlap exists within Google (search, ads, AI mode, Lens) and between AI chat tools (chatgpt, perplexity). Descriptions help differentiate.
Naming follows a consistent 'platform_what' pattern for most tools, but a few outliers like 'scrape_as_markdown', 'screenshot', 'chatgpt', and 'perplexity' break the pattern.
30 tools is at the high end of reasonable. The server covers many scraping targets, but could be split into per-platform servers. Not excessive, but bordering on heavy.
Covers major platforms (Amazon, Google, Reddit, TikTok, Walmart, YouTube) but missing others (Facebook, Twitter, Instagram) and some common scraping operations (reviews, comments, posts). Decent but not exhaustive.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Crawl, scrape, search the web, and automate browsers at scale with anti-bot bypass.
ScrapeUnblocker: ScrapeUnblocker allows to bypass anti-bot services and scrape the full page source.
The most accurate web access API. Stop getting blocked.
Hundreds of scraping & data APIs through one key. USD pay-per-request, normalized schemas, failover.
Related MCP Servers
- AlicenseBqualityDmaintenanceAnthropic's github MCP server, but better. Support for more endpoints. Including releases and tags, pull request reviews, statuses, rate limit, gists, projects, packages, and even pull request diffs. Indented to be used with MissionSquad's MCP API for secret management (aka your access token).4586110MIT
- AlicenseNot gradedqualityDmaintenanceEnables web scraping and document processing with JavaScript execution, anti-detection measures, batch processing, and structured data extraction. Supports multiple formats including markdown, HTML, screenshots, and handles PDFs with OCR capabilities.4MIT
- AlicenseAqualityBmaintenanceEnables AI agents to scrape any website by providing tools for JavaScript rendering, antibot bypass, and automatic captcha solving. It supports synchronous, asynchronous, and batch scraping operations with built-in proxy rotation.5207MIT
- AlicenseAqualityAmaintenanceEnables web scraping, structured data extraction, and screenshot capture with automatic anti-bot bypass, supporting JavaScript rendering, proxy rotation, and tiered pricing.252181MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Decodo/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server