Skip to main content
Glama
get-mcp-ads

ChatGPT Ads MCP server

openai ads get conversion pixels

openai_ads_get_conversion_pixels
Read-onlyIdempotent

Lists an ad account's conversion pixels and connected pixel IDs, preserving native fields and pagination for auditing or integration setup.

Instructions

List the account's conversion pixels and connected pixel IDs. Native fields and pagination are preserved. See openai_ads_get_write_schema for nested request fields.

Input Schema

NameRequiredDescriptionDefault
queryNoDocumented native query parameters. Each call reads one page unless the tool says otherwise.
adAccountIdYesThe adacct_ ID configured in OPENAI_ADS_ACCOUNT_ID. The API key is scoped to this one account; another ID is refused.

Output Schema

NameRequiredDescriptionDefault
resultYesOriginal tool result: parsed JSON when the text is JSON, otherwise the text or multiple MCP content blocks. Provider fields depend on the selected query.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered structurally. "Native fields and pagination are preserved" adds a little behavioural context about response shape, but "preserved" is vague about whether pagination tokens are returned or handled internally. No mention of rate limits or page-size behaviour beyond what the schema states.

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?

Three short sentences, purpose front-loaded, no filler. The final sentence about write_schema is the weakest link concision-wise because it points a read tool at a write-schema helper.

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

Completeness3/5

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

Annotations and an output schema exist, and required/optional parameters are fully documented, so most of the burden is already met. The description leaves scope ambiguity versus the other conversion_* tools and includes a possibly misleading write-schema pointer, which keeps it from being fully complete.

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%, including a documented adAccountId constraint and a fully described nested query object, so the schema carries parameter meaning. The description adds nothing about parameters, which is acceptable at this coverage level but is only baseline.

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?

"List the account's conversion pixels and connected pixel IDs" gives a specific verb (list) and resource (conversion pixels), and the output content is named. It does not explicitly distinguish itself from near-neighbour siblings such as openai_ads_get_conversion_settings or openai_ads_get_conversion_events, though the resource noun differs enough to be workable.

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

Usage Guidelines3/5

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

No statement of when to pick this over the conversion_settings/conversion_events siblings, so usage is only implied by the resource name. The one routing pointer present ("See openai_ads_get_write_schema") is a cross-reference but not a when/when-not rule, and it is arguably misdirected for a read-only list operation.

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