mcp-server

refresh_ad_category_attributes

AD category attributes — fetch the channel's CATEGORY attributes for the ad's currently mapped categories and refresh its rewrite rules — the same 'Update Category Attributes' action the wizard runs. Use this to load an ad's category attributes after mapping categories. Some ad channels expose extra, category-specific required attributes that only appear AFTER a category is mapped; run this after configuring the category-mapping step so those attributes show up in get_ad_attributes. Calls the channel (a live read) and rebuilds the integration. After this the category attributes appear in get_ad_attributes and you map them with map_ad_attribute like any other attribute. Returns {integrationId, action:'refresh_category_attributes', status:'updated', kind, editUrl, message}. Re-export/submit afterwards to reach the channel. ad_id is from list_ads. project_id is OPTIONAL (project_id_required otherwise — then call list_projects). ON CHANNELS THAT PRE-CACHE, THIS DOES NOT CALL THE CHANNEL SYNCHRONOUSLY: if the attributes for the current categories are not downloaded yet it returns status:'warming' with a categoryAttributeWarmup block and does the work in the background — that is a SUCCESS, not an error. Then poll ad_status until the block is absent or state is 'ready'; the attributes are pulled in automatically, so you do NOT have to call this again. Only call it a second time if ad_status reports state 'failed'.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "ad_id": "<ad_id>"
    },
    "name": "refresh_ad_category_attributes"
  }
}

Input Schema

Name	Required	Description	Default
`ad_id`	Yes
`project_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 1, 2026

TDQS

A4.4/5.0

Behavior3/5

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

Goes well beyond annotations by disclosing the live channel call, integration rebuild, return payload shape, the need to re-export/submit afterwards, and the non-obvious 'warming' success state with polling instructions. That said, some of this is arguably required rather than additive given openWorldHint=true and readOnlyHint=false, and the description does not clarify permissions or side effects on previously mapped attributes.

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 the core action and the key ordering constraint (run after category mapping), then the return shape, then the warmup caveat. Dense and dash-heavy with some redundancy around where attributes appear, but nearly every sentence carries operative information an agent needs.

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?

No output schema exists, yet the description enumerates the returned fields and the alternate status:'warming' payload, and it covers the full follow-up workflow (poll ad_status, map attributes, re-export/submit). For a two-parameter, open-world mutation this is complete enough to invoke correctly without experimentation.

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 description coverage is 0%, so the description must compensate, and it does: ad_id is sourced from list_ads and project_id is marked OPTIONAL with the project_id_required fallback to list_projects. It adds meaning beyond the bare integer types, though it gives no format/range detail (left to the schema's exclusiveMinimum).

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?

States a specific verb (refresh/fetch) and resource (ad category attributes), equates it to the known wizard action 'Update Category Attributes', and distinguishes it from the read-only sibling get_ad_attributes by explaining it also rebuilds the integration. An agent can tell exactly what this does versus get_ad_attributes or refresh_marketplace_category_attributes.

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?

Explicit about when to call it: after configuring category mapping, so channel-specific required attributes surface in get_ad_attributes, then map them with map_ad_attribute. It also names the alternative path for missing project_id (project_id_required → list_projects) and gives a precise re-invocation rule (only if ad_status reports 'failed').

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?