GBPly

Request a new evergreen campaign

request_create_evergreen_campaign

Destructive

Ask the user to approve a new evergreen library that rotates its posts on a schedule (each post at least 28 days apart). Starts paused unless start is true. Returns an approval link.

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": {
      "profile_id": "<profile_id>",
      "name": "<name>",
      "frequency": "<frequency>",
      "time": "<time>",
      "start_date": "<start_date>",
      "posts": "<posts>"
    },
    "name": "request_create_evergreen_campaign"
  }
}

Input Schema

Name	Required	Description
`name`	Yes
`time`	Yes	HH:mm in the business's own timezone.
`posts`	Yes	Starting library posts.
`start`	No	Start publishing straight away. Default false (paused).
`weekday`	No	ISO weekday for weekly/biweekly: 1=Mon … 7=Sun. Required for weekly/biweekly.
`frequency`	Yes	biweekly = every 2 weeks. Monthly/yearly repeat on the start date's day.
`profile_id`	Yes
`start_date`	Yes	YYYY-MM-DD, first possible date.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, openWorldHint=true, and idempotentHint=false, but the description adds genuinely new behavior: the call does not publish immediately, it produces an approval link for the user, and it starts paused unless 'start' is true. It still does not explain why the operation is destructive or what a later approval triggers, which would resolve the tension between 'ask the user to approve' and destructiveHint=true.

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?

Three short sentences, each carrying distinct information: what it is, the scheduling rule, the default state, and the return value. Nothing is wasted and the confirmation/approval framing is front-loaded.

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 an 8-parameter request tool with no output schema, the description covers the essential workflow (user approval, return value as a link, paused default) and one scheduling constraint. The remaining gap is routing guidance against sibling campaign-creation tools, which matters given how many similar siblings exist.

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 75%, so the schema already documents time, start, weekday, frequency, start_date, and key post fields. The description adds the only meaningful non-schema constraint (posts must be at least 28 days apart) and restates the 'start' default, but says nothing about the 1–20 post limit, the required weekly/biweekly weekday, or the image/CTA constraints.

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 states a specific verb and resource ('Ask the user to approve a new evergreen library') plus the defining behavior (posts rotate on a schedule, at least 28 days apart). It differentiates loosely from request_add_to_evergreen by emphasizing a NEW library, but never names that sibling explicitly, so an agent must infer the boundary.

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?

The phrase 'Ask the user to approve' implies this is the initiation step of an approval workflow, and 'Starts paused unless start is true' hints at a safe default. However, there is no explicit guidance on when to use this versus request_create_repeating_post, request_add_to_evergreen, or preview_campaign_dates, which are the most likely confusions.

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

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