Keytomic

Generate article

generate_article

Writes the article of one content calendar topic of a site, the same as Generate in the Calendar and the daily automation. Without confirm, returns the plan and starts nothing (status plan): the articles used and left this month and today, the Article Credits, and whether the article uses an Article Credit because the month limit is reached. Show the plan to the user, and call again with confirm: true only after the user agrees; when the plan uses an Article Credit, add useArticleCredit: true. With confirm: true, reads the plan again and starts the article (status generating). When the plan read again uses an Article Credit and the call has no useArticleCredit: true, it returns the plan (status plan) and starts nothing. Keytomic writes it in a few minutes: follow it with list_calendar_topics with topicId (generationStatus), and read it with get_draft when it is ready. The article counts when Keytomic saves the draft. When the topic cannot get an article now, both calls answer a tool error and use nothing: a topic with an article (topic_has_article), a topic whose article Keytomic writes now (topic_generation_in_progress), a topic the workspace cannot open (topic_not_in_plan), or a usage limit. The site needs saved Image Studio settings.

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": "generate_article"
  }
}

Input Schema

Name	Required	Description
`confirm`	No	true starts the article. Send it only after the user saw the plan this tool returns without confirm and agreed. Without it, the tool returns the plan and starts nothing.
`topicId`	Yes	Topic whose article to write, from list_calendar_topics.
`projectId`	Yes	Site to act on, from list_sites.
`useArticleCredit`	No	true agrees that the article uses 1 Article Credit. Send it with confirm: true only when the plan says that the article uses an Article Credit and the user agreed. Without it, a start that uses an Article Credit returns the plan and starts nothing.

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=false, destructive=false, idempotent=false, openWorld=true; the description adds the details that actually matter: the call is a dry-run by default, a confirmed call consumes an Article Credit under a month-limit condition, the article counts only when Keytomic saves the draft, generation takes minutes, and failed preconditions consume nothing. The non-idempotent annotation is also explained via the re-read of the plan on the confirm call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core action and the confirm gate are front-loaded, which is right, but the 'returns the plan and starts nothing' outcome is restated three separate times and the credit rule is explained twice in near-identical wording. The density is defensible for a two-phase billing-gated tool, yet tightening would cut roughly a quarter of the text without losing any rule.

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, no enums, and four parameters, the description has to carry the whole contract, and it does: state transitions (plan → generating), credit accounting, error taxonomy, follow-up tools for polling and retrieval, and the prerequisite of saved Image Studio settings. Nothing an agent needs to call this correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so baseline would be 3, but the description goes further by explaining the cross-parameter contract: useArticleCredit: true must be sent alongside confirm: true and only when the plan says a credit is used, otherwise the call degrades back to a plan response. That conditional dependency between two booleans is meaning the schema alone does not convey.

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 ('Writes the article of one content calendar topic of a site') and anchors it to user-visible equivalents ('the same as Generate in the Calendar and the daily automation'). It also names the sibling tools involved in the workflow (list_calendar_topics, get_draft), so an agent can place it in the pipeline without opening any other definition.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit two-step protocol: call without confirm first, show the plan to the user, then call again with confirm: true only after agreement. It also names the exact conditions that should stop the agent (plan uses an Article Credit, topic_has_article, topic_generation_in_progress, topic_not_in_plan, usage limit), which is about as far from inference as guidelines get.

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?