Skip to main content
Glama

update_node

Apply a partial patch to a graph node: merge new property values and remove obsolete keys, optionally marking the change as correction or supersede for history tracking.

Instructions

노드를 부분 갱신한다.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
patchYes{ set: {...}, remove: ["key", ...] } — set 은 merge, remove 는 properties 키 삭제. 서버관리 필드는 갱신 불가.
reasonNo왜 바꾸는지 ([24]). 생략=일반 갱신. 'correction'=기존 값이 틀렸다 → 덮어쓰고 틀린 값은 안 남긴다(변경 사실만 기록). 'supersede'=기존 값이 유효했으나 낡았다 → 이전 값을 이력에 백업한 뒤 덮어쓴다.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.0.0

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden, yet it only states 'partial update' with no disclosure of mutation behavior, reversibility, or side effects. The schema separately documents that server-managed fields are immutable and that 'supersede' backs up old values to history, but the description itself does not surface these behavioral traits.

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 front-loaded sentence with no wasted words that states the core action clearly. It is appropriately terse, though so minimal that it forgoes opportunities to convey usage and behavior guidance.

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

Completeness3/5

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

The presence of an output schema and rich parameter descriptions makes the overall definition mostly complete despite the sparse description. Gaps remain in usage guidance relative to sibling tools and in behavioral disclosure (history backup, change logging, server-managed field handling) that the description does not surface.

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?

The description itself adds no parameter meaning, but the input schema covers the complex parameters well at 67% coverage: patch's set/remove syntax and server-managed field restriction are documented, and reason's correction/supersede semantics are described in detail. The only undocumented parameter, id, is a self-evident string identifier.

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?

The description 'partially updates a node' states a specific verb and resource, and the 'partial' qualifier usefully signals merge semantics rather than full replacement. It distinguishes the tool from delete_node, update_edge, and push_node, though it does not name these siblings or their selection conditions explicitly.

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?

The description gives no guidance on when to use update_node versus alternatives such as push_node or update_edge, and states no exclusions or prerequisites. There is no indication of when a partial update is appropriate versus creating or replacing a node.

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