mcp-server

list_ad_channels

Read-onlyIdempotent

Search the CATALOG of ADS channels you can ADD — product-listing channels (Google Shopping, Meta catalog, Microsoft, Pinterest, …) you can create an ads integration for (to list the ads that ALREADY exist, use list_ads). Use this when the user wants to add an ad channel and needs its channelCode. Ads are product-listing channels for the merchant's physical products, not marketplaces: they publish products to the channel and have no order sync. SEARCHABLE + PAGED: pass query to match a channelCode/label, page with limit/offset (response carries hasMore + nextOffset). Response = {channels, returned, total, kind, hasMore, nextOffset}; each channel = {channelCode, label, kind, available, availabilityReason, authType, orderSyncSupported, multichannel, multichannelCode, primaryChannelCode, devOnly, feedManagerUrl}. available=false → availabilityReason says why: 'not_included' or another reason (not available for this Koongo account). orderSyncSupported is always false for ads. Use channelCode with get_ad_channel (definition types + capabilities) then create_ad. project_id is OPTIONAL (inferred for a single-project customer; project_id_required otherwise — then call list_projects).

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

Input Schema

Name	Required	Description
`limit`	No	Max channels per page (default 50, max 200).
`query`	No	Filter to channels whose code or label contains this text.
`offset`	No	Channels to skip; use the response nextOffset to page.
`project_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the description is free to spend its words on non-obvious behavior: available=false is explained via availabilityReason ('not_included'), orderSyncSupported is pinned to always false for ads, and paging semantics (hasMore/nextOffset) are disclosed. The project_id inference rule is a genuine behavioral trait not derivable from annotations or schema.

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?

Front-loaded with purpose and the sibling disambiguation, then structured by concern (scope, paging, response shape, next steps, project_id). The full enumeration of every channel field is heavy for a description, though it substitutes for the missing output schema, so the length is largely justified rather than padded.

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?

With no output schema, the description supplies the return shape both at the envelope level ({channels, returned, total, kind, hasMore, nextOffset}) and per-channel field level, including which fields are always false for ads. Combined with the follow-on tool chain and project_id handling, nothing material is missing for a read-only listing tool.

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?

Schema coverage is 75%, and the one undocumented parameter — project_id — is fully explained (optional, inferred for single-project customers, project_id_required otherwise). query's matching behavior (channelCode/label) and the paging contract are restated, which mostly duplicates the schema rather than adding new meaning, keeping this just below a 5.

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?

Opens with a specific verb and resource ("Search the CATALOG of ADS channels you can ADD") and immediately bounds the domain: product-listing channels, not marketplaces. It explicitly distinguishes itself from the two nearest siblings, list_ads (existing ads) and list_marketplace_channels (implied by the ads-vs-marketplaces contrast), so an agent can route correctly without opening a schema.

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?

Gives an explicit trigger ("Use this when the user wants to add an ad channel and needs its channelCode") plus a negative route to list_ads for the opposite intent. It also prescribes the follow-on sequence — channelCode → get_ad_channel → create_ad — and the project_id fallback (call list_projects when project_id_required), which is exactly the when-to-use guidance an agent needs.

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?