Skip to main content
Glama

devtune_get_action_draft

Read-onlyIdempotent

Get an action's content draft, for accounts with content drafts. draftKind is the draft the action takes now: page (the Page Drafter writes a whole new page for a create action) or section_edits (the Section Editor writes a change list for a refresh action), with agentKey naming the agent; both are null for an action that takes no draft. briefState says whether its brief is ready (outdated: written before the current brief format, so it must be regenerated to draft), and targetPage, for section edits, is the page edited (the action's own target, else its ready brief's page on an owned domain), whether it is locked, and briefRecommendedUrl when the brief recommends a different page. models lists the models a run can use with each one's per-run credit estimate. run is the draft run in flight, or the last one that ended without a draft. versions lists the current draft and up to 10 earlier versions, newest first: each has its draftKind, title, contentMarkdown (the page, or the change list rendered as markdown), changeList for section edits (each change's heading, current text, proposed text and reason), status (current for the draft the action shows, superseded otherwise), timestamps, briefId and runId, and factCheck: its status (checked, partial or unavailable), the sentences still flagged, each with its reason (unsupported or contradicted by the customer's own site, not_in_brief: a product fact the brief's facts list does not state, with siteJudgment saying whether the site states it, contradicted_by_source: a claim about another product that an external fact on the brief's facts list contradicts, with that fact as the brief words it and the source it cites, or competitor_link: the sentence links to one of the project's configured competitors, with the link in linkUrl) and the pages it was judged against and any contradicting quote, how many were flagged before and after the agent's fix pass, and coverage: how many sentences the check reviewed as possible claims (questions and short fragments are not counted), and of those how many were settled (restated from the brief's facts list, judged against the site, or contradicted by a source on the brief's facts list), unsettled, not checked, third-party claims (about another product, company, standard or source) read but not verified (notVerified), set aside as guidance, examples, headings or opinion, or marked [Needs source], with hasGap true when any were not judged and settled. current is the current version. pullRequest, for accounts with content pull requests, is the pull request opened from the draft (state opening, open, merged, closed or failed, with number, url, repository, branch, filePath, the draftId it carries, trigger (auto when DevTune opened it for a new draft because the content source has automatic pull requests on) and any failure, whose code for an automatic attempt can also be source_needs_reconnect, file_not_found (filePath null), file_exists or draft_does_not_match_source, and checkedAt, when DevTune last read a GitBook change request in GitBook), or null. Drafts are never published by DevTune.

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": {
      "actionId": "<actionId>"
    },
    "name": "devtune_get_action_draft"
  }
}

Input Schema

NameRequiredDescriptionDefault
actionIdYesUUID of the action.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already establish this as a safe, idempotent read, so credit goes to what the text adds: entitlement gating (accounts with content drafts, accounts with content pull requests), the meaning of an in-flight vs. ended run, pull request lifecycle states and failure codes, and the closing guarantee that "Drafts are never published by DevTune." Those are real behavioral facts not present in the annotations or schema.

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?

Purpose is front-loaded in the first clause, and most of the length is substantive because no output schema exists. However, the body degenerates into chained clauses and deeply nested parentheticals (factCheck reasons, pull request failure codes) that make the payload hard to scan and would benefit from enumeration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and full annotation coverage, this tool's completeness burden is the return shape, and the description documents nearly every field: versions, changeList, factCheck with reasons and coverage counts, current version, and pullRequest. Gaps are minor: no handling for an invalid or missing actionId, and no guidance on the relationship to the sibling tools that create or advance drafts.

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% for the single actionId parameter, so the structured field already does the work and the baseline of 3 applies. The description adds no syntax, sourcing, or lookup guidance for actionId, but none is needed beyond what the schema states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource: "Get an action's content draft," and qualifies scope with "for accounts with content drafts." It never names or distinguishes itself from close siblings such as devtune_get_action_brief or devtune_start_action_draft, so an agent must infer the boundary from surrounding context.

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

Usage Guidelines2/5

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

There is no explicit when-to-use or when-not-to-use statement, and no sibling is named as an alternative. The only workflow hint is buried mid-text ("outdated: written before the current brief format, so it must be regenerated to draft"), which implies a relationship to generate_action_brief/start_action_draft but leaves the agent to derive it.

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