Skip to main content
Glama
Sign In
Google Ads MCP Server

Google Ads MCP Server

by adkit
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

List ad platforms

list_ad_platforms
Read-onlyIdempotent

Lists supported ad platforms and links to each platform's MCP server and setup page, helping users identify supported networks or find a server for a single platform.

Instructions

List the ad platforms AdKit supports (Google, Meta, TikTok, LinkedIn, Microsoft, Reddit, X, Pinterest) and the link to each platform's own MCP server and setup page. Use this when the user asks which ad platforms are supported or wants a server for one platform only. Returns Markdown.

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": "list_ad_platforms"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the return format ('Returns Markdown'), which is useful beyond the annotations but thin for a tool whose output is otherwise unenumerated; there is no output schema to lean on.

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?

Two front-loaded sentences with no wasted framing: contents first, usage condition second. The inline enumeration of eight platforms is slightly bulky but earns its place by telling the agent the coverage without a call.

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 zero-parameter read-only catalog tool with no output schema, the description covers what is returned (platform names, MCP server links, setup page links) and the format (Markdown). What remains unstated is minor: whether every platform always has both links, and whether output includes anything else.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description correctly conveys that no filtering or platform argument is needed, confirming the call is argument-free.

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?

The description uses a specific verb ('List') plus a concrete resource ('the ad platforms AdKit supports') and enumerates exactly what the user gets back: the eight platform names plus each platform's own MCP server link and setup page. An agent can tell this is a static catalog lookup and not a filtered search or a setup-instructions tool.

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?

It gives explicit triggering conditions: the user asks which platforms are supported, or wants a server for one platform only. It does not name an alternative tool to use when the user actually needs setup steps (e.g. a setup-guide sibling), so there is no explicit exclusion, but the intended context is clear.

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

Deploy Server

Other Tools