Skip to main content
Glama

Publish Advertisement

publish_advertisement
Destructive

Publish a advertisement (advertisement_id or advertisement_uuid): sets it to PUBLISH and clears its slug page cache and the published websites' list caches. Scoped to the caller's merchant.

Input Schema

NameRequiredDescriptionDefault
advertisement_idNo
advertisement_uuidNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds real value beyond them by disclosing the side effects: the status flip to PUBLISH plus invalidation of the ad's slug page cache and published websites' list caches, and that it is merchant-scoped. It still does not say whether re-publishing an already-published ad errors or is a no-op, which matters given idempotentHint=false.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence that names the resource, the identifiers, the resulting state, and the cache effects with no filler. Minor grammar slip ('a advertisement') does not cost clarity.

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 a destructive mutation with no output schema, the description covers the state change, side effects, and scoping, which is the important part. Gaps remain around error/precondition behavior for already-published ads and whether both identifiers may be passed, leaving the agent short of what it needs to call with confidence.

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% and neither parameter is required, so the schema alone leaves the agent guessing. The description does compensate partly by naming both identifiers and implying an either/or selection, but it adds no format or precedence detail (e.g., which wins if both are supplied).

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?

The description gives a specific verb (publish) and resource (advertisement), plus the concrete state change to PUBLISH. It is distinguishable from siblings like edit_advertisement or activate_ads_campaign by that state transition, though it does not explicitly name an alternative to contrast against.

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?

It implies when to call by describing the publish action and the merchant scoping, and it clarifies that either advertisement_id or advertisement_uuid selects the target. However, there is no explicit guidance on when to prefer this over edit_advertisement, nor any exclusion such as behavior for already-published ads.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources