Skip to main content
Glama

Find what works for your brand

get_what_works
Read-onlyIdempotent

Returns what is working for one of the account’s brands: up to three brand-specific insights and up to twelve standout image ads (at most three per advertiser), from the brand’s tracked competitors or, with category, from a one-time Ad Library sample that tracks nothing. The usual first read before making a campaign from rivals’ best ads. state insufficient_evidence means fewer than two standout ads were found; a category, or more tracked competitors, widens the evidence. Samples carry no totals and stale observations are marked. Ads returned draw on the daily workspace reading allowance.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_what_works"
  }
}

Input Schema

NameRequiredDescriptionDefault
brand_idNoBrand id from list_brands. Needed when the account has several brands; an account with one brand uses it automatically.
categoryNoOptional category or market in plain words, such as gym software. Switches the evidence from tracked competitors to a one-time sample of Ad Library advertisers in that category; nothing is tracked.
response_formatNoOutput format: text (default) or json. table is not available for this tool.

Output Schema

NameRequiredDescriptionDefault
stateNoready, pending, unavailable, or insufficient_evidence.
insightsNoAt most three supported brand-specific insights.
retry_atNoEarliest retry time for an expired or failed insight attempt, when supplied.
allowanceNoFree daily ad-return allowance for this workspace, resetting at midnight UTC.
cache_keyNoEvidence and brand version cache identity.
standoutsNoUp to twelve standout ads, at most three per advertiser.
reading_useNoreading use value in this response.
cost_creditsNoCredits quoted or charged by this operation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / brand_id / description
      Previous value: -"Public brand reference from list_brands. Required when the account has multiple brands; category-only requests use the sole brand."New value: +"Brand id from list_brands. Needed when the account has several brands; an account with one brand uses it automatically."
    • changedInput schema / properties / category / description
      Previous value: -"Optional category or market in plain words, such as gym software. Uses library advertisers in that category for a one-time look and does not track them."New value: +"Optional category or market in plain words, such as gym software. Switches the evidence from tracked competitors to a one-time sample of Ad Library advertisers in that category; nothing is tracked."
    • changedInput schema / properties / response_format / description
      Previous value: -"Output format: text or json for capped research examples; table is available only for tracked rival rows."New value: +"Output format: text (default) or json. table is not available for this tool."
  2. Changed2 schema fields changed
    • addedOutput schema / properties / allowance
      Added value: +{
      +  "anyOf": [
      +    {
      +      "additionalProperties": false,
      +      "description": "Free daily ad-return allowance for this workspace, resetting at midnight UTC.",
      +      "properties": {
      +        "daily_limit": {
      +          "description": "Maximum free ad examples returned per UTC day.",
      +          "type": "number"
      +        },
      +        "remaining": {
      +          "description": "Free ad examples still available today.",
      +          "type": "number"
      +        },
      +        "resets_at": {
      +          "description": "ISO timestamp when the allowance or credits reset.",
      +          "type": "string"
      +        }
      +      },
      +      "required": [
      +        "daily_limit",
      +        "remaining",
      +        "resets_at"
      +      ],
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "Free daily ad-return allowance for this workspace, resetting at midnight UTC."
      +}
    • addedOutput schema / properties / reading_use
      Added value: +{
      +  "anyOf": [
      +    {
      +      "additionalProperties": false,
      +      "description": "reading use value in this response.",
      +      "properties": {
      +        "ads_returned": {
      +          "anyOf": [
      +            {
      +              "description": "ads returned value in this response.",
      +              "type": "number"
      +            },
      +            {
      +              "type": "null"
      +            }
      +          ],
      +          "description": "ads returned value in this response."
      +        },
      +        "message": {
      +          "anyOf": [
      +            {
      +              "description": "message value in this response.",
      +              "type": "string"
      +            },
      +            {
      +              "type": "null"
      +            }
      +          ],
      +          "description": "message value in this response."
      +        }
      +      },
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "reading use value in this response."
      +}
  3. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, open-world and non-destructive behavior, but the description adds non-obvious traits: ads draw on the daily workspace reading allowance (a quota cost), samples carry no totals, stale observations are marked, and the `insufficient_evidence` state has a defined threshold of fewer than two standout ads. That is meaningful disclosure beyond the structured fields; only auth/permission requirements are left unstated.

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 payload scope is front-loaded in the first sentence, followed by usage context, then degraded-state semantics and quota note — a sensible ordering with no filler. The middle sentences are long and clause-heavy, which slightly slows scanning, but every sentence contributes information.

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 read tool with full annotations, a complete output schema, and fully described parameters, the description supplies what the structured data cannot: quota consumption, sample limitations, staleness marking, and insufficient-evidence semantics. Nothing an agent needs in order to call it correctly appears to be missing.

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 all three parameters are already documented, and the description largely restates them: brand_id scoping and the category switch to a one-time sample. The one genuine addition is tying thin results back to the category parameter as the remedy. Baseline 3 is appropriate since the schema carries the parameter burden.

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 uses a specific verb and resource ('Returns what is working for one of the account's brands') and quantifies the payload: up to three insights and up to twelve standout image ads, at most three per advertiser. It clearly delimits the two evidence sources (tracked competitors vs. a one-time Ad Library sample). It does not explicitly contrast itself with the sibling find_winning_ads, so an agent must infer that boundary.

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 usual first read before making a campaign from rivals' best ads' gives a concrete use context, and the description explains the branch condition for `category` versus default tracked-competitor mode. It also tells the agent what to do when evidence is thin ('a category, or more tracked competitors, widens the evidence'). It stops short of naming when to prefer a different tool outright.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.