Keytomic

Update calendar topic

update_calendar_topic

DestructiveIdempotent

Saves edits to one content calendar topic of a site, the same as editing it in the Calendar. Send only the fields to change; the others keep their values. The scheduled day controls when the daily automation writes the article and, with automatic publishing on, when Keytomic publishes it. The automation writes articles only on the site’s automation days (the settings section of get_project lists them), one topic without an article a day, so a topic on another day gets no article. The review status is a label and does not change the automation. A topic that has an article, or whose article is being written, cannot be edited (topic_has_article). When the workspace can open only some topics for now, only those can be edited (topic_not_in_plan). The primary keyword, the keyword metrics and the article stay as they are. Returns the updated topic. Spends no credits.

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>",
      "topicId": "<topicId>"
    },
    "name": "update_calendar_topic"
  }
}

Input Schema

Name	Required	Description
`slug`	No	URL slug for the article, such as how-to-bake-sourdough. null clears it.
`title`	No	The topic title, which becomes the article title.
`intent`	No	Search intent the article answers.
`status`	No	Review status of the topic: pending, approved or needs_revision. It is a label for the team that the Calendar does not show; the daily automation does not read it and writes the article on its scheduled day for every status.
`topicId`	Yes	Topic to edit, from list_calendar_topics.
`blogType`	No	Article type, such as listicle, how_to or direct_answer. null clears it.
`entities`	No	People, products, places and concepts the article names. Replaces the whole list.
`projectId`	Yes	Site to act on, from list_sites.
`funnelStage`	No	Funnel stage the article serves.
`scheduledDay`	No	Scheduled day, YYYY-MM-DD, as the Calendar shows it (UTC). On this day the daily automation writes the article and, with automatic publishing on, publishes it. Pick tomorrow (UTC) or a later day: the automation writes each day’s article at 00:00 UTC and never goes back to a past day. null removes the day, so the automation does not write the article until a day is set again.
`targetAudience`	No	Readers the article is for. null clears it.
`topicalCluster`	No	Topic group the article belongs to. null clears it.
`aiCitationAngle`	No	What makes the article worth citing in AI answers. null clears it.
`authorProfileId`	No	Author of this article, from the settings section of get_project. null removes the override, so the site’s default author applies.
`secondaryKeywords`	No	Keywords the article also covers, besides the primary keyword. Replaces the whole list.
`businessValueAngle`	No	How the article helps the business. null clears it.
`customInstructions`	No	Instructions the writer follows for this article only, up to 1000 characters. null clears them.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the annotations it discloses partial-update semantics ("Send only the fields to change"), the automation timing model (articles written at 00:00 UTC on automation days, one per day, never retroactively), the fact that review status is a mere label, and that the call costs no credits. It also states the return value, all of which the annotations cannot convey.

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?

Purpose and partial-update rule are front-loaded, then constraints, then cost. A few sentences duplicate schema text (the status label explanation appears twice across description and schema), and the automation-day paragraph is dense but each sentence carries non-obvious behavior.

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 17 parameters, mutation semantics, and no output schema, the description covers what an agent needs: partial update behavior, blocking error conditions, automation timing effects, the return value, and cost. Nothing material for correct invocation is missing.

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 100%, and most of the interactive meaning (scheduledDay vs automation days, status being a non-functional label) is already written into the schema property descriptions, so the prose largely restates it. It adds only limited new parameter guidance beyond the schema, which matches the baseline for full coverage.

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 names a specific verb and resource ("Saves edits to one content calendar topic of a site") and grounds it in a user-facing action ("the same as editing it in the Calendar"). It also separates itself from the draft-editing sibling by stating "The primary keyword, the keyword metrics and the article stay as they are."

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?

The description gives concrete when-not conditions with the exact error identifiers: a topic with an article or one being written cannot be edited (topic_has_article), and plan-restricted topics cannot be edited (topic_not_in_plan). It does not name an alternative tool to use when those blocks apply, which is the only gap.

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

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