Skip to main content
Glama

Opus Growth, Ad Platforms MCP Connector

Asset Library

list_assets
Read-onlyIdempotent

Lists the account's ASSET LIBRARY ("Öğeler" / Assets) — ALL asset types across the whole account (not just one campaign): sitelinks, callouts, structured snippets, calls, IMAGES, promotions, prices, lead forms, and text assets. Shows each asset's type, a readable label, id, and source (ADVERTISER = you created it, AUTOMATICALLY_CREATED = Google auto). Optionally filter with asset_type (e.g. IMAGE, SITELINK, CALLOUT, PROMOTION). The reply always reports the TRUE total in the account and says when the list was cut short by limit, so a capped page is never mistaken for the whole library. include_usage=true also says, per asset, whether it is used by a running ad, only by paused/removed ones, or by nothing at all — that is what to check before any clean-up. NOTE: Google Ads has NO API to delete library assets (the API supports create and update only), so unused assets cannot be removed from here or in bulk; they can only be unlinked from campaigns (remove_extension_assets) or hidden in the Google Ads interface. LOCATION is NOT an asset-library type — location assets come from the Google Business Profile link and are handled by add_location_assets. BUSINESS NAME / LOGO are NOT asset types in Google Ads — they are FIELD TYPES of a TEXT or IMAGE asset, so look for them with list_extension_assets (which reports campaign- and account-level BUSINESS_NAME / BUSINESS_LOGO / LANDSCAPE_LOGO links) and attach them with manage_extension_assets(link_asset_ids=..., link_field_type=...). include_approval=true adds, per asset, its LINK approval status across campaigns and the account — approval_status is ELIGIBLE / PENDING / LIMITED / NOT_ELIGIBLE, with reasons such as ASSET_DISAPPROVED — plus a top-level approval_summary of the disapproved/limited ones. That is how you answer "which sitelinks were not approved" (the ad-level policy report, list_ad_policy_issues, covers ads only and never shows extension/sitelink assets). Read-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
asset_typeNo
customer_idYes
include_usageNo
include_approvalNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Added
  4. Removed
  5. Added
  6. Removed
  7. Added
  8. Removed
  9. Added
  10. Removed
  11. Added
  12. Removed
  13. Added
  14. Removed
  15. Added
  16. Removed
  17. Added
  18. Removed
  19. Added
  20. Removed
  21. Added
  22. Removed
  23. Added
  24. Removed
  25. Added
  26. Removed
  27. Added
  28. Removed
  29. Added
  30. Removed
  31. Added
  32. Removed
  33. Added
  34. Removed
  35. Added
  36. Removed
  37. Added
  38. Removed
  39. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly/idempotent/non-destructive), and the description adds substantial behavior beyond them: source values, guaranteed reporting of the TRUE total, explicit flagging when `limit` truncates the list, and the hard constraint that no API exists to delete library assets. This is exactly the kind of context that prevents an agent from planning an impossible deletion.

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?

Purpose and return semantics are front-loaded, but the description is a dense wall of run-on sentences, bundling several distinct clarifications (usage, delete limitation, non-types, approval) into one paragraph with no structural breaks. The content is mostly earned, but scannability suffers.

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?

Though an output schema exists (so return values needn't be spelled out), the description still documents the key returned fields and both opt-in behaviors, fully arming an agent to call and interpret this tool. Nothing material is missing for a read-only list tool with sibling ambiguity.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must carry all parameter meaning, and it does: asset_type examples (IMAGE, SITELINK, CALLOUT, PROMOTION), include_usage semantics (running/paused/removed/none), include_approval with its enum values (ELIGIBLE/PENDING/LIMITED/NOT_ELIGIBLE) and reasons, and limit's truncation behavior.

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+resource ('Lists the account's ASSET LIBRARY') and enumerates exactly what it covers across the whole account, not one campaign. It proactively distinguishes itself from sibling concerns (list_extension_assets, add_location_assets, remove_extension_assets) so an agent can route correctly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when/when-not guidance: names the filter condition for asset_type, tells the agent that clean-up is done via remove_extension_assets or the UI, and clarifies that LOCATION and BUSINESS NAME/LOGO are NOT library types and belong to other tools. It even names the sibling (list_ad_policy_issues) for the adjacent task.

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.