Skip to main content
Glama
Decodo

Decodo MCP Server

by Decodo

Google Ads

google_ads
Read-only

Retrieve paid Google Ads for a search query as parsed JSON to identify advertisers bidding on keywords and review their ad copy.

Instructions

Search Google through the Decodo Web Scraping API (google_ads target) and return the paid Google Ads shown for a query, parsed as JSON. Use it to see which advertisers bid on a keyword and what their ads say. Docs: https://help.decodo.com/docs/web-scraping-api-google-ads

Input Schema

NameRequiredDescriptionDefault
geoNoGeolocation of the desired request, expressed as a country name
queryYesSearch query for Google Ads (e.g., "laptop")
localeNoLocale of the desired request
jsRenderNoShould the request be opened in a headless browser, false by default
pageFromNoStarting page number for pagination
deviceTypeNoDevice type to emulate for the request

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint and destructiveHint, so the safety profile is covered. The description adds that requests go through the Decodo Web Scraping API and come back as parsed JSON, but says nothing about latency, quota/rate limits, or how heavily the result set is summarized.

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?

Two front-loaded sentences with the purpose first and the practical use case second, followed by a docs link. No filler and no repetition of the title.

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

Completeness4/5

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

For a simple read-only lookup with full schema coverage and annotations, the description covers what the tool is, what it returns conceptually, and where the reference docs live. The only gap is the shape of the returned ad objects, which no output schema defines.

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 coverage is 100% and every parameter (geo, locale, jsRender, pageFrom, deviceType) has its own description, so the schema carries the load. The description adds no extra meaning about any of the six parameters, which is the baseline case.

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?

Names a specific verb and resource: it searches Google and returns the paid Google Ads for a query, parsed as JSON. That distinguishes it from the organic 'google_search' sibling by describing the result set, though it never names an alternative tool outright.

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?

'Use it to see which advertisers bid on a keyword and what their ads say' gives a concrete use case and context. It stops short of explicit exclusions such as 'use google_search for organic results', leaving the routing decision partly to inference.

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