Skip to main content
Glama

List calendar topics

list_calendar_topics
Read-only

Lists a site’s content calendar topics, ordered by scheduled day: title, scheduled day, review status, article generation and publishing state, the primary keyword with its search volume, difficulty and demand trend, and the planning fields (intent, funnel stage, audience, angles, author override). The scheduled day controls when the daily automation writes the article and, with automatic publishing on, publishes it. Without from and to, returns every topic; give both to read only the topics scheduled on those days (UTC, both included), such as one month. Topics without a scheduled day are only in the full list. Returns up to rowLimit topics a call: page through the rest with startRow and nextStartRow. Pass topicId to read only that topic, without from, to, startRow and rowLimit. When the workspace can open only some topics for now, returns only those, with lockedTopicCount for the others: the first 10 topics scheduled in the workspace’s first month until one of them has an article, then only that topic; another topicId answers topic_not_in_plan. Makes no external calls.

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": {
      "projectId": "<projectId>"
    },
    "name": "list_calendar_topics"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoLast scheduled day, YYYY-MM-DD (UTC), included. Give it with from.
fromNoFirst scheduled day, YYYY-MM-DD (UTC). Give it with to.
topicIdNoRead only this topic, from an earlier list.
rowLimitNoMost topics to return in this call. Defaults to 50.
startRowNoTopics to skip: nextStartRow from the previous page. Defaults to 0.
projectIdYesSite to act on, from list_sites.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare readOnly/no-destructive/no-open-world; the description adds substantial context beyond that: ordering by scheduled day, that the day drives the daily automation and auto-publishing, that topics without a day appear only in the full list, pagination behavior, and that no external calls are made. It also discloses the non-obvious plan-lock behavior and the topic_not_in_plan error condition.

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?

Content is front-loaded with purpose, then scoping, then paging, then the plan-lock edge case, and every sentence carries information. The sentences are long and densely packed with parentheticals, which costs a little readability, but little is wasted.

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?

No output schema exists, so the description must cover return values, and it names the key returned fields and nextStartRow/lockedTopicCount. Given six parameters with built-in descriptions and read-only annotations, an agent has everything needed to call this correctly and interpret the result.

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?

Although schema coverage is 100%, the description adds cross-parameter meaning the schema cannot express: from and to must be given together, topicId is exclusive of from/to/startRow/rowLimit, and the date window is UTC with both endpoints included. That is real semantic value for correct invocation, not repetition.

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?

Opens with a specific verb and resource ('Lists a site's content calendar topics, ordered by scheduled day') and then enumerates the fields returned, so an agent knows exactly what this tool yields without opening the schema. It is clearly distinguishable from mutation siblings like create_calendar_topic and update_calendar_topic.

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?

Gives concrete invocation guidance: omit from/to for the full list, pass both for a bounded window, use topicId for a single topic, and page with startRow/nextStartRow. It does not name a sibling alternative (e.g. get_content_calendar_progress) or state when another tool should be preferred, so it stops short of full routing guidance.

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