Skip to main content
Glama
Sign In

Keytomic

by com.keytomic.app
OverviewDiscussionsAdmin

Get publication status

get_publication_status
Read-only

Returns where the article of a content calendar topic was published: the latest publication for each mode (draft or publish) of each publishing destination of the site that has a publication of the article. Destinations without a publication are not listed. Each publication has its status (pending, succeeded or failed), the public URL on the destination (null for a draft-mode publication, which has no public URL), when it started and completed, and the destination’s destinationId, name and provider. A failed publication has a failureMessage and a fixUrl, where the owner checks the destination in 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_publication_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
topicIdYesTopic whose article to read, from list_calendar_topics.
projectIdYesSite to act on, from list_sites.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.2/5.0
Behavior5/5

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

Well beyond the annotations, which already cover read-only, non-destructive, closed-world behavior, the description discloses that destinations without a publication are omitted, that draft-mode publications carry a null public URL, that failures include failureMessage and fixUrl, and that it makes no external calls. It also documents two distinct error answers (draft_not_found, topic_not_in_plan) with the plan-gating condition behind the second.

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?

A single dense paragraph that front-loads what is returned and then layers in edge cases and error semantics; nearly every sentence carries information an agent would otherwise have to discover empirically. It is heavy but not padded.

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?

There is no output schema, and the description fully specifies the returned fields, the null-URL case, the failure fields, and the two error answers, which is exactly what an agent needs to interpret results. Nothing material is left unresolved for a two-parameter read tool.

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 both parameters are already documented in the schema as coming from list_calendar_topics and list_sites. The description only adds an implicit constraint on topicId (plan-restricted topics answer topic_not_in_plan), so it neither compensates for a gap nor adds much beyond the schema.

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?

States a specific verb and resource: it returns where the article of a calendar topic was published, and it defines the exact granularity (latest publication per mode per destination of the site). That level of specificity inherently separates it from siblings like get_draft or get_content_calendar_progress without needing to name them.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: the reader infers it is the post-generation status check, and the definition points to list_calendar_topics as the source of valid topic IDs. There is no explicit when-to-use/when-not-to-use guidance or named alternative, so an agent must reason about the fit itself.

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