Agent Data API

content_month_plan

Idempotent

Plan a content month for an agency: up to 30 posts with topics, publish dates and linked production dates, bundled shoot days, holidays per region, conflicts and an .ics file. EN/DE. Returns: JSON with language, plan_id, period, today, summary, posts, shoot_days, conflicts, warnings, posts_for_reschedule, next_step, holiday_region, holidays, calendar_file_ics, coverage. PAID: 0.05 USDC per call (USDC on eip155:8453, x402 v2). Requires an x402-capable MCP client that attaches the payment in _meta["x402/payment"] (e.g. createx402MCPClient from @x402/mcp). Without a payment this tool returns a "payment required" result and charges nothing. NOTE: Rule-based, German or English (language), no AI model, stateless. Send periods, counts, weekdays and your already booked dates only, no personal data. Topics are suggestions from built-in recipes, not a content strategy. Nothing is written to any calendar; the .ics text is yours to import.

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": {
      "from": "<from>",
      "to": "<to>"
    },
    "name": "content_month_plan"
  }
}

Input Schema

Name	Required	Description	Default
`to`	Yes	At most 62 days after from.
`from`	Yes
`seed`	No
`today`	No
`language`	No	de (default) or en	de
`categories`	No
`media_type`	No
`mix_counts`	No	Posts per category; overrides posts_per_week and categories.
`start_time`	No		09:00
`break_minutes`	No
`lunch_minutes`	No
`phase_offsets`	No	Days before publish.
`avoid_weekends`	No
`holiday_region`	No		none
`posts_per_week`	No
`max_day_minutes`	No
`publish_weekdays`	No
`max_shoots_per_day`	No
`min_shoot_lead_days`	No
`production_weekdays`	No
`existing_shoot_dates`	No	Shoot days already booked.
`existing_publish_dates`	No	Publish dates already taken.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 24, 2026

removedInput schema / properties / categories / description
```
Removed value: -"Topic categories, shared evenly."
```

addedInput schema / properties / holiday_region

Added value: +{
+  "default": "none",
+  "enum": [
+    "none",
+    "DE-BW",
+    "DE-BY",
+    "DE-BE",
+    "DE-BB",
+    "DE-HB",
+    "DE-HH",
+    "DE-HE",
+    "DE-MV",
+    "DE-NI",
+    "DE-NW",
+    "DE-RP",
+    "DE-SL",
+    "DE-SN",
+    "DE-ST",
+    "DE-SH",
+    "DE-TH",
+    "AT",
+    "CH"
+  ],
+  "type": "string"
+}

removedInput schema / properties / today / description

Removed value: -"Reference date, default today (Germany)."

Changed1 schema field changedOct 24, 2026

addedInput schema / properties / language

Added value: +{
+  "default": "de",
+  "description": "de (default) or en",
+  "enum": [
+    "de",
+    "en"
+  ],
+  "type": "string"
+}

AddedOct 24, 2026

TDQS

A3.6/5.0

Behavior5/5

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

The description discloses substantial behavior beyond the annotations: it is paid (0.05 USDC via x402), requires an x402-capable client, returns a payment-required result without payment, is rule-based and stateless, does not write to any calendar, and is EN/DE. These details tell the agent about cost, authentication/payment prerequisites, side effects, and determinism in a way the annotations alone do not.

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?

The description is dense and front-loaded, beginning with the core purpose and then covering outputs, payment, and constraints. The output field list is justified because there is no output schema, though the payment and prerequisite wording could be tightened slightly.

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 complex 22-parameter planning tool with no output schema, the description covers purpose, outputs, payment, statelessness, privacy, and calendar behavior well. However, it leaves many parameters undocumented despite low schema description coverage, so an agent still lacks enough semantic guidance to invoke the tool precisely.

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

Parameters2/5

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

With 22 parameters and only 27% schema description coverage, the description needs to compensate but mostly does not. It gives a high-level hint to 'Send periods, counts, weekdays and your already booked dates only' and lists output fields, but it does not explain the semantics of seed, today, start_time, break_minutes, lunch_minutes, phase_offsets, max_day_minutes, max_shoots_per_day, or min_shoot_lead_days.

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 clearly states a specific verb and resource: 'Plan a content month for an agency' with posts, topics, publish dates, shoot days, holidays, conflicts, and an .ics file. The month-level scope and output summary make it easy to distinguish from atomic tools, though it never names the closest sibling alternatives such as shoot_day_plan or content_plan_shift.

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 context is implied by 'Plan a content month for an agency' and by the note to send only periods, counts, weekdays, and booked dates. The description also limits expectations ('Topics are suggestions from built-in recipes, not a content strategy' and 'Nothing is written to any calendar'), but it does not explicitly say when to use this tool instead of content_plan_shift, shoot_day_plan, or video_project_plan.

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

All Agent Data API 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?