Skip to main content
Glama
Pinterest Ads MCP Server

Pinterest Ads MCP Server

Change catalog items in a batch

pinterest_ads_batch_catalog_items
Destructive

Create, update, upsert, or delete up to 1,000 Pinterest catalog items in one batch, with confirmation guards for bulk and delete actions, then return a batch ID for status tracking.

Instructions

Create, update, upsert or delete catalog items in one batch (up to 1000).

operation: CREATE, UPDATE (change some attributes), UPSERT (send every attribute) or DELETE. items: [{"item_id": "SKU1", "attributes": {"price": "24.99 GBP", "availability": "in stock"}}]; DELETE needs only item_id. If a feed manages the catalog, Pinterest recommends changing items through the feed. DELETE needs confirm='DELETE'; more than PINTEREST_ADS_BULK_THRESHOLD items need confirm='APPLY'. Returns a batch_id to check with pinterest_ads_get_catalog_items_batch.

Input Schema

NameRequiredDescriptionDefault
itemsYes
confirmNo
countryYes
languageYes
operationYes
catalog_idNo
catalog_typeNoRETAIL
ad_account_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already flag destructive and non-idempotent, and the description adds materially: the 1000-item cap, the confirm='DELETE' requirement for deletions, the confirm='APPLY' requirement above PINTEREST_ADS_BULK_THRESHOLD, and that the call is asynchronous, returning a batch_id to poll with pinterest_ads_get_catalog_items_batch. That is real behavioral context an agent cannot get from the 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?

Dense and front-loaded — verbs and cap first, then the item shape, then the feed caveat, then the confirm gates, then the return value. Nothing is filler, though the trailing fragment about the return value reads as tacked on rather than integrated.

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?

For an eight-parameter, destructive, non-idempotent batch mutation with no output schema and 0% schema description coverage, key gaps remain: the roles of catalog_id vs ad_account_id, what catalog_type defaults to and affects, and what country/language constrain. The operational and confirmation story is complete; the parameter story is not.

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 0%, so the description must carry the load. It does well on operation, items (with a concrete example object and the note that DELETE needs only item_id) and confirm, but country, language, catalog_id, catalog_type and ad_account_id get no explanation at all, leaving five of eight parameters undocumented anywhere.

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 opens with a specific verb set and resource: create/update/upsert/delete catalog items in a batch, with a size ceiling of 1000. That distinguishes it from list/get siblings such as pinterest_ads_get_catalog_items and from the feed-based pinterest_ads_ingest_catalog_feed path.

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?

It spells out the four operations and what each means in practice (UPDATE changes some attributes, UPSERT sends every attribute), and it names an explicit alternative: if a feed manages the catalog, change items through the feed instead. The confirm gates tell the agent the exact conditions required before a destructive or bulk apply proceeds.

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