Skip to main content
Glama
adwhispr

AdWhispr Ads MCP Server

Official

Search ads by idea

search_ads
Read-only

Find a brand's ads by idea, such as before-and-after or social proof, to research winning creative and guide your next campaign.

Instructions

Search a brand's ads by idea, such as "before and after" or "social proof".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.3/5.0
Behavior3/5

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

The readOnlyHint=true annotation already establishes this as a safe read operation, lowering the disclosure bar. The description adds that retrieval is concept-driven rather than keyword- or ID-driven, which is a genuine behavioral trait, but says nothing about result volume, ordering, or pagination.

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?

A single front-loaded sentence that conveys the verb, resource, and filter dimension with two illustrative examples. No filler and nothing deferred to a later sentence.

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

Completeness3/5

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

With no input properties and no output schema, the description carries the burden of explaining what comes back and what to supply, and it only partially does so. It never says whether the return is a list of ad creatives, how many, or how the 'idea' argument is passed.

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?

Zero parameters means the baseline is 4, but the description implies an 'idea' input that is not modeled anywhere in the schema (empty properties, additionalProperties true). That hint is useful directionally yet ambiguous about the actual calling shape, so it neither fully earns the no-params baseline nor leaves the agent stranded.

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 names a specific verb (Search) and resource (a brand's ads) and adds the distinguishing filter dimension (by idea), with concrete examples 'before and after' and 'social proof'. It stops short of naming or contrasting with the sibling get_brand_ads, which also retrieves brand ads, so an agent must guess how the two differ.

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 when-to-use guidance is given — nothing says when to pick this over get_brand_ads, search_brands, or get_instagram_content. The 'by idea' phrase hints at a use case but never states prerequisites or exclusions.

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