mcp-server

list_ads

Read-onlyIdempotent

List the CREATED ads of a project (the ad integrations that already exist, not the catalog of channels you can add — use list_ad_channels for that). Use this to find an existing ad and its ad_id. Ads are product-listing channels (Google Shopping, Meta catalog, Microsoft, price comparison) for the merchant's physical products, not marketplaces: they publish products to the channel and have no order sync. Returns {integrations, returned, total}; each row is {integrationId, projectId, name, channelCode, kind:'ads', definitionCode, status, ready, lastStep, isReady, isConnected, isOverlimit, productMode, orderMode, orderSync}. project_id is OPTIONAL: with it you get that project's ads; WITHOUT it you get ads across ALL your projects (each row carries its projectId). If a call returns project_id_required, pick a project (see list_projects) and pass its project_id. integrationId is what you pass as ad_id to get_ad / ad_status and the other ads tools.

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_ads"
  }
}

Input Schema

Name	Required	Description	Default
`project_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 1, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the read-only and idempotent annotations, it discloses domain behavior: ads publish products to product-listing channels and have no order sync. It also describes the return shape, optional cross-project behavior, and a structured error recovery path, adding substantial context not covered by annotations.

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?

The description is front-loaded with the scope and the key sibling contrast, with no filler. The inline return-field list is dense, but it is justified because there is no output schema; still, it makes one sentence unusually heavy.

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?

For a one-parameter read-only tool with no output schema, the description supplies everything an agent needs: scope, alternatives, optional parameter behavior, return fields, ad_id mapping, and error fallback. It is complete relative to the tool's complexity.

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% for the single parameter, but the description fully explains project_id semantics: optional scoping to one project, without it returning ads across all projects, and each row carrying projectId. It also explains that integrationId is the value to pass as ad_id to get_ad, ad_status, and other ads tools.

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?

Names the specific verb and resource, 'List the CREATED ads', and explicitly distinguishes it from list_ad_channels as the channel catalog. It also clarifies that ads are product-listing channels rather than marketplaces, helping separate it from marketplace tools.

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?

Explicitly says to use this tool to find an existing ad and its ad_id, and explicitly says not to use it for the catalog of channels, directing to list_ad_channels instead. It also explains optional project scoping and the project_id_required recovery path via list_projects.

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

All mcp-server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?