Skip to main content
Glama

Get the content calendar

get_calendar
Read-onlyIdempotent

List planned social posts between from and to (YYYY-MM-DD, inclusive). Max 400 days. By default each post is a SUMMARY — id, date, scheduledAt (the instant it is due, ISO), timezone, localTime (the due time in that zone, e.g. "Mon 2 Nov, 18:00" — quote this to the owner), platform, format, status, the opening line (hook, up to 140 characters), hasMedia, and publishTargets (each account it is queued to, with its state: queued, claimed, published, failed, cancelled, needs_reconnect, needs_attention; empty means it is only a plan and will not publish). Pass detail: "full" for every field (caption, hashtags, YouTube title and description, media, cover…), best with a narrow range or a small limit. Pages: limit posts at a time (default 100 summaries, or 20 full posts); when next_cursor is not null, call again with cursor: next_cursor for the next page. total is the number of posts in the range.

Input Schema

NameRequiredDescriptionDefault
toYesEnd date YYYY-MM-DD
fromYesStart date YYYY-MM-DD
limitNoPosts per page. Default 100 summaries, or 20 full posts.
cursorNo`next_cursor` from the previous page.
detailNosummary (default): a few facts per post. full: every field.
brand_idNoBrand workspace id from list_brands
user_goalNoOptional: the user's goal behind this call, in one short sentence of plain words (e.g. "add a page so customers can book tables"). No names, emails or other personal details.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / user_goal
      Added value: +{
      +  "description": "Optional: the user's goal behind this call, in one short sentence of plain words (e.g. \"add a page so customers can book tables\"). No names, emails or other personal details.",
      +  "type": "string"
      +}
  2. Changed3 schema fields changed
    • addedInput schema / properties / cursor
      Added value: +{
      +  "description": "`next_cursor` from the previous page.",
      +  "maxLength": 12,
      +  "type": "string"
      +}
    • addedInput schema / properties / detail
      Added value: +{
      +  "description": "summary (default): a few facts per post. full: every field.",
      +  "enum": [
      +    "summary",
      +    "full"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / limit
      Added value: +{
      +  "description": "Posts per page. Default 100 summaries, or 20 full posts.",
      +  "maximum": 200,
      +  "minimum": 1,
      +  "type": "integer"
      +}
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed world), yet the description adds substantial behavior beyond them: the default summary payload shape, the heavier full payload, the 400-day cap, page-size defaults (100 summaries vs 20 full posts), and the meaning of an empty `publishTargets` (plan only, will not publish).

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 core operation, then progressively adds payload and paging detail; almost every sentence is informative. It is dense and long, with a lengthy enumeration of summary fields, but the density is mostly earned rather than padding.

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?

With no output schema, the description carries the full burden of explaining return values, and it does: it enumerates summary fields, describes the full-detail mode, documents pagination and `total`, and explains the empty-publishTargets case. An agent has everything needed to call and interpret it.

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 coverage is 100%, so the baseline would be 3, but the description meaningfully exceeds it: it explains date inclusivity and the 400-day ceiling not encoded in the schema, clarifies `detail` trade-offs, and describes the cursor round-trip using `next_cursor`, plus decoding `publishTargets` states and `total`.

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 opening sentence states a specific verb and resource ('List planned social posts') plus the exact scoping (between `from` and `to`, inclusive, max 400 days). This is clearly distinguishable from siblings like get_post_performance or list_content_drafts, which address different resources.

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?

It gives concrete usage context: when to use `detail: "full"` (best with a narrow range or small limit) and how to page with `cursor` when `next_cursor` is non-null. It does not name a specific alternative tool or an explicit 'do not use for X' case, so it falls short of a 5.

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