Get Google Ad Library ad
google_adLibrary_ad_getGet a single Google Ad Transparency creative by public Ad Transparency URL.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public Google Ad Transparency URL for the creative. |
google_adLibrary_ad_getGet a single Google Ad Transparency creative by public Ad Transparency URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public Google Ad Transparency URL for the creative. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds only that the URL must be 'public' and the result is 'single', but does not disclose response format, error behavior, or any other operational details. This is adequate given annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no waste. It front-loads the action and the key input requirement, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-URL tool with one parameter and read-only annotations, the description is nearly complete. It does not describe the return payload, but the tool name and the presence of sibling ad-library get tools (e.g., facebook_adLibrary_ad_get) imply a standard retrieval response. The lack of an output schema shifts some burden, but overall the context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the url parameter with the note 'Public Google Ad Transparency URL for the creative.' The description's phrase 'by public Ad Transparency URL' essentially repeats the schema, adding negligible new meaning. With 100% schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely names the verb ('Get'), the resource ('Google Ad Transparency creative'), and the input discriminator ('by public Ad Transparency URL'). It clearly distinguishes from sibling tools like google_adLibrary_advertisers_search or google_company_ads_list, and from ad-library fetchers on other platforms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for fetching a known ad by URL, but it does not explicitly state when to use this versus the sibling search or list tools. An agent must infer that this tool is appropriate only when a public URL is already available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool is clearly scoped to a specific platform and action (e.g., facebook_post_get vs instagram_post_get). Descriptions explicitly differentiate similar tools across platforms, and within-a-platform tools like tiktok_search_videos_list vs tiktok_search_hashtag_list have clear disambiguation notes.
All 167 tools follow a strict `platform_resource_action` pattern (e.g., youtube_video_comments_list). No mixing of styles—snake_case throughout, with consistent verb ordering (get, list, search, etc.).
The server has 167 tools, which is far beyond the typical well-scoped range of 3-15. While the broad multi-platform scope justifies many tools, this extreme number makes the tool surface overwhelming and difficult for an agent to navigate efficiently.
The tool set covers a wide range of platforms and operations including profile retrieval, post/video fetching, comments, search, transcripts, and ad library access. Minor gaps exist (e.g., no Facebook events or LinkedIn messaging), but the surface is comprehensive for a read-only data aggregation use case.