Skip to main content
Glama
LeadMagic

LeadMagic MCP Server

by LeadMagic

Google Ads Search

search_google_ads

Find Google Ads by company domain or name to analyze competitor advertising strategies. Reveals creative content and campaign insights for market research.

Instructions

Search for Google Ads based on company's domain or name. Analyze competitor advertising strategies, creative content, and campaign insights.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
company_nameNo
company_domainNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

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 behavioral burden and largely fails it: nothing about whether the call consumes credits (a real concern given get_credits is a sibling), rate limits, result volume, or what a hit vs. miss looks like. Only 'search' implies a read operation, which is minimal disclosure.

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?

Two short sentences with the concrete capability front-loaded and no padding. The second sentence's 'creative content, and campaign insights' adds flavor but little operational value.

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?

With no annotations, no output schema, 0% schema description coverage, and two optional mutually-ambiguous parameters, the description should clarify selector semantics and return shape. It leaves the agent without enough to call the tool confidently, especially on whether to pass both parameters at once.

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

Parameters2/5

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

Schema description coverage is 0% for two parameters, so the description must compensate and only partially does: it maps company_domain and company_name to 'domain or name' but never says whether they are alternatives or combined, which is preferred, or accepted formats (bare domain vs URL).

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 first sentence names a specific verb and resource ('Search for Google Ads') and gives the two accepted keys ('company's domain or name'), which lets an agent distinguish it from sibling ad tools like search_meta_ads and search_b2b_ads. The second sentence drifts into vague benefit language ('campaign insights') rather than defining the tool further.

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 phrase 'Analyze competitor advertising strategies' implies the intended use case, but there is no explicit when-to-use, no exclusion, and no guidance on choosing this over search_meta_ads or search_b2b_ads in the sibling set. Usage is inferable but not stated.

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