Skip to main content
Glama
Sign In

DevTune MCP

by ai.devtune
OverviewDiscussionsAdmin

devtune_create_draft_pull_request

DestructiveIdempotent

Open a pull request on the customer's content repo, or a change request in their GitBook space, from an action's current content draft, for accounts with content pull requests, as the member who created the API key or authorized this connection; they must manage this project. The page belongs to the content source with the longest matching URL prefix (see devtune_get_content_sources), and the source's provider decides which. A refresh draft's section edits are applied to the page: each change's current text is replaced, matched after collapsing whitespace, and each new section is added after its heading. If any change does not match, nothing is written and the refusal is draft_does_not_match_source with the change numbers. A create draft becomes a new page named from the brief's target. On GitHub, DevTune commits to its own branch, devtune/action-, and opens the pull request. On GitBook, DevTune opens a change request whose description names who approved the draft, writes the page, and checks GitBook stored it as written (page_not_preserved if not). DevTune never merges either. One per action: calling again with a newer draft updates the open one. Pass draftId (the current version from devtune_get_action_draft) so a draft replaced meanwhile is refused with draft_not_latest. When no source covers the page, the refusal is no_content_source with details.sources; retry with sourceId. When the page is not found, the refusal is file_not_found with details.tried; retry with filePath (GitHub) or pagePath (GitBook). Other refusals: unavailable, no_draft, action_closed (live or archived), page_locked, source_needs_reconnect, invalid_file_path, file_exists, branch_diverged (someone else pushed to DevTune's branch; DevTune leaves their commits alone), change_request_diverged (someone else edited the change request; DevTune leaves their edits alone), change_request_conflicts (the change request has conflicts in GitBook), page_not_preserved, pull_request_in_progress, pull_request_merged, github_error and gitbook_error (details.detail is rate_limited when GitBook's rate limit for the connection is used up, recovery_incomplete when DevTune could not finish looking for a change request an earlier attempt may have opened, or recovery_stale when another attempt for the action finished while this one started; retry later). Returns the pull request: provider, state, number, url, repository and branch (GitHub) or space (GitBook), filePath (the GitBook page path for GitBook), draftId, updateFailure (a failed update beside an open change request), checkedAt (when DevTune last read a GitBook change request in GitBook; null for GitHub) and timestamps.

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_create_draft_pull_request"
  }
}

Input Schema

NameRequiredDescriptionDefault
draftIdNoThe current draft version id from devtune_get_action_draft; refused if a newer draft replaced it.
actionIdYesUUID of the action.
filePathNoThe repo file to edit or create, under the source's folder, when DevTune cannot find or name it. GitHub sources only.
pagePathNoThe GitBook page path to edit or create, below the space root, such as guides/quickstart, when DevTune cannot find or name it. GitBook sources only.
sourceIdNoA content source id from devtune_get_content_sources, for a page no source covers.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / filePath / description
      Previous value: -"The repo file to edit or create, under the source's folder, when DevTune cannot find or name it."New value: +"The repo file to edit or create, under the source's folder, when DevTune cannot find or name it. GitHub sources only."
    • addedInput schema / properties / pagePath
      Added value: +{
+  "description": "The GitBook page path to edit or create, below the space root, such as guides/quickstart, when DevTune cannot find or name it. GitBook sources only.",
+  "maxLength": 1000,
+  "minLength": 1,
+  "type": "string"
+}
  2. Added

TDQS

A4.5/5.0
Behavior5/5

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

Goes far beyond the supplied annotations: it discloses that DevTune never merges, commits to branch devtune/action-<id>, enforces one PR per action with re-calls updating the open one (matching idempotentHint), and that a failed match writes nothing. It documents divergence handling (branch_diverged, change_request_diverged), rate-limit states, and destructive scope (replacing current text, adding sections) in concrete terms.

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 and auth prerequisites are front-loaded, which is good, but the body becomes a single dense paragraph that exhausts roughly twenty refusal codes in one run-on sentence. Much of that detail is genuinely useful, yet a bulleted error list would scan far better, and low-level implementation notes (whitespace collapsing) sit at the same level as critical warnings.

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?

For a destructive, open-world, one-per-action mutation with no output schema, the description covers return shape (provider, state, number, url, repository/branch or space, filePath, draftId, updateFailure, checkedAt), partial-failure signaling via updateFailure, and recovery for nearly every refusal. Nothing essential to calling it safely 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?

With 100% schema coverage the schema already defines all five parameters, so the baseline is 3; the description earns above baseline by explaining the failure semantics each optional parameter resolves — draftId refused as draft_not_latest, sourceId needed on no_content_source, filePath/pagePath needed on file_not_found with a provider split. That is meaning the schema does not carry.

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+resource: "Open a pull request on the customer's content repo, or a change request in their GitBook space, from an action's current content draft." It names the input origin (an action's draft) and the two provider variants, which clearly separates it from siblings like devtune_close_draft_pull_request.

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?

States prerequisites explicitly (accounts with content pull requests, the API-key creator or authorizing member, and they must manage the project) and routes the agent to devtune_get_action_draft for draftId and devtune_get_content_sources for unresolved sources. It also gives concrete retry paths (sourceId, filePath, pagePath). It never says when NOT to call it, e.g. that devtune_close_draft_pull_request is the reverse operation, so it stops short of a 5.

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

All DevTune MCP 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