Skip to main content
Glama

Metadata MCP Connector

List Search Terms

list_search_terms
Read-only

Review the Google Ads search terms report with filtering, sorting, and pagination.

            PURPOSE:
            List the actual search queries that triggered the account's Google Ads, so you can
            review wasteful or off-target terms and decide which ones to add to a negative
            keywords list. Mirrors the "Search Terms" library page in the Metadata UI.

            WHEN TO USE:
            - Investigate which queries are costing money without producing clicks or conversions
            - Find queries to add to a negative keywords list (pair with add_keywords_to_negative_lists)
            - Inspect search terms tied to a specific experiment or matched keyword
            - Sort by cost / clicks / conversions to surface the worst offenders

            FILTERS (all optional):
            - searchTerm: substring match on the search term text
            - experiment: experiment name substring match
            - keyword: matched keyword substring
            - matchType: array subset of [PHRASE, BROAD, EXACT, NEAR_EXACT, NEAR_PHRASE]
            - startDate / endDate: ISO-8601 timestamps (e.g. 2026-06-01T00:00:00.000Z).
              The UI defaults to the last 30 days when both are omitted.

            PAGINATION & SORT:
            - page: 0-based (default 0)
            - size: rows per page (default 12, max 100)
            - sort: "<field>,<direction>". Sortable fields include searchTerm, matchType,
              experiment, addedExcluded, keyword, impressions, clicks, ctr, averageCpc,
              spent, conversions, costPerConversion. Direction is asc or desc.
              Default: "clicks,desc".

            RESPONSE FORMAT:
            Returns a paginated response:
            {
              "totalElements": 123,
              "totalPages": 5,
              "data": [
                {
                  "id": "bGVhZCBnZW5lcmF0aW9uIGNhbmFkYQ",
                  "searchTerm": "lead generation canada",
                  "experiment": "MD_Experiment",
                  "experimentId": "179908",
                  "matchType": "PHRASE",
                  "keyword": "lead generation",
                  "addedExcluded": "Added",
                  "impressions": 200,
                  "clicks": 11,
                  "ctr": 5.5,
                  "averageCpc": 2.3,
                  "spent": 25.30,
                  "conversions": 0,
                  "costPerConversion": null
                },
                ...
              ]
            }

            COMMON USE CASES:
            1. Top spenders with zero conversions in the last 30 days:
               list_search_terms(sort="spent,desc")
               then filter the response client-side for conversions == 0.

            2. Worst CTR among phrase matches:
               list_search_terms(matchType=["PHRASE"], sort="ctr,asc")

            3. Search terms tied to a specific experiment:
               list_search_terms(experiment="Q2 Brand Test")

            4. Date-bounded review:
               list_search_terms(
                 startDate="2026-05-01T00:00:00.000Z",
                 endDate="2026-05-31T23:59:59.999Z",
                 sort="spent,desc"
               )

            PARAMETERS:
            - searchTerm (string, optional): substring filter on the search term text.
            - experiment (string, optional): experiment name substring filter.
            - keyword (string, optional): matched keyword substring filter.
            - matchType (array of strings, optional): subset of
              [PHRASE, BROAD, EXACT, NEAR_EXACT, NEAR_PHRASE].
            - startDate (string, optional): ISO-8601 timestamp lower bound.
            - endDate (string, optional): ISO-8601 timestamp upper bound.
            - page (integer, optional): 0-based page index (default 0).
            - size (integer, optional): rows per page (default 12).
            - sort (string, optional): "<field>,<direction>" (default "clicks,desc").

            CHANNEL SCOPE:
            BOTH search channels are supported: pass channel=MICROSOFT_ADS for Microsoft
            Ads (Bing) and channel=GOOGLE_ADS for Google. The two channels hold SEPARATE
            reports, so never substitute one channel for the other to get "close enough"
            results.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo0-based page index. Default 0.
sizeNoRows per page. Default 12 (kept small to limit chat-context tokens), max 100.
sortNoSort criteria in format '<field>,<direction>'. Default 'clicks,desc'. Sortable fields: searchTerm, matchType, experiment, addedExcluded, keyword, impressions, clicks, ctr, averageCpc, spent, conversions, costPerConversion.clicks,desc
channelNoAd channel scope. Both search channels are supported. These are PER-CHANNEL resources: GOOGLE_ADS and MICROSOFT_ADS hold separate sets, and one is invisible to the other. Defaults to GOOGLE_ADS when the user does not say which.GOOGLE_ADS
endDateNoOptional ISO-8601 timestamp upper bound (e.g. 2026-06-30T23:59:59.999Z).
keywordNoOptional matched-keyword substring filter.
matchTypeNoOptional subset of match types to include.
startDateNoOptional ISO-8601 timestamp lower bound (e.g. 2026-06-01T00:00:00.000Z).
experimentNoOptional experiment name substring filter.
searchTermNoOptional substring filter on the search term text.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds substantial behavioral context: default 30-day date window, page/size/sort defaults, a detailed response format with field examples and null handling, and a strong warning that GOOGLE_ADS and MICROSOFT_ADS channels are separate and must not be substituted.

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 well-structured and front-loaded with purpose, and the use cases and response example are valuable. However, it is long and repetitive: FILTERS/PAGINATION and CHANNEL SCOPE largely restate the schema, and the full PARAMETERS section duplicates the input schema almost verbatim.

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

Completeness5/5

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

With no output schema, the RESPONSE FORMAT section provides the needed return-shape context, and the description fully covers defaults, filters, sorting, date formats, channel scope, and practical usage via worked examples. Nothing an agent needs to correctly select and invoke this tool is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the implicit date-window default, the token-saving rationale for size=12, the channel separation warning, and worked sort examples. Much of the PARAMETERS section duplicates the schema, but the extra behavioral context justifies a 4.

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

Purpose5/5

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

States a specific verb and resource: it lists/reviews the Google Ads search terms report, showing actual queries that triggered ads and supporting negative-keyword decisions. It also anchors the tool as mirroring the 'Search Terms' library page, making it clearly distinguishable from broader keyword or reporting tools in the sibling set.

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?

Provides an explicit 'WHEN TO USE' section with concrete scenarios, including pairing with add_keywords_to_negative_lists and sorting to surface wasteful terms. It lacks explicit 'when not to use' guidance or named alternatives for keyword-level reporting, so it falls just short of full routing clarity.

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.

Resources