Skip to main content
Glama
cortex8

DataForSEO MCP Server

by cortex8
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

DataForSEO MCP Server

Model Context Protocol (MCP) server implementation for DataForSEO, enabling AI assistants to interact with selected DataForSEO APIs and obtain SEO data through a standardized interface.

Features

  • AI_OPTIMIZATION API: provides data for keyword discovery, conversational optimization, and real-time LLM benchmarking;

  • SERP API: real-time Search Engine Results Page (SERP) data for Google, Bing, and Yahoo;

  • KEYWORDS_DATA API: keyword research and clickstream data, including search volume, cost-per-click, and other metrics;

  • ONPAGE API: allows crawling websites and webpages according to customizable parameters to obtain on-page SEO performance metrics;

  • DATAFORSEO LABS API: data on keywords, SERPs, and domains based on DataForSEO's in-house databases and proprietary algorithms;

  • BACKLINKS API: comprehensive backlink analysis including referring domains, anchor text distribution, and link quality metrics;

  • BUSINESS DATA API: publicly available data on any business entity;

  • DOMAIN ANALYTICS API: data on website traffic, technologies, and Whois details;

  • CONTENT ANALYSIS API: robust source of data for brand monitoring, sentiment analysis, and citation management;

Prerequisites

  • Node.js (v14 or higher)

  • DataForSEO API credentials (API login and password)

Installation

  1. Clone the repository:

git clone https://github.com/dataforseo/mcp-server-typescript
cd mcp-server-typescript

  1. Install dependencies:

npm install

  1. Set up environment variables:

# Required
export DATAFORSEO_USERNAME=your_username
export DATAFORSEO_PASSWORD=your_password

# Optional: specify which modules to enable (comma-separated)
# If not set, all modules will be enabled
export ENABLED_MODULES="SERP,KEYWORDS_DATA,ONPAGE,DATAFORSEO_LABS,BACKLINKS,BUSINESS_DATA,DOMAIN_ANALYTICS"

# Optional: specify which prompts in enabled modules are enable too (prompts names, comma-separated)
# If not set, all prompts from enabled modules will be enabled
export ENABLED_PROMPTS="top_3_google_result_domains,top_5_serp_paid_and_organic"

# Optional: enable full API responses
# If not set or set to false, the server will filter and transform API responses to a more concise format
# If set to true, the server will return the full, unmodified API responses
export DATAFORSEO_FULL_RESPONSE="false"

# Optional: enable simple filter schema
# If set to true, a simplified version of the filters schema will be used.
# This is required for ChatGPT APIs or other LLMs that cannot handle nested structures.
export DATAFORSEO_SIMPLE_FILTER="false"

Installation as an NPM Package

You can install the package globally:

npm install -g dataforseo-mcp-server

Or run it directly without installation:

npx dataforseo-mcp-server

Remember to set environment variables before running the command:

# Required environment variables
export DATAFORSEO_USERNAME=your_username
export DATAFORSEO_PASSWORD=your_password

# Run with npx
npx dataforseo-mcp-server

Building and Running

Build the project:

npm run build

Run the server:

# Start local server (direct MCP communication)
npx dataforseo-mcp-server

# Start HTTP server
npx dataforseo-mcp-server http

HTTP Server Configuration

The server runs on port 3000 by default and supports both Basic Authentication and environment variable-based authentication.

To start the HTTP server, run:

npm run http

Authentication Methods

  1. Basic Authentication

    • Send requests with Basic Auth header:

    Authorization: Basic <base64-encoded-credentials>

    • Credentials format: username:password

  2. Environment Variables

    • If no Basic Auth is provided, the server will use credentials from environment variables:

    export DATAFORSEO_USERNAME=your_username
export DATAFORSEO_PASSWORD=your_password
# Optional
export DATAFORSEO_SIMPLE_FILTER="false"
export DATAFORSEO_FULL_RESPONSE="true"

Cloudflare Worker Deployment

The DataForSEO MCP Server can be deployed as a Cloudflare Worker for serverless, edge-distributed access to DataForSEO APIs.

Worker Features

  • Edge Distribution: Deploy globally across Cloudflare's edge network

  • Serverless: No server management required

  • Auto-scaling: Handles traffic spikes automatically

  • MCP Protocol Support: Compatible with both Streamable HTTP and SSE transports

  • Environment Variables: Secure credential management through Cloudflare dashboard

Quick Start

  1. Install Wrangler CLI:

    npm install -g wrangler

  2. Configure Worker:

    # Login to Cloudflare
wrangler login

# Set environment variables
wrangler secret put DATAFORSEO_USERNAME
wrangler secret put DATAFORSEO_PASSWORD

  3. Deploy Worker:

    # Build and deploy
npm run build
wrangler deploy --main build/index-worker.js

Configuration

The worker uses the same environment variables as the standard server:

  • DATAFORSEO_USERNAME: Your DataForSEO username

  • DATAFORSEO_PASSWORD: Your DataForSEO password

  • ENABLED_MODULES: Comma-separated list of modules to enable

  • ENABLED_PROMPTS: Comma-separated list of prompt names to enable

  • DATAFORSEO_FULL_RESPONSE: Set to "true" for full API responses

Worker Endpoints

Once deployed, your worker will be available at https://your-worker.your-subdomain.workers.dev/ with the following endpoints:

  • POST /mcp: Streamable HTTP transport (recommended)

  • GET /sse: SSE connection establishment (deprecated)

  • POST /messages: SSE message handling (deprecated)

  • GET /health: Health check endpoint

  • GET /: API documentation page

Advanced Configuration

Edit wrangler.jsonc to customize your deployment:

{
  "name": "dataforseo-mcp-worker",
  "main": "build/index-worker.js",
  "compatibility_date": "2025-07-10",
  "compatibility_flags": ["nodejs_compat"],
  "vars": {
    "ENABLED_MODULES": "SERP,KEYWORDS_DATA,ONPAGE,DATAFORSEO_LABS",
    "ENABLED_PROMPTS":"top_3_google_result_domains,top_5_serp_paid_and_organic"
  }
}

Usage with Claude

After deployment, configure Claude to use your worker:

{
  "name": "DataForSEO",
  "description": "Access DataForSEO APIs via Cloudflare Worker",
  "transport": {
    "type": "http",
    "baseUrl": "https://your-worker.your-subdomain.workers.dev/mcp"
  }
}

Available Modules

The following modules are available to be enabled/disabled:

  • AI_OPTIMIZATION: provides data for keyword discovery, conversational optimization, and real-time LLM benchmarking;

  • SERP: real-time SERP data for Google, Bing, and Yahoo;

  • KEYWORDS_DATA: keyword research and clickstream data;

  • ONPAGE: crawl websites and webpages to obtain on-page SEO performance metrics;

  • DATAFORSEO_LABS: data on keywords, SERPs, and domains based on DataForSEO's databases and algorithms;

  • BACKLINKS: data on inbound links, referring domains and referring pages for any domain, subdomain, or webpage;

  • BUSINESS_DATA: based on business reviews and business information publicly shared on the following platforms: Google, Trustpilot, Tripadvisor;

  • DOMAIN_ANALYTICS: helps identify all possible technologies used for building websites and offers Whois data;

  • CONTENT_ANALYSIS: help you discover citations of the target keyword or brand and analyze the sentiments around it;

Adding New Tools/Modules

Module Structure

Each module corresponds to a specific DataForSEO API:

Implementation Options

You can either:

  1. Add a new tool to an existing module

  2. Create a completely new module

Adding a New Tool

Here's how to add a new tool to any new or pre-existing module:

// src/code/modules/your-module/tools/your-tool.tool.ts
import { BaseTool } from '../../base.tool';
import { DataForSEOClient } from '../../../client/dataforseo.client';
import { z } from 'zod';

export class YourTool extends BaseTool {
  constructor(private client: DataForSEOClient) {
    super(client);
    // DataForSEO API returns extensive data with many fields, which can be overwhelming
    // for AI agents to process. We select only the most relevant fields to ensure
    // efficient and focused responses.
    this.fields = [
      'title',           // Example: Include the title field
      'description',     // Example: Include the description field
      'url',            // Example: Include the URL field
      // Add more fields as needed
    ];
  }

  getName() {
    return 'your-tool-name';
  }

  getDescription() {
    return 'Description of what your tool does';
  }

  getParams(): z.ZodRawShape {
    return {
      // Required parameters
      keyword: z.string().describe('The keyword to search for'),
      location: z.string().describe('Location in format "City,Region,Country" or just "Country"'),
      
      // Optional parameters
      fields: z.array(z.string()).optional().describe('Specific fields to return in the response. If not specified, all fields will be returned'),
      language: z.string().optional().describe('Language code (e.g., "en")'),
    };
  }

  async handle(params: any) {
    try {
      // Make the API call
      const response = await this.client.makeRequest({
        endpoint: '/v3/dataforseo_endpoint_path',
        method: 'POST',
        body: [{
          // Your request parameters
          keyword: params.keyword,
          location: params.location,
          language: params.language,
        }],
      });

      // Validate the response for errors
      this.validateResponse(response);

      //if the main data array is specified in tasks[0].result[:] field
      const result = this.handleDirectResult(response);
      //if main data array specified in tasks[0].result[0].items field
      const result = this.handleItemsResult(response);
      // Format and return the response
      return this.formatResponse(result);
    } catch (error) {
      // Handle and format any errors
      return this.formatErrorResponse(error);
    }
  }
}

Creating a New Module

  1. Create a new directory under src/core/modules/ for your module:

mkdir -p src/core/modules/your-module-name

  1. Create module files:

// src/core/modules/your-module-name/your-module-name.module.ts
import { BaseModule } from '../base.module';
import { DataForSEOClient } from '../../client/dataforseo.client';
import { YourTool } from './tools/your-tool.tool';

export class YourModuleNameModule extends BaseModule {
  constructor(private client: DataForSEOClient) {
    super();
  }

  getTools() {
    return {
      'your-tool-name': new YourTool(this.client),
    };
  }
}

  1. Register your module in src/core/config/modules.config.ts:

export const AVAILABLE_MODULES = [
  'SERP',
  'KEYWORDS_DATA',
  'ONPAGE',
  'DATAFORSEO_LABS',
  'BACKLINKS',
  'BUSINESS_DATA',
  'DOMAIN_ANALYTICS',
  'CONTENT_ANALYSIS',
  'YOUR_MODULE_NAME'  // Add your module name here
] as const;

  1. Initialize your module in src/main/index.ts:

if (isModuleEnabled('YOUR_MODULE_NAME', enabledModules)) {
  modules.push(new YourModuleNameModule(dataForSEOClient));
}

Field Configuration

The MCP server supports field filtering to customize which data fields are returned in API responses. This helps reduce response size and focus on the most relevant data for your use case.

Configuration File Format

Create a JSON configuration file with the following structure:

{
  "supported_fields": {
    "tool_name": ["field1", "field2", "field3"],
    "another_tool": ["field1", "field2"]
  }
}

Using Field Configuration

Pass the configuration file using the --configuration parameter:

# With npm
npm run cli -- http --configuration field-config.json

# With npx
npx dataforseo-mcp-server http --configuration field-config.json

# Local mode
npx dataforseo-mcp-server local --configuration field-config.json

Configuration Behavior

  • If a tool is configured: Only the specified fields will be returned in the response

  • If a tool is not configured: All available fields will be returned (default behavior)

  • If no configuration file is provided: All tools return all available fields

Example Configuration File

The repository includes an example configuration file field-config.example.json with optimized field selections for common tools:

{
  "supported_fields": {
    "backlinks_backlinks": [
      "id",
      "items.anchor",
      "items.backlink_spam_score",
      "items.dofollow",
      "items.domain_from",
      "items.domain_from_country",
      "items.domain_from_ip",
      "items.domain_from_platform_type",
      "items.domain_from_rank",
      "items.domain_to",
      "items.first_seen",
      "items.is_broken",
      "items.is_new",
      "items.item_type",
      "items.last_seen",
      "items.links_count",
      "items.original",
      "items.page_from_encoding",
      "items.page_from_external_links",
      "items.page_from_internal_links",
      "items.page_from_language",
      "items.page_from_rank",
      "items.page_from_size",
      "items.page_from_status_code",
      "items.page_from_title",
      "items.prev_seen",
      "items.rank",
      "items.ranked_keywords_info.page_from_keywords_count_top_10",
      "items.ranked_keywords_info.page_from_keywords_count_top_100",
      "items.ranked_keywords_info.page_from_keywords_count_top_3",
      "items.semantic_location",
      "items.text_post",
      "items.text_pre",
      "items.tld_from",
      "items.type",
      "items.url_from",
      "items.url_from_https",
      "items.url_to",
      "items.url_to_https",
      "items.url_to_spam_score",
      "items.url_to_status_code",
      "status_code",
      "status_message"
    ],
    ...
  }
}

Nested Field Support

The configuration supports nested field paths using dot notation:

  • "rating.value" - Access the value field within the rating object

  • "items.demography.age.keyword" - Access deeply nested fields

  • "meta.description" - Access nested object properties

Field Discovery

To discover available fields for any tool:

  1. Run the tool without field configuration to see the full response

  2. Identify the fields you need from the API response

  3. Add those field paths to your configuration file

Creating Your Own Configuration

  1. Copy the example file:

cp field-config.example.json my-config.json

  1. Modify the field selections based on your needs

  2. Use your custom configuration:

npx dataforseo-mcp-server http --configuration my-config.json

What endpoints/APIs do you want us to support next?

We're always looking to expand the capabilities of this MCP server. If you have specific DataForSEO endpoints or APIs you'd like to see supported, please:

  1. Check the DataForSEO API Documentation to see what's available

  2. Open an issue in our GitHub repository with:

    • The API/endpoint you'd like to see supported;

    • A brief description of your use case;

    • Describe any specific features you'd like to see implemented.

Your feedback helps us prioritize which APIs to support next!

Resources

Available Tools

36 tools
backlinks_page_intersectionB

This endpoint will provide you with the list of domains pointing to the specified websites. This endpoint is especially useful for creating a Link Gap feature that shows what domains link to your competitors but do not link out to your website

ParametersJSON Schema
NameRequiredDescriptionDefault
filtersNoarray of results filtering parameters optional field you can add several filters at once (8 filters maximum) you should set a logical operator and, or between the conditions the following operators are supported: regex, not_regex, =, <>, in, not_in, like, not_like, ilike, not_ilike, match, not_match you can use the % operator with like and not_like to match any string of zero or more characters example: ["1.rank",">","80"] [["2.page_from_rank",">","55"], "and", ["1.original","=","true"]] [["1.first_seen",">","2017-10-23 11:31:45 +00:00"], "and", [["1.anchor","like","%seo%"],"or",["1.text_pre","not_like","%seo%"]]]
limitNothe maximum number of returned results
offsetNooffset in the array of returned results optional field default value: 0 if you specify the 10 value, the first ten backlinks in the results array will be omitted and the data will be provided for the successive backlinks
order_byNoresults sorting rules optional field you can use the same values as in the filters array to sort the results possible sorting types: asc – results will be sorted in the ascending order desc – results will be sorted in the descending order you should use a comma to set up a sorting type example: ["rank,desc"] note that you can set no more than three sorting rules in a single request you should use a comma to separate several sorting rules example: ["domain_from_rank,desc","page_from_rank,asc"]
targetsYesdomains, subdomains or webpages to get links for required field you can set up to 20 domains, subdomains or webpages a domain or a subdomain should be specified without https:// and www. a page should be specified with absolute URL (including http:// or https://)

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It mentions the tool provides a 'list of domains' and hints at a 'Link Gap' use case, but doesn't disclose critical behavioral traits: whether this is a read-only operation, potential rate limits, authentication requirements, pagination behavior (beyond offset/limit parameters), or what format the returned data takes. The description adds minimal behavioral context beyond the basic purpose.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately concise with two sentences. The first sentence states the core purpose, and the second provides a specific use case. Both sentences earn their place by adding value. However, the structure could be slightly improved by front-loading more operational details about the tool's behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

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, no annotations, and many similar sibling tools), the description is insufficiently complete. It doesn't explain what the output looks like, how results are structured, or how this tool differs from other backlinks tools. For a tool with this level of complexity and no structured output documentation, the description should provide more complete operational context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already thoroughly documents all 5 parameters. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it doesn't explain how 'targets' relates to the output, or provide additional context about filter usage. With complete schema coverage, the baseline is 3 even without parameter info in the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'provide you with the list of domains pointing to the specified websites.' This is a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from its many sibling tools (like backlinks_domain_intersection or backlinks_referring_domains), which likely have overlapping functionality in the backlinks domain.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides some usage context: 'especially useful for creating a Link Gap feature that shows what domains link to your competitors but do not link out to your website.' This implies a competitive analysis use case but doesn't explicitly state when to use this tool versus alternatives among the many backlinks siblings, nor does it mention any prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

keywords_data_google_ads_search_volumeC

Get search volume data for keywords from Google Ads

ParametersJSON Schema
NameRequiredDescriptionDefault
keywordsYesArray of keywords to get search volume for
language_codeNoLanguage two-letter ISO code (e.g., 'en'). optional field
location_nameNofull name of the location optional field in format "Country" example: United Kingdom

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe how it behaves: no information about rate limits, authentication needs, error handling, or what the output looks like (since there's no output schema). For a data retrieval tool with zero annotation coverage, this leaves critical behavioral traits unspecified.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a straightforward data retrieval tool and front-loads the core purpose immediately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (data retrieval from an external API), lack of annotations, and absence of an output schema, the description is insufficiently complete. It doesn't explain what search volume data includes (metrics, format), how results are returned, or any limitations. For a tool interacting with Google Ads API, more context about response structure and constraints would be expected.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 three parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema (keywords array, optional language_code and location_name). This meets the baseline of 3 when schema coverage is high, but doesn't provide additional semantic context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get search volume data') and resource ('for keywords from Google Ads'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'keywords_data_dataforseo_trends_explore' or 'keywords_data_google_trends_explore' that might also handle keyword data, so it doesn't fully distinguish from alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, leaving the agent with no usage instructions beyond the basic purpose. This is a significant gap given multiple sibling tools in the keywords_data category.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

on_page_content_parsingC

This endpoint allows parsing the content on any page you specify and will return the structured content of the target page, including link URLs, anchors, headings, and textual content.

ParametersJSON Schema
NameRequiredDescriptionDefault
accept_languageNoAccept-Language header value
custom_jsNoCustom JavaScript code to execute
custom_user_agentNoCustom User-Agent header
enable_javascriptNoEnable JavaScript rendering
urlYesURL of the page to parse

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns structured content, but doesn't cover critical aspects like rate limits, authentication needs, error handling, or performance implications (e.g., timeouts for JavaScript-heavy pages). The mention of 'parsing' implies a read-only operation, but this isn't explicitly confirmed, leaving gaps in transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core functionality. It avoids unnecessary words and directly states what the tool does. However, it could be slightly more structured by separating the action from the output details for clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

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 annotations, and no output schema, the description is incomplete. It doesn't explain the return format (e.g., structure of parsed content), error cases, or dependencies like network access. For a parsing tool with multiple configuration options, this leaves significant gaps for an AI agent to use it effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description doesn't add any parameter-specific details beyond what's in the schema (e.g., it doesn't explain how 'custom_js' interacts with 'enable_javascript'). This meets the baseline for high schema coverage, but no extra value is provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: parsing page content and returning structured data including links, anchors, headings, and text. It specifies the verb ('parsing') and resource ('content on any page'), making the function understandable. However, it doesn't explicitly differentiate from sibling tools like 'on_page_instant_pages' or 'on_page_lighthouse', which might have overlapping or related functionality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It mentions parsing 'any page' but doesn't specify contexts, prerequisites, or exclusions. Given the sibling tools include other on_page tools, this lack of differentiation leaves the agent without clear usage instructions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

on_page_instant_pagesC

Using this function you will get page-specific data with detailed information on how well a particular page is optimized for organic search

ParametersJSON Schema
NameRequiredDescriptionDefault
accept_languageNolanguage header for accessing the website all locale formats are supported (xx, xx-XX, xxx-XX, etc.) Note: if you do not specify this parameter, some websites may deny access; in this case, pages will be returned with the "type":"broken in the response array
custom_jsNoCustom JavaScript code to execute
custom_user_agentNoCustom User-Agent header
enable_javascriptNoEnable JavaScript rendering
urlYesURL to analyze

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the tool returns 'page-specific data' about SEO optimization, but fails to describe critical behaviors: what the output format looks like, whether it's a read-only operation, potential rate limits, authentication needs, or error handling. The description is too high-level to guide an agent effectively.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence that efficiently states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the core function. However, it could be slightly more structured by explicitly separating purpose from context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a 5-parameter tool with no annotations and no output schema, the description is incomplete. It doesn't explain the return format, error conditions, or how parameters interact with the SEO analysis. For a tool that likely returns structured data about page optimization, more context is needed to use it effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema—it doesn't explain how parameters like 'custom_js' or 'enable_javascript' affect the SEO analysis. This meets the baseline of 3 when schema coverage is complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'get page-specific data with detailed information on how well a particular page is optimized for organic search'. It specifies the verb ('get') and resource ('page-specific data'), and distinguishes it from sibling tools like 'on_page_content_parsing' or 'on_page_lighthouse' by focusing on SEO optimization assessment. However, it doesn't explicitly differentiate from all siblings, so it's not a perfect 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'on_page_content_parsing' or 'on_page_lighthouse' that might serve similar purposes, nor does it specify prerequisites or exclusions. The only implied usage is for analyzing page SEO, but this is too vague for effective tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

on_page_lighthouseD

The OnPage Lighthouse API is based on Google’s open-source Lighthouse project for measuring the quality of web pages and web apps.

ParametersJSON Schema
NameRequiredDescriptionDefault
accept_languageNoAccept-Language header value
custom_jsNoCustom JavaScript code to execute
custom_user_agentNoCustom User-Agent header
enable_javascriptNoEnable JavaScript rendering
urlYesURL of the page to parse

TDQS

D1.9/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it only mentions the tool's basis on Lighthouse without describing key behaviors: what the tool outputs (e.g., performance scores, audit results), whether it performs network requests, any rate limits, authentication needs, or side effects. This leaves the agent guessing about the tool's operation and results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is concise but under-specified—it doesn't front-load critical information about the tool's function. While it avoids waste, it lacks structure that could clarify purpose or usage, making it less helpful than a more informative yet still brief description would be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a Lighthouse-based tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It fails to explain what the tool returns, how it behaves, or when to use it, leaving significant gaps for an AI agent to understand and invoke the tool correctly in context with its siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 5 parameters (e.g., 'url' for the page to parse, 'enable_javascript' for rendering). The description adds no additional meaning or context about parameters beyond what the schema provides, such as usage examples or constraints. This meets the baseline for high schema coverage but doesn't enhance understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool is 'based on Google's open-source Lighthouse project for measuring the quality of web pages and web apps,' which provides some context but is vague about the specific action. It doesn't clearly state what the tool actually does (e.g., run a Lighthouse audit, fetch metrics, generate reports) or distinguish it from sibling tools like 'on_page_content_parsing' or 'on_page_instant_pages.' This is closer to a tautology of the name 'on_page_lighthouse' without specifying the verb.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or comparisons with sibling tools (e.g., 'on_page_content_parsing' or 'on_page_instant_pages'), leaving the agent with no information on selection criteria. This is a significant gap in usage instructions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

serp_locationsB

Utility tool for serp_organic_live_advanced to get list of availible locations.

ParametersJSON Schema
NameRequiredDescriptionDefault
country_iso_codeYesISO 3166-1 alpha-2 country code, for example: US, GB, MT
location_nameNoName of location or it`s part.
location_typeNoType of location. Possible variants: 'TV Region','Postal Code','Neighborhood','Governorate','National Park','Quarter','Canton','Airport','Okrug','Prefecture','City','Country','Province','Barrio','Sub-District','Congressional District','Municipality District','district','DMA Region','Union Territory','Territory','Colloquial Area','Autonomous Community','Borough','County','State','District','City Region','Commune','Region','Department','Division','Sub-Ward','Municipality','University'
search_engineNosearch engine name, one of: google, yahoo, bing.google

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'gets' a list, implying a read-only operation, but doesn't clarify if it's a search, filter, or lookup, nor does it mention rate limits, authentication needs, or output format. For a tool with no annotations, this minimal description lacks critical behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's purpose and relationship to a sibling tool. It's front-loaded with key information and has no wasted words, though minor spelling errors ('availible') slightly detract from polish.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no annotations, no output schema, and 4 parameters, the description is incomplete. It doesn't explain what 'availible locations' means in practice, how results are returned, or any limitations. For a utility tool with moderate complexity, this leaves significant gaps in understanding its full context and behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 four parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema, such as how parameters interact or examples of usage. This meets the baseline of 3, as the schema does the heavy lifting, but the description doesn't enhance understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose as a 'utility tool for serp_organic_live_advanced to get list of availible locations.' It specifies the verb ('get') and resource ('list of availible locations'), and identifies its relationship to a specific sibling tool. However, it doesn't fully distinguish from other location-related tools like 'serp_youtube_locations' in the sibling list, keeping it from a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context by mentioning 'for serp_organic_live_advanced,' suggesting it's a helper tool for that sibling. However, it doesn't explicitly state when to use this tool versus alternatives like 'serp_youtube_locations' or standalone location searches, nor does it provide any exclusions or prerequisites. This leaves some ambiguity in usage scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

serp_organic_live_advancedC

Get organic search results for a keyword in specified search engine

ParametersJSON Schema
NameRequiredDescriptionDefault
depthNoparsing depth optional field number of results in SERP
deviceNodevice type optional field can take the values:desktop, mobile default value: desktopdesktop
keywordYesSearch keyword
language_codeYessearch engine language code (e.g., 'en')
location_nameNofull name of the location required field Location format - hierarchical, comma-separated (from most specific to least) Can be one of: 1. Country only: "United States" 2. Region,Country: "California,United States" 3. City,Region,Country: "San Francisco,California,United States"United States
max_crawl_pagesNopage crawl limit optional field number of search results pages to crawl max value: 100 Note: the max_crawl_pages and depth parameters complement each other
people_also_ask_click_depthNoclicks on the corresponding element specify the click depth on the people_also_ask element to get additional people_also_ask_element items;
search_engineNosearch engine name, one of: google, yahoo, bing.google

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden but only states what the tool does without behavioral details. It doesn't disclose if this is a read-only operation, potential rate limits, authentication needs, or what happens with invalid inputs. This leaves significant gaps in understanding the tool's behavior beyond basic functionality.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core purpose without unnecessary details. It avoids redundancy but could be slightly more structured by hinting at key parameters like depth or device, though not required given schema coverage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 8 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain return values, error handling, or behavioral constraints, leaving the agent with incomplete context for safe and effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all 8 parameters. The description adds no additional parameter semantics beyond implying keyword and search engine usage, which is already covered. Baseline 3 is appropriate as the schema handles parameter documentation adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and resource 'organic search results', specifying the action and target. It mentions 'keyword' and 'search engine' to define scope, but doesn't differentiate from sibling tools like 'serp_youtube_organic_live_advanced' which targets YouTube specifically versus general search engines.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 is provided. The description lacks context on prerequisites, such as when to choose this over other SERP or keyword tools, and doesn't mention any exclusions or complementary tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

serp_youtube_locationsB

Utility tool to get list of available locations for: serp_youtube_organic_live_advanced, serp_youtube_video_info_live_advanced, serp_youtube_video_comments_live_advanced, serp_youtube_video_subtitles_live_advanced.

ParametersJSON Schema
NameRequiredDescriptionDefault
country_iso_codeYesISO 3166-1 alpha-2 country code, for example: US, GB, MT
location_nameNoName of location or it`s part.
location_typeNoType of location. Possible variants: 'TV Region','Postal Code','Neighborhood','Governorate','National Park','Quarter','Canton','Airport','Okrug','Prefecture','City','Country','Province','Barrio','Sub-District','Congressional District','Municipality District','district','DMA Region','Union Territory','Territory','Colloquial Area','Autonomous Community','Borough','County','State','District','City Region','Commune','Region','Department','Division','Sub-Ward','Municipality','University'

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but offers minimal behavioral disclosure. It doesn't describe what the tool returns (list format, structure), whether it's cached/real-time data, rate limits, authentication needs, or error conditions. The description only states it's a 'utility tool' without explaining operational characteristics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's purpose and target tools without any wasted words. It's appropriately sized and front-loaded with the core functionality, 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.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no annotations and no output schema, the description is incomplete. It doesn't explain what the returned location data looks like (format, structure, fields), how results are filtered/limited, or any behavioral aspects. For a utility tool that presumably returns structured location data, more context about the output is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already fully documents all three parameters with their types, descriptions, and requirements. The description adds no parameter information beyond what's in the schema, maintaining the baseline score of 3 for adequate but not enhanced parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool's purpose as getting 'list of available locations' for specific YouTube SERP tools, which is clear but somewhat vague. It specifies the resource (locations) and target tools, but doesn't articulate the exact verb or differentiate from the sibling 'serp_locations' tool that appears to serve a similar function for non-YouTube SERP tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly lists four specific sibling tools for which this location data is intended, providing clear context for when to use it. However, it doesn't mention when NOT to use it (e.g., for non-YouTube SERP tools) or explicitly name alternatives like 'serp_locations' for other SERP tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

serp_youtube_organic_live_advancedC

provides top 20 blocks of youtube search engine results for a keyword

ParametersJSON Schema
NameRequiredDescriptionDefault
block_depthNoparsing depth optional field number of blocks of results in SERP max value: 700
deviceNodevice type optional field can take the values:desktop, mobile default value: desktopdesktop
keywordYesSearch keyword
language_codeYessearch engine language code (e.g., 'en')
location_nameYesfull name of the location required field Location format - hierarchical, comma-separated (from most specific to least) Can be one of: 1. Country only: "United States" 2. Region,Country: "California,United States" 3. City,Region,Country: "San Francisco,California,United States"
osNodevice operating system optional field if you specify desktop in the device field, choose from the following values: windows, macos default value: windows if you specify mobile in the device field, choose from the following values: android, ios default value: androidwindows

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool provides 'top 20 blocks' but doesn't explain what constitutes a 'block' (e.g., video results, playlists, channels), whether results are live/real-time, pagination behavior, rate limits, or authentication needs. For a tool with no annotations and complex functionality, this is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core purpose. It wastes no words and is appropriately sized for the tool's complexity, 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.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (6 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the output format (what 'blocks' include), behavioral traits like rate limits or data freshness, or how it differs from siblings. Without annotations or output schema, the description should provide more context to be fully helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all 6 parameters. The description doesn't add any parameter semantics beyond what's in the schema (e.g., it doesn't clarify 'blocks' or provide examples). With high schema coverage, the baseline is 3, as the description doesn't compensate but also doesn't detract.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'provides top 20 blocks of youtube search engine results for a keyword.' It specifies the verb ('provides'), resource ('youtube search engine results'), and scope ('top 20 blocks'). However, it doesn't explicitly differentiate from sibling tools like 'serp_organic_live_advanced' or 'serp_youtube_video_info_live_advanced', which would be needed for a score of 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or contexts where this specific YouTube SERP tool is preferred over general SERP tools or other YouTube-related tools. The absence of usage guidelines leaves the agent without direction for tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

serp_youtube_video_comments_live_advancedC

provides data on the video comments you specify

ParametersJSON Schema
NameRequiredDescriptionDefault
depthNoparsing depth, number of results in SERP, max value: 700
deviceNodevice type optional field can take the values:desktop, mobile default value: desktopdesktop
language_codeYessearch engine language code (e.g., 'en')
location_nameYesfull name of the location required field Location format - hierarchical, comma-separated (from most specific to least) Can be one of: 1. Country only: "United States" 2. Region,Country: "California,United States" 3. City,Region,Country: "San Francisco,California,United States"
osNodevice operating system optional field if you specify desktop in the device field, choose from the following values: windows, macos default value: windows if you specify mobile in the device field, choose from the following values: android, ios default value: androidwindows
video_idYesID of the video

TDQS

C2.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'provides data' which suggests a read-only operation, but fails to describe critical behaviors such as whether this is a live/real-time query, rate limits, authentication needs, data freshness, or what the output format looks like (especially important since there's no output schema). The description is too minimal to adequately inform the agent about how the tool behaves.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero wasted words, making it appropriately concise. However, it lacks front-loading of critical information (e.g., not specifying it's for YouTube video comments retrieval), which slightly reduces its effectiveness despite the brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (6 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what data is returned, how results are structured, or behavioral aspects like live data access. For a tool with 'advanced' in its name and multiple configuration parameters, the minimal description leaves significant gaps in understanding its full context and usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, providing clear details for all 6 parameters (e.g., 'depth' as parsing depth with max value, 'location_name' with format examples). The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting, but doesn't compensate or enhance understanding further.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool 'provides data on the video comments you specify', which indicates a data retrieval function but is vague about what specific data is provided (e.g., comment text, metrics, sentiment). It distinguishes from obvious siblings like 'serp_youtube_video_info_live_advanced' by focusing on comments rather than general video info, but lacks specificity about the verb (e.g., 'fetch', 'analyze') and scope (e.g., 'live', 'advanced' aspects).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description offers no guidance on when to use this tool versus alternatives. There are no explicit mentions of when to use it, when not to use it, or references to sibling tools (e.g., 'serp_youtube_video_info_live_advanced' for general video data). Usage is implied only by the tool name and description, leaving the agent to infer context without clear direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

serp_youtube_video_info_live_advancedC

provides data on the video you specify

ParametersJSON Schema
NameRequiredDescriptionDefault
deviceNodevice type optional field can take the values:desktop, mobile default value: desktopdesktop
language_codeYessearch engine language code (e.g., 'en')
location_nameYesfull name of the location required field Location format - hierarchical, comma-separated (from most specific to least) Can be one of: 1. Country only: "United States" 2. Region,Country: "California,United States" 3. City,Region,Country: "San Francisco,California,United States"
osNodevice operating system optional field if you specify desktop in the device field, choose from the following values: windows, macos default value: windows if you specify mobile in the device field, choose from the following values: android, ios default value: androidwindows
video_idYesID of the video

TDQS

C2.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a read operation ('provides data'), but doesn't disclose critical traits like whether it's live/real-time (suggested by 'live_advanced' in the name), rate limits, authentication needs, or what 'advanced' entails. The description adds little beyond the basic action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, vague sentence that under-specifies rather than being concise. While it's brief, it fails to front-load useful information—every word should earn its place, but this adds minimal value. It's not verbose, but it's inefficient due to lack of substance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what data is returned, how 'live_advanced' affects behavior, or differentiate from siblings. Given the complexity and lack of structured context, the description should do more to guide the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all 5 parameters (e.g., device, language_code, video_id). The description adds no parameter-specific meaning beyond implying 'video you specify' relates to 'video_id', which is already clear from the schema. Baseline 3 is appropriate as the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'provides data on the video you specify' is vague and tautological—it essentially restates the tool name 'serp_youtube_video_info_live_advanced' without specifying what kind of data (e.g., metadata, analytics, SERP rankings) or how it differs from sibling tools like 'serp_youtube_organic_live_advanced' or 'serp_youtube_video_comments_live_advanced'. It lacks a clear verb-resource distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

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. Given multiple sibling tools in the SERP/YouTube category (e.g., 'serp_youtube_organic_live_advanced', 'serp_youtube_video_comments_live_advanced'), the description fails to indicate context, prerequisites, or exclusions, leaving the agent to guess based on names alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

serp_youtube_video_subtitles_live_advancedC

provides data on the video subtitles you specify

ParametersJSON Schema
NameRequiredDescriptionDefault
deviceNodevice type optional field can take the values:desktop, mobile default value: desktopdesktop
language_codeYessearch engine language code (e.g., 'en')
location_nameYesfull name of the location required field Location format - hierarchical, comma-separated (from most specific to least) Can be one of: 1. Country only: "United States" 2. Region,Country: "California,United States" 3. City,Region,Country: "San Francisco,California,United States"
osNodevice operating system optional field if you specify desktop in the device field, choose from the following values: windows, macos default value: windows if you specify mobile in the device field, choose from the following values: android, ios default value: androidwindows
subtitles_languageNolanguage code of original text (e.g., 'en')
subtitles_translate_languageNolanguage code of translated text (e.g., 'en')
video_idYesID of the video

TDQS

C2.1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure but fails to do so. It does not indicate whether this is a read-only operation, if it requires authentication, has rate limits, or what kind of data is returned (e.g., raw subtitles, analysis, metadata). The vague phrase 'provides data' offers no insight into the tool's behavior or constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise—a single sentence with no wasted words. It is front-loaded and to the point, though this brevity contributes to its lack of detail. Every word serves the core message, even if that message is insufficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (7 parameters, no annotations, no output schema), the description is incomplete. It fails to explain what data is returned, how subtitles are processed, or any behavioral aspects. While the schema covers parameters, the overall context for using this tool—especially alongside siblings—is lacking, making it inadequate for informed agent decision-making.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, meaning all parameters are documented in the input schema itself. The description adds no additional meaning about parameters beyond what the schema provides (e.g., it doesn't explain how 'video_id' relates to YouTube URLs or clarify the purpose of 'subtitles_translate_language'). With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'provides data on the video subtitles you specify' is tautological—it essentially restates the tool name 'serp_youtube_video_subtitles_live_advanced' without adding specificity. It lacks a clear verb (e.g., 'fetch', 'retrieve', 'analyze') and does not distinguish this tool from siblings like 'serp_youtube_video_comments_live_advanced' or 'serp_youtube_video_info_live_advanced', which also provide YouTube video data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, context for usage, or comparisons to sibling tools (e.g., when to choose subtitles data over comments or general video info). This leaves the agent without direction for tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.7/5.0
Disambiguation2/5

The tool set has significant overlap and ambiguity, particularly within the backlinks and keywords categories. For example, backlinks_bulk_new_lost_backlinks and backlinks_bulk_new_lost_referring_domains have very similar purposes, and tools like backlinks_domain_intersection and backlinks_page_intersection are nearly identical in description. This makes it difficult for an agent to reliably choose the correct tool without deep domain knowledge.

Naming Consistency4/5

Tool names follow a consistent snake_case pattern with a clear prefix structure (e.g., backlinks_, keywords_data_, on_page_, serp_). However, there are minor deviations such as serp_locations and serp_youtube_locations not following the same verb_noun style as others, and some names are overly long and repetitive (e.g., backlinks_bulk_new_lost_referring_domains). Overall, the naming is predictable but could be more streamlined.

Tool Count2/5

With 36 tools, the count is excessive for a single server, leading to cognitive overload and potential confusion. The tools cover multiple domains (backlinks, keywords, on-page, SERP, YouTube), suggesting the server is overly broad. A more focused approach with fewer, more distinct tools would improve usability and coherence.

Completeness4/5

The server provides comprehensive coverage across SEO-related domains, including backlinks, keywords, on-page analysis, and SERP data. There are no obvious major gaps; for example, it includes both bulk and individual operations, time-series data, and utility tools. However, the sheer number of tools may obscure completeness, and some areas like keyword tracking could benefit from more streamlined integration.

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

Appeared in Searches

Latest Blog Posts

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/cortex8/oyt-dataforseo-mcp-worker'

If you have feedback or need assistance with the MCP directory API, please join our Discord server