Skip to main content
Glama

update_edge

Update a graph edge by applying a partial patch, using 'correction' to overwrite incorrect data or 'supersede' to archive outdated values.

Instructions

엣지를 부분 갱신한다. patch/reason 규약은 update_node 와 같다.

[23-C] RN7 ZZ(1): patch is required, as [5-A] declares it. It had drifted to | None = None, which made this the one updater that accepted a missing patch — and the falsy-to-{} degradation that used to hide behind it reported ok:True while changing nothing but updated_at, publishing an edge.update for an edit that never happened. Keyword-only because key carries a default.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyNo
patchYes
reasonNo왜 바꾸는지 ([24]). 생략=일반 갱신. 'correction'=기존 값이 틀렸다 → 덮어쓰고 틀린 값은 안 남긴다(변경 사실만 기록). 'supersede'=기존 값이 유효했으나 낡았다 → 이전 값을 이력에 백업한 뒤 덮어쓴다.
sourceYes
targetYes
relationYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.0.0

TDQS

C2.8/5.0
Behavior2/5

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

No annotations are present, so the description carries the full transparency burden. It discloses that patch is required and references an old bug where a missing patch caused a false ok:True and an edge.update event, but it does not clearly describe current success/failure behavior, preconditions, or side effects of a normal partial update.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening sentence is clear and front-loaded, but the following change-note is full of internal identifiers ([23-C], RN7 ZZ(1), [5-A]) and Python keyword-only implementation details that do not help an agent invoke the tool. The useful content is buried in a historical bug explanation.

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

Completeness2/5

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

For a six-parameter mutating tool with no annotations and low schema coverage, the description is incomplete: edge identity fields, patch semantics, and preconditions are undefined. The output schema may cover return values, but the input contract is not self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only 17% schema description coverage, the description needs to explain source, target, relation, key, and patch, but only says patch is required and delegates patch/reason details to update_node. This is not enough for an agent to construct a correct call without consulting another tool's documentation.

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 first sentence, '엣지를 부분 갱신한다', states a specific verb and resource: partially update an edge. The mention that patch/reason conventions are shared with update_node further identifies this as the edge counterpart, distinguishing it from update_node, delete_edge, and push_edge.

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?

No explicit when-to-use or alternative guidance is given; the agent must infer that this is for edge updates from the name and first sentence. Pointing to update_node for patch/reason conventions helps with parameter handling, but does not explain when to choose this tool over push_edge, delete_edge, or undo.

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