Skip to main content
Glama
Sign In

Keytomic

by com.keytomic.app
OverviewDiscussionsAdmin

Get draft

get_draft
Read-only

Returns the article Keytomic wrote for a content calendar topic of a site: the newest draft of the topic, with its title, slug, summary, SEO title and description, the full text as Markdown, the hero image, the word count, the publication status with the published URL, the topic’s primary keyword and scheduled day, the author saved on the article, whether this connection can edit the article, the SERP Snapshot: the top Google results for the topic’s keyword and market when the brief was written (keyword, market, check time, and each result’s rank, title, URL, domain, and whether it is on the site’s own domain), or null when none was saved, and structuredData: the structured data (JSON-LD) of the article, as Content Studio shows it. structuredData has the owner’s Structured Data Edit (edit, or null), the JSON-LD that a publish sends (sent: Keytomic’s, with the edit on top), Keytomic’s JSON-LD with no edit (keytomic), the publishing destination of the read, and liveUpdate: when a structured data save with update_draft reaches the live post. on_save: the save sends it to the live WordPress post. next_publish: the next publish of the article sends it. other_article: a newer article, such as a content refresh, publishes the post, so the edit does not reach it. seoPluginCanOverride is true for a WordPress post that Keytomic imported: when the site runs Yoast SEO, Rank Math, All in One SEO, SEOPress or The SEO Framework, the page shows that plugin’s schema instead of the structured data that Keytomic sends, so never tell the user that the live page has it. Name destinationId from the destinations section of get_project; without it, the read uses the site’s only active destination, else none, and then destination and liveUpdate are null. structuredData is null when the article cannot be published yet, for example when its text is empty. To change it, send the whole edit with update_draft just after this read: the last save wins. Only WordPress gets structured data from Keytomic. A topic without an article answers draft_not_found. When the workspace can open only some topics for now, only those can be read (see list_calendar_topics); others answer 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>",
      "topicId": "<topicId>"
    },
    "name": "get_draft"
  }
}

Input Schema

NameRequiredDescriptionDefault
topicIdYesTopic whose article to read, from list_calendar_topics.
projectIdYesSite to act on, from list_sites.
destinationIdNoPublishing destination whose structured data to show, from the destinations section of get_project. Leave it out to use the site’s only active destination.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnlyHint/openWorldHint=false annotations, the description discloses fallback behavior (no destinationId means the site's only active destination, else destination and liveUpdate are null), plan gating (only some topics readable, others return topic_not_in_plan), a strong correctness warning that seoPluginCanOverride means the live page may show a plugin's schema and 'never tell the user that the live page has it', and liveUpdate semantics (on_save/next_publish/other_article). It even states 'Makes no external calls,' which corroborates the closed-world annotation.

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 purpose is front-loaded, but the body is a single sprawling run-on sentence that enumerates return fields with nested colons and parentheticals, which makes it hard to scan. Given there is no output schema, most of that field inventory earns its place, yet the dense packing and buried critical caveats (seoPluginCanOverride, destination fallback) cost readability.

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 returns, and it does so exhaustively down to nested structuredData and liveUpdate outcomes. It also covers error responses, permission/plan limits, and destination resolution, leaving nothing an agent needs in order to call it correctly.

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 the baseline is 3, but the description adds consequences the schema does not carry: omitting destinationId falls back to the sole active destination and otherwise makes destination and liveUpdate null. It also ties topicId to the draft_not_found outcome and projectId to the site scope. This is meaningful added semantics rather than restatement.

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 clause states a specific verb and resource with scope: 'Returns the article Keytomic wrote for a content calendar topic of a site: the newest draft of the topic.' It immediately pins down 'newest draft' versus other article versions and names the sibling resources used to obtain inputs (get_project, list_calendar_topics), so an agent can separate it from update_draft, publish_draft, and the other getters.

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 a concrete sibling hand-off: 'To change it, send the whole edit with update_draft just after this read: the last save wins,' which tells the agent the read-before-write pattern. It also sets preconditions (destinationId from get_project) and failure modes (draft_not_found, topic_not_in_plan). What is missing is an explicit statement of when to prefer this over a general project/topic listing, so it is clear context without exclusions.

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

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