Skip to main content
Glama
milcho0604

velog-mcp

by milcho0604
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

발행글 수정

velog_update_post
Destructive

Update an already-published Velog post while keeping its publication status and any fields you omit unchanged. Specify only the values to modify—title, body, tags, URL slug, series, or thumbnail—and the rest stay as-is.

Instructions

이미 발행된 글을 수정한다. 발행 상태(is_temp:false)는 유지된다. 생략한 필드는 기존 값을 그대로 유지한다 — 초안 도구와 달리 전체 교체가 아니다. 초안 id 는 거부한다(초안 수정은 velog_update_draft). 현재 설정에서는 공개 범위를 바꿀 수단이 없다 — 공개 글은 공개로, 비공개 글은 비공개로 그대로 남는다. 범위를 바꾸려면 VELOG_ALLOW_PUBLIC=1 이 필요하다.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
bodyNo생략하면 기존 본문 유지. 문체: 사람이 쓴 글처럼 자연스럽게. 긴 줄표(—)와 가운뎃점(·)을 쓰지 말고 쉼표나 마침표로 끊을 것. "**하나.** ... **둘.**" 식 볼드 번호 나열 금지(산문이나 평범한 불릿으로). 문단은 2~3문장으로 짧게, 200자가 넘으면 쪼갠다. "이 글의 한계" 같은 부록 절을 만들지 말고 해당 문단 자리에 한 문장으로 녹일 것.
tagsNo생략하면 기존 태그 유지
titleNo글 제목. 긴 줄표(—) 금지. 부제는 콜론이나 괄호, 짧은 하이픈으로.
url_slugNo생략하면 기존 주소 유지
series_idNo
thumbnailNo썸네일 이미지 URL (http/https). 생략하면 본문 첫 이미지로 자동 설정한다. 자동 설정을 원하지 않으면 null 을 준다
series_nameNo시리즈 **이름**(id 대신). 저장 전에 내 시리즈에서 찾아 같은 요청에 실어 보낸다 — 한 번의 호출로 시리즈까지 붙는다. 못 찾으면 저장하지 않고 목록을 알려준다

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.9.2
    • changedInput schema / properties / body / description
      Previous value: -"생략하면 기존 본문 유지"New value: +"생략하면 기존 본문 유지. 문체: 사람이 쓴 글처럼 자연스럽게. 긴 줄표(—)와 가운뎃점(·)을 쓰지 말고 쉼표나 마침표로 끊을 것. \"**하나.** ... **둘.**\" 식 볼드 번호 나열 금지(산문이나 평범한 불릿으로). 문단은 2~3문장으로 짧게, 200자가 넘으면 쪼갠다. \"이 글의 한계\" 같은 부록 절을 만들지 말고 해당 문단 자리에 한 문장으로 녹일 것."
    • removedInput schema / properties / thumbnail / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • addedInput schema / properties / thumbnail / type
      Added value: +[
+  "string",
+  "null"
+]
    • addedInput schema / properties / title / description
      Added value: +"글 제목. 긴 줄표(—) 금지. 부제는 콜론이나 괄호, 짧은 하이픈으로."
    • addedInput schema / properties / title / maxLength
      Added value: +255
  2. Changed4 schema fields changedv0.6.0
    • addedInput schema / properties / series_name
      Added value: +{
+  "description": "시리즈 **이름**(id 대신). 저장 전에 내 시리즈에서 찾아 같은 요청에 실어 보낸다 — 한 번의 호출로 시리즈까지 붙는다. 못 찾으면 저장하지 않고 목록을 알려준다",
+  "minLength": 1,
+  "type": "string"
+}
    • addedInput schema / properties / thumbnail / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedInput schema / properties / thumbnail / description
      Added value: +"썸네일 이미지 URL (http/https). 생략하면 본문 첫 이미지로 자동 설정한다. 자동 설정을 원하지 않으면 null 을 준다"
    • removedInput schema / properties / thumbnail / type
      Removed value: -"string"
  3. First observedv0.3.0

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the destructiveHint annotation, the description adds valuable behavioral context: published status is preserved, omitted fields retain existing values, draft IDs are rejected, and visibility scope cannot be changed under the current configuration. No contradiction with annotations exists.

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?

The description is front-loaded with the main purpose and each sentence carries substantive information. It is slightly dense with multiple clauses and configuration details, but nothing feels wasted given the complexity of the behavior being described.

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 mutation tool with 8 parameters and unusual partial-update semantics, the description plus schema provides enough context to call it correctly: required id, behavior for omitted fields, draft exclusion, visibility constraints, and the alternative tool for drafts. No output schema is present, but return values are not essential for correct invocation.

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?

The description adds important tool-level parameter semantics: omitted fields keep existing values rather than resetting, which is central to correctly using the optional parameters. The schema already covers most parameters well, though id and series_id still lack direct explanation in either the schema or description.

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 description opens with a specific verb and resource: '이미 발행된 글을 수정한다' (edits an already-published post). It also distinguishes itself from sibling velog_update_draft by explicitly stating that draft IDs are rejected and draft editing belongs to a different tool.

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?

The description gives clear when-to-use guidance: use this for published posts, not drafts, and explicitly names velog_update_draft as the alternative. It also contrasts the partial-update behavior with the draft tool's full-replacement behavior, further guiding correct tool selection.

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

Deploy Server

Other Tools