Skip to main content
Glama
ghl-mcp-server-v2

ghl-mcp-server-v2

by zackscriven

ghl_ad_li_campaign_group_publish

Publish a LinkedIn ad campaign group to make it live by sending the required ad ID and location ID to the ad publishing endpoint.

Instructions

Publish ad campaign group Publish a LinkedIn ad campaign group and push it live Endpoint: POST /ad-publishing/linkedin/ads/{adId}/publish (Version header: v3; source: v3/ad-publishing-v3.json) OAuth scopes: adPublishing.write

Input Schema

NameRequiredDescriptionDefault
adIdYesAd identifier
bodyYesRequest body (schema carried verbatim from the official OpenAPI spec).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.1.0
    • addedInput schema / properties / body / title
      Added value: +"LocationIdBodyDTO"
  2. First observedv2.0.0

TDQS

B3.4/5.0
Behavior3/5

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

The description adds real context beyond annotations: the exact POST endpoint, version header, and required adPublishing.write scope. However, it does not say whether publishing is synchronous or async (sibling ghl_ad_fb_campaign_publishing_progress_get hints publish may be a job), what happens if the group is already published, or whether the operation can be reversed.

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

Conciseness3/5

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

Front-loaded and short, but the first two lines restate the same thing ('Publish ad campaign group' / 'Publish a LinkedIn ad campaign group and push it live'), and the endpoint/spec-source metadata is verbose boilerplate.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter mutation with annotations covering safety hints, the description supplies the endpoint, version, and OAuth scope, which is close to what an agent needs. The main remaining gap is the async/return behavior of the publish call.

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 coverage is 100% with both adId and the nested locationId described in the schema, so the baseline applies. The description adds no meaning about the adId/body relationship or what locationId controls in a publish call.

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?

States a specific verb and resource ('Publish a LinkedIn ad campaign group and push it live'), and the LinkedIn qualifier plus the publish verb separate it from siblings like ghl_ad_li_campaign_group_upsert and ghl_ad_fb_campaign_publish.

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?

Usage is only implied by 'push it live' and the OAuth scope line. There is no explicit when-to-use rule versus upsert (create/update the campaign group first?) or versus the reporting/progress siblings.

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