XBOSS

네이버 블로그 글 초안 수정

naver__blog__owner_post__update

Destructive

연결한 내 네이버 블로그의 임시저장 초안 하나를 새 내용으로 고쳐 다시 임시저장합니다. log_no 에 고칠 초안 번호(글 초안 만들기 결과의 log_no)를, document 에 바꿀 글을 넣으세요. 임시저장 목록에 없는 번호면 고치지 않고 초안을 찾지 못했다는 오류가 나며, 새 글을 만들지 않습니다. 발행은 하지 않습니다. 최종 발행은 고객이 네이버 블로그에서 직접 하고, 글의 내용은 고객의 것입니다. 네이버 계정을 먼저 연결해야 합니다. 호출마다 토큰 1소진 요청 처리 시 XBOSS 작업을 생성하고 처리 결과를 저장합니다. 기관 원본의 조회 여부와 별개로 이 호출은 순수 읽기 전용이 아닙니다. 기관 데이터 변경은 도구별 실행 내용과 기존 확인 절차를 따릅니다.

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": {
      "log_no": "<log_no>",
      "document": "<document>"
    },
    "name": "naver__blog__owner_post__update"
  }
}

Input Schema

Name	Required	Description
`log_no`	Yes	Draft number (logNo) to update - the log_no returned when the draft was created.
`document`	Yes	The post content to save as a draft (never published).
`account_link_id`	No	연동 ID(UUID v4). 선택 입력입니다. 비워 두면 서버가 API 키로 연동을 찾아 씁니다. 같은 서비스에 계정을 여러 개 연동했을 때만 직접 입력해 주세요.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 15, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already flag readOnlyHint=false and destructiveHint=true; the description adds real context beyond them: no publishing, no new post creation, a not-found error path that leaves state untouched, a 1-token cost per call, and server-side XBOSS task creation with stored results. The overwrite of existing draft content is only implied by '새 내용으로 고쳐' rather than stated outright, which keeps it from a 5.

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 essential information (what it does, parameter mapping, no-publish, error path, prerequisite) is front-loaded and tight. However, the trailing sentences about XBOSS tasks and '기관 원본의 조회 여부' read as generic boilerplate not specific to a Naver blog draft edit, diluting an otherwise efficient description.

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?

For a 3-parameter mutation with a nested object and no output schema, the description covers the prerequisite, the side effects (token cost, task creation), the error behavior, and what it deliberately does not do. Only the precise effect on the prior draft content is left implicit.

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 description coverage is 100% and the nested document object is fully documented, so the baseline is 3. The description restates the log_no provenance and the document payload, which the schema already says, and adds no extra meaning about the nested fields (rights_declared, content_artifact_ref) beyond what is already there.

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 ('임시저장 초안 하나를 새 내용으로 고쳐 다시 임시저장'), scoped to the caller's own connected Naver blog. It explicitly contrasts with creating ('새 글을 만들지 않습니다') and publishing ('발행은 하지 않습니다'), so an agent can distinguish it from sibling create/publish tools without opening the schema.

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?

Gives clear preconditions (Naver account must be linked first) and explicit mapping instructions for both required params (log_no from the draft-creation result, document as the new body). It also states the failure mode when log_no is not in the draft list. It does not name a specific sibling to use instead when the goal is to create or publish, so it falls 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 XBOSS tools Inspect

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

Need Help?