AdCopilot

Google Ads: add ad schedule

set_ad_schedule

Destructive

ADDS ad schedule windows to a campaign; its existing windows stay.

This never replaces a schedule: the windows the campaign already has are
left as they are. A campaign with no schedule serves at all hours, and
its first windows narrow it to them; on a campaign that already has
windows, an added one widens when ads show rather than narrowing it.
Narrowing an existing schedule needs windows removed in Google Ads
(Campaign → Ad schedule), which this server never does, so tell the user
the old windows stay until they remove them there.

Controls which days and hours ads are shown.

Args:
    customer_id: The Google Ads customer ID.
    campaign_id: The ID of the campaign.
    schedules: List of schedule objects, each with:
        - day_of_week: One of MONDAY, TUESDAY, WEDNESDAY,
            THURSDAY, FRIDAY, SATURDAY, SUNDAY.
        - start_hour: Start hour (0-23).
        - start_minute: One of ZERO, FIFTEEN, THIRTY,
            FORTY_FIVE. Default: ZERO.
        - end_hour: End hour (0-23). Use 24 for midnight.
        - end_minute: One of ZERO, FIFTEEN, THIRTY,
            FORTY_FIVE. Default: ZERO.

Returns:
    Dictionary with created schedule criteria.

Tools revision: d80f65c0.

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": {
      "customer_id": "<customer_id>",
      "campaign_id": "<campaign_id>",
      "schedules": "<schedules>"
    },
    "name": "set_ad_schedule"
  }
}

Input Schema

Name	Required	Description	Default
`schedules`	Yes
`campaign_id`	Yes
`customer_id`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only say destructiveHint=true and idempotentHint=false; the description carries the real behavioral payload – additions never replace, an unscheduled campaign is narrowed by its first windows, later additions widen serving, and removals are impossible via this server. The explicit instruction to tell the user the old windows persist is exactly the disclosure a mutation tool needs. Nothing contradicts the destructive annotation; the narrowing case actually justifies it.

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 behavioral headline before the details, and the Args formatting is scannable. It loses a point for redundancy – 'its existing windows stay' is restated as 'This never replaces a schedule: the windows the campaign already has are left as they are' – plus a filler line ('Controls which days and hours ads are shown') that adds nothing.

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?

For a three-parameter mutating tool with an output schema present, everything an agent needs is covered: additive semantics, the no-schedule edge case, the irreversibility caveat and user messaging, and the full nested parameter contract. Return values are properly left to the output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the nested schedules array is typed only as generic objects, so the Args block is the sole source of the field contract: day_of_week enum values, start/end hour ranges, 'Use 24 for midnight', the ZERO/FIFTEEN/THIRTY/FORTY_FIVE minute enum, and the ZERO defaults. Without this text the tool would be uncallable on the most important parameter.

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 first line states a specific verb and resource ('ADDS ad schedule windows to a campaign') and immediately pins the scope boundary ('its existing windows stay'). The title and body agree, and an agent can distinguish this from unrelated campaign-mutation siblings like update_campaign or set_campaign_status without reading any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is explicit: this tool appends windows, a schedule-less campaign serves all hours and first windows narrow it, and narrowing an existing schedule is not possible here – the user must remove windows in the Google Ads UI. That is a genuine when-to-use/when-not-to-use signal. It stops short of only 5 because no sibling tool is named as an alternative path, though no obvious sibling exists.

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

All AdCopilot 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?