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

There are no annotations, so the description carries the full behavioral burden. It usefully discloses that the text is AI-written and escaped on the frontend, which is important for safety expectations. However, it does not mention persistence, whether the annotation is stored, how ttl affects behavior, or any side effects such as interactions with undo/redo.

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

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

The description is short and front-loaded, with the main function stated first. However, the bracketed references ([5-D], [11]) are cryptic and provide no actionable guidance. The second sentence adds useful behavioral context, but the overall structure is somewhat under-specified rather than tightly informative.

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

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

This is a mutation-style tool with no annotations and no schema descriptions, so the description needs to provide more operational context. It explains the display behavior and escaping, but omits how the annotation can be removed, how it interacts with undo/redo and clear operations, and what ttl means. An agent would have to guess important invocation details.

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

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

Schema description coverage is 0%, so the description must compensate for the schema's lack of parameter explanations. It partially clarifies that x/y are screen coordinates and text is rendered escaped, but it does not explain ttl at all. The parameter semantics are therefore incomplete, especially for ttl, whose default and minimum values are present in the schema but whose meaning is left unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's primary action: displaying a text memo at screen coordinates (x, y). The verb and resource are specific enough to understand the tool's function, and the coordinate emphasis distinguishes it from simple content-adding tools. However, it does not explicitly contrast with related sibling tools like record_finding or cite.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given for when to use this tool versus alternatives such as record_finding, update_finding, or cite. There is no mention of prerequisites, typical use cases, or exclusions, so an agent must infer the appropriate context from the name and description alone.

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

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

With no annotations provided, the description takes on the disclosure burden. It explicitly states the tool is non-mutating ('그래프는 안 바꾼다') and that the effect is temporary ('임시로'), which covers the main safety-relevant behaviors. It does not mention TTL expiration or clearing behavior, but the schema's ttl parameter partially covers that, and the core behavioral profile is transparent.

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

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

The description is a single sentence with the key safety message positioned after an em dash, making it efficient and front-loaded. The cryptic reference '[5-D]' and the vague '등' (etc.) slightly reduce self-containedness, but the overall structure is appropriately concise.

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

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

The tool has a selector DSL, nested style object, TTL semantics, and an output schema, but the description only mentions 'just pushed' targets and graph non-mutation. It does not explain that the selector parameter can target arbitrary nodes, nor does it mention the clear_style relationship outside of the schema. The schema compensates substantially, so the description is adequate but not complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description itself adds no parameter-level detail, but the schema already provides rich explanations for selector (DSL filter), style (limited to color/size/border), and ttl (seconds, 0 means until clear_style). The description does not need to compensate here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('임시로 강조한다' = temporarily highlight) and clearly distinguishes the tool from graph-mutating siblings by stating '그래프는 안 바꾼다' (does not change the graph). However, it anchors the purpose to '방금 push 한 것 등' (just-pushed things, etc.) and does not mention that styles are applied to selector-matched nodes, so the full scope of the resource is slightly underspecified.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: use this when you want temporary visual emphasis after pushing elements, and it will not modify graph data. It does not explicitly name alternatives or exclusion cases, but the temporary/read-only-frame nature is clear enough to differentiate it from update_node, push_node, or clear_style.

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

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

With no annotations, the description must carry behavioral disclosure. It does reveal that citations accumulate on a node and that source_url accepts file paths/addresses beyond HTTP. However, it omits potential side effects (e.g., whether citations are immutable, ordering, or any conflicts). This is useful but incomplete.

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

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

Two sentences with no redundancy. The main action is front-loaded and the additional detail about URL flexibility and accumulation is concise. Could be more structured, but efficient.

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

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

The tool is simple (3 flat params, no nested objects) and has an output schema, so return values are covered. The description covers the key behavioral nuance (accumulation, URL flexibility) but leaves parameter explanations incomplete for node_id and source_title, which reduces overall completeness.

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

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

Schema description coverage is 0%, so the description must compensate for all parameters. It clarifies that source_url can be a file path or address, but does not explain node_id (which node) or source_title (its role or format). Two of three parameters remain semantically unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: attaching evidence links to a node, with concrete examples (IDA address, document URL). This is specific and unambiguous, though it doesn't explicitly contrast with siblings like add_annotation or update_node.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. It does not mention when to prefer cite over add_annotation or update_node, nor any prerequisites. The only contextual note (accumulation of citations) is more about behavior than usage.

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

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

Beyond the destructiveHint annotation, the description discloses exactly what is deleted (all nodes/edges), what is preserved (snapshots, findings), and that an automatic snapshot is saved before execution with a usable snapshot_id for revert. This is strong behavioral disclosure for a destructive tool.

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

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

Two short sentences: the first states the action and exclusions, the second adds the safety/revert mechanism. Every sentence earns its place and there is no redundant filler.

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

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

For a parameterless destructive tool with an output schema, the description is nearly complete: scope, preserved data, and recovery path are all covered. It leaves unspecified the fate of related metadata such as styles or annotations, but the deletion scope and output schema make the core call safe and understandable.

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

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

The tool has zero parameters and 100% schema coverage, so there is nothing for the description to add about inputs. Baseline for parameterless tools is 4, and the description appropriately focuses on behavior and output rather than inventing parameter guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the operation: delete all nodes and edges in the graph. It goes beyond a generic verb by adding scope ('all') and exclusions ('snapshots and findings are preserved'), which distinguishes it from related tools like clear_layer and individual delete_node/delete_edge.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description communicates when this tool is appropriate: a full graph reset that keeps snapshots and findings, and it notes the automatic backup. It does not explicitly name alternatives or say when not to use it, but the scope and preservation caveats provide clear context.

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

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

Even though destructiveHint=true already signals destructiveness, the description adds important behavioral details: edges connected to deleted nodes are removed even if they belong to other layers, findings are preserved, and an automatic snapshot is saved before execution, allowing rollback via snapshot_id. This goes well beyond the annotation.

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

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

The description is compact and well-structured: the primary action comes first, followed by important side effects and recovery behavior. Every sentence adds useful information without redundancy.

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

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

For a tool with a single required parameter, an output schema, and a destructiveHint annotation, the description covers the essential operational details: what gets deleted, cascading edge removal, preservation of findings, and automatic snapshot-based rollback. An agent has enough context to invoke it correctly.

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

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

The input schema only defines 'layer' as a string with no description, and schema description coverage is 0%. The description compensates by explaining that layer refers to the drawing context of a specific AI/session, which gives the parameter meaningful semantics. It could add more detail on how to obtain or format the layer identifier, but the core meaning is clear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('deletes nodes/edges drawn by a specific AI/session') and identifies the resource scope ('layer'). It also distinguishes itself from broader or narrower tools like clear_all, delete_node, and delete_edge by describing how connected edges and findings are handled.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description establishes clear usage context: use this tool to remove nodes/edges belonging to a particular AI/session layer. It does not explicitly name alternatives or state when not to use it, but the layer-based scope is clear enough for an agent to select it appropriately among siblings.

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

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

With no annotations provided, the description carries the full burden. It discloses the key destructive behavior (omitting style_id clears everything), which is important risk information. However, it doesn't mention reversibility, permission requirements, or response behavior. The cryptic '[5-D]' reference adds no behavioral clarity.

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

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

Two sentences with zero waste. The core purpose is front-loaded, and the key parameter behavior follows immediately. The cryptic '[5-D]' token is unnecessary but doesn't significantly detract from the efficient structure.

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

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

The tool is simple (1 param, 0 required) and has an output schema, so the description doesn't need to explain return values. It covers the core behavior adequately. However, the unexplained '[5-D]' reference and lack of edge-case guidance (e.g., what happens when style_id references a nonexistent style) leave minor gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain the null semantics (omitting style_id clears all), which adds meaning beyond the schema's default:null. However, it doesn't specify what format style_id should take or how it relates to other tools' style parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a clear verb+resource: 'Clears AI style'. Distinguishes from siblings like clear_layer and clear_all by specifying the target (AI style). However, the '[5-D]' notation is cryptic without context, and it's unclear whether this refers to a specific style type or internal reference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides one useful usage condition: omitting style_id clears all styles. But it doesn't explicitly differentiate from similar tools like clear_layer or clear_all, nor does it state when to prefer this tool over alternatives. The guidance is implied rather than explicit.

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

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

The description adds no behavioral disclosure beyond the action itself. While destructiveHint: true is annotated, the description provides no additional context about side effects, reversibility, or what exactly gets destroyed. It contributes nothing beyond what the annotation already states.

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

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

The single sentence is brief, but brevity without substance is under-specification, not conciseness. The sentence does not earn its place because it adds no information beyond the tool name. It lacks the structure needed to convey essential details.

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

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

For a tool with 4 parameters (3 required) and no schema descriptions, the description is critically incomplete. It does not explain the meaning of inputs, the expected output, or any usage context. An agent cannot reliably invoke this tool with the given information.

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

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

With 0% schema description coverage, the description carries the full burden of explaining the four parameters. It fails entirely, offering no explanation of what 'source', 'target', 'relation', or 'key' mean or how they are used in deletion. An agent has no way to understand the inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description '엣지를 삭제한다' translates directly to 'delete the edge', which is a tautological restatement of the tool name. It provides no additional context about what an edge is or how this operation differs from delete_node. The purpose is clear at a basic level but adds no distinguishing detail.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives like delete_node or update_edge. There is no mention of prerequisites, conditions, or exclusions, leaving the agent to infer usage entirely from the name.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely repeats the destructive verb and does not state whether deletion is permanent, whether related data is affected, whether it is undoable, or whether any confirmation is involved. This is insufficient for a delete operation.

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

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

The description is very short and free of filler, which is structurally clean. However, it is so terse that it reads as a restatement of the tool name rather than an informative definition, so the brevity is not fully earning its place.

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

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

The simple one-parameter schema and presence of an output schema mean the agent has enough to attempt invocation, but the description omits deletion semantics, side effects, and any relationship to sibling tools. For a destructive tool with no annotations, this is not complete enough.

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

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

Schema description coverage is 0%, so the description must compensate, but it only says 'delete a finding.' It implicitly connects finding_id to the finding being deleted, but it does not explain the parameter's meaning, format, or any constraints beyond the schema's required flag.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'finding 을 삭제한다' clearly states a specific verb (delete) and resource (finding), so an agent can determine the core operation. However, it is essentially a direct paraphrase of the tool name and offers no elaboration on what a finding is or what deletion entails, so it doesn't reach a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives such as undo, clear_layer, delete_node, delete_edge, or update_finding. The description does not mention any conditions, prerequisites, or exclusions, leaving usage entirely to inference.

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

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

The description discloses the refusal behavior with a specific error payload and the policy that dangling edges are not allowed. This goes beyond the destructiveHint annotation by explaining the exact failure mode and the reasoning behind it, which is valuable for an agent deciding whether to set cascade.

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

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

Two concise sentences with no filler. The main action is front-loaded, and the edge-case condition and response format are given in the second sentence. Every sentence earns its place.

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

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

The description covers the primary behavior and the critical edge case, but it omits details on the exact effect when cascade=True (does it delete edges or fail?), and any other side effects or prerequisites. Given an output schema exists, the return structure is partially known, but the semantics of the cascade flag could be clearer. Adequate but not exhaustive.

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

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

With schema description coverage at 0%, the description is the only source of parameter meaning. It explains that cascade=False causes a refusal when edges exist, implying the opposite for cascade=True, but does not explicitly state that cascade=True deletes connected edges. The id parameter is left obvious from the schema/name. Partial compensation for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: deleting a node, and includes a specific behavioral condition (refusal when edges exist and cascade is false). This distinguishes it from other graph mutation tools like delete_edge or clear_all. The verb+resource pair is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives such as delete_edge, clear_layer, or clear_all. The description focuses on the cascade condition but does not mention any contextual selection criteria, leaving the agent to infer from the tool name alone.

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

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

No annotations are provided, so the description carries the full burden. It transparently discloses that the file is created in the server data directory, the caller cannot specify a path (path traversal blocked), and the function returns the path. It also notes JSON round-trip compatibility, which is useful behavioral context.

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

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

Two concise sentences, front-loaded with the core purpose. The references to [5-E] and [11] are terse but do not detract from clarity; the structure is efficient and scannable.

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

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

Given the presence of an output schema (which covers return values), the description covers key behavioral aspects: file location, path restriction, and round-trip behavior. It does not explain filter DSL details, but those are in the schema. Overall, it is sufficiently complete for an export tool.

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

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

Schema description coverage is 100%, so both parameters are well-documented. The description adds minimal extra meaning beyond the schema (e.g., round-trip note for JSON). This meets the baseline for high coverage but does not elevate beyond it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States the verb 'export' and resource 'graph to a data format file', clearly distinguishing from import_graph and save_snapshot. The mention of file creation and path return makes the intent unambiguous, though it does not explicitly name sibling alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage through the note that JSON round-trips via import, suggesting a use case for export-import cycles. However, it lacks explicit 'when to use vs. not use' guidance or exclusions for other formats or scenarios.

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

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

No annotations are provided, so the description carries the behavioral burden. It adds useful traits — undirected traversal and shortest-first ordering — but does not explicitly state whether the operation is read-only, whether it can be expensive, or what happens when no path exists. The schema's truncation note on max_paths partially helps but does not replace overall behavioral disclosure.

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

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

The description is three compact lines with the core purpose and constraints front-loaded. Every clause adds value: what it enumerates, graph direction, ordering, and the relationship to path_to. There is no filler or repetition of schema fields.

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

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

An output schema exists and three of five parameters are already documented in the input schema, so the description can stay focused on purpose and selection. It is nearly complete for an agent to call the tool correctly, but the lack of explicit side-effect/performance/no-path behavior and thin source/target semantics keep it short of a 5.

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

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

The schema already describes max_paths, max_length, and edge_filter, and the description's 'source→target' phrase adds endpoint roles for the two otherwise undocumented required parameters. However, it does not clarify node ID formats or how edge_filter integrates with path selection, and at 60% schema description coverage the description only partially compensates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'source→target 실제 경로 열거 (무방향, 최단 우선)', a specific verb plus resource with clear constraints: enumerating actual paths from source to target, undirected, shortest-first. It also distinguishes itself from path_to by calling itself its successor, which prevents confusion with the reachability-only tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear selection context: 'path_to 의 후속' and 'path_to 는 "도달 가능?"(bool)만 답한다 — 실제 경로는 여기서 준다' tell an agent to use this tool when actual paths are needed instead of a boolean reachability answer. It does not, however, spell out when-not conditions or alternatives beyond path_to, and path_to is not present in the sibling list.

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

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

With no annotations, the description carries the behavioral burden. It meaningfully discloses that zoom_level is only an advisory hint because the M1 detail view auto-fits the subgraph, and that the focus.set protocol remains unchanged. This goes beyond the bare action, though it does not mention any effect on selection history or view state.

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

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

The core action is delivered in one front-loaded sentence, and the parameter descriptions are compact. No filler or redundant restatement of the tool name.

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

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

For a simple two-parameter navigation tool, the description covers the action, the view transition, and the caveat on zoom_level; an output schema exists so return values need not be described. It is slightly incomplete in not clarifying prerequisites or error behavior for invalid node IDs.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining that zoom_level is advisory and does not alter the underlying protocol, which is more semantic detail than the schema's 'detail view zoom hint' alone provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The Korean description states a specific action: 'Moves the screen to this node' and adds the transition 'overview → detail'. This is clear and resource-specific, though it does not explicitly distinguish itself from sibling view-related tools such as get_focused_node or get_view_state.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The overview→detail transition implies when the tool is appropriate (when the user wants to inspect a node in detail), but it does not state when not to use it or name alternatives. The usage context is implied rather than explicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does state the return values (expression and count, or null), which is useful, but it does not explicitly confirm that the tool is read-only or describe any potential side effects. For a simple getter this is acceptable, but more explicit safety information would be better.

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

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

The description is extremely concise, with two short sentences that immediately state what the tool returns and its purpose. It front-loads the core information and contains no redundant or filler content.

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

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

For a zero-parameter getter with an output schema, the description covers the essential context: what it returns, the null case, and why an AI would use it (shared view). The cryptic reference '[5-C]' is unexplained and might confuse, but it is minor. The tool's behavior is well covered given its simplicity.

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

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

The tool has zero parameters and the schema covers them trivially (100% coverage with none). Per the baseline for zero parameters, a score of 4 is appropriate; the description adds no parameter-specific detail because there are none to explain.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves the currently applied filter, including its expression and matching node count, and returns null if none exists. It also explains the purpose as a shared view for the AI to know what the person is focusing on. It does not explicitly contrast with sibling tools, but the purpose is unambiguous and specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when the AI needs to know the person's current focus (shared view), but it does not explicitly state when to use this over alternatives like get_view_state or suggest_filter. There is no mention of when not to use it or exclusions.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It does well by revealing the non-obvious missing-anchor fallback shape ({ id, missing: true }) and the inclusion of body/evidence. It does not cover error handling or read-safety, but 'get' makes the read-only intent clear and the described behavior is otherwise complete.

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

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

Two tight sentences: the primary function is stated first, and the edge-case behavior is appended second. There is no filler or redundancy.

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

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

For a one-parameter get tool with an output schema present, the description is complete. It covers the full scope of the response and highlights the most important edge case (missing anchor), so an agent has enough information to call the tool correctly.

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

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

The only parameter, finding_id, is self-explanatory from its name, and the description's use of 'single finding' reinforces that the ID identifies one finding. However, schema description coverage is 0%, and the description adds no further detail about where the ID comes from or how it should be formatted. The gap is minor for a single obvious parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('get') and a specific resource ('single finding'), and it goes further by listing what is included (body, evidence, anchor node summary). This clearly distinguishes it from sibling list/update/delete finding tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes it clear that this tool is for retrieving the full content of one finding, which implies when to use it. It does not explicitly contrast with list_findings or get_node, but the context is specific enough for an agent to select it for detail retrieval.

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

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

With no annotations provided, the description carries the burden and does well: it discloses the returned fields, the null case when there is no selection, and the observational nature of the tool. It does not explicitly state read-only behavior, but 'channel to know what the person is seeing' strongly implies it.

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

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

The description is two short sentences with no filler. The core return value is front-loaded, followed by the null behavior and the usage context. Every sentence earns its place.

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

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

For a zero-parameter getter with an output schema, the description is complete: it explains what is returned, what null means, and when the tool is useful. No critical information is missing.

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

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

The tool has zero parameters, so the schema already fully covers parameter meaning. No additional param description is needed; baseline 4 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states what the tool returns: the node currently selected/focused by the human, with id and since_ms. It is specific and not tautological, but it does not explicitly contrast with sibling tools like get_selection_history or get_view_state.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear usage context: it is the channel for the AI to know what the person is looking at between tasks. It does not explicitly mention alternatives or when-not-to-use, but the context is enough to guide an agent.

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

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

With no annotations, the description carries the burden of explaining behavior. It discloses that the tool returns an aggregated overview rather than detailed data, and implies a read-only, lightweight operation by saying it provides a summary before scanning large graphs. This is useful context beyond the tool name alone.

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

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

The description is compact and front-loaded with a one-line summary of the output, followed by the key usage trigger. Every sentence serves a purpose, with no wasted words.

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

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

Given the tool has no parameters, an existing output schema, and a simple read-only summary purpose, the description fully equips an agent to select and invoke the tool correctly. It explains what the tool returns and when to call it.

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

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

The tool has zero parameters and the schema is fully documented by its emptiness, so there is nothing for the description to add. Per the baseline for zero-parameter tools, this is sufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as a graph overview that reports scale, type distribution, layer, and top hubs. It distinguishes itself from detailed node/edge/list tools by focusing on a high-level summary, so an agent can tell it apart from siblings without inspecting them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit usage context: call it first during handover and before scanning thousands of nodes. It does not name specific alternative tools or exclusions, but the guidance is clear and actionable.

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

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

With no annotations provided, the description must disclose behavioral traits. It only states 'neighbor subgraph' and does not mention truncation (max_nodes), direction handling, edge filtering, depth limits, or any side effects. This is a significant gap for a traversal tool.

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

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

The description is a single short sentence, which is concise in length but under-specified. It lacks the essential context needed for a 5-parameter tool, making it more an under-specification than a model of conciseness. The structure is not front-loaded with the most critical constraints.

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

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

Given the tool's complexity (5 parameters, graph traversal, output schema present), the description is severely incomplete. It does not mention truncation, direction, filtering, depth limits, or any behavior beyond the label. Even with the output schema covering return values, an agent cannot infer when or how to call this tool correctly from the description alone.

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

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

Schema description coverage is 80% (4 of 5 parameters have descriptions), so the baseline is 3. The description adds no parameter meaning beyond what the schema provides; id remains undocumented, and the tool description does not clarify it. The schema already explains depth, direction, max_nodes, and edge_filter, so the description contributes nothing extra.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool fetches a 'neighbor subgraph from id with depth hops', which conveys a graph traversal purpose. However, it is vague about what a 'neighbor subgraph' includes (nodes, edges, filtering) and does not differentiate it from siblings like get_node or find_paths. It is not a tautology but lacks specificity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention use cases, when not to use it, or any context that would help an agent select it. The schema hints at parameters, but the description itself offers no decision support.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that reserved keys (_citations/_superseded/_provenance) are exposed as-is, justifies this as read-only and evidence/history purposes, and notes there is no forgery risk. This goes beyond the schema and adds valuable behavioral context, though it stops short of covering error handling or auth requirements.

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

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

The description is extremely concise—two sentences with zero filler. The primary purpose is front-loaded, and the second sentence adds a specific, relevant nuance about reserved keys. Every word earns its place; no redundant information.

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

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

The tool has an output schema (per context signal), so the description needn't explain return values. It covers the core semantics (whole node, tags, properties) and adds a behavioral caveat about reserved keys. For a simple get-by-id operation, this is sufficient, though it omits details like handling non-existent nodes or the impact of include_neighbors on output shape—but the schema covers the latter.

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

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

Schema description coverage is 50%: the include_neighbors parameter has a description, but id does not. The tool description does not clarify the id's format or any additional constraints, nor does it explain how it relates to the returned node. With only half the parameters described, the description should compensate, but it doesn't, leaving id semantically under-documented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states '노드 하나를 통째로 조회한다' (fetch one whole node) with a specific verb and resource, including properties and tags. It distinguishes from siblings like list_nodes (listing many) and get_neighbors (neighbors only) by the 'whole node' scope. The nuance about reserved keys adds clarity without ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage: fetch a single node when you need its full data. However, it does not explicitly contrast with alternatives like list_nodes or get_neighbors, nor mention when not to use it. Since there are many sibling tools, explicit routing would help, but the purpose statement gives enough implicit guidance.

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

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

With no annotations, the description carries the full burden. It does disclose the output order (latest first) and the structure of items (id, ts), which is useful behavioral context. However, it does not explicitly state that the operation is read-only (though implied by 'get'), nor does it mention any side effects, error conditions, or limitations. Partial transparency.

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

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

The description is extremely concise – a single phrase with no redundant words. It front-loads the core purpose (history) and includes the ordering and output shape. Every element is informative and nothing is wasted.

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

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

The tool has an output schema, so return format is covered externally. However, the description lacks explanation of the parameter, which is a gap. It also does not provide any usage context, such as when selection history would be relevant, or any prerequisites (e.g., a selection must exist). For a simple getter, it is minimally adequate, but incomplete for full autonomous use.

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

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

Schema description coverage is 0% – the description does not mention the sole parameter 'last_n' at all. The schema provides type, default, min, and max, but no semantic meaning. Since coverage is low, the description must compensate, but it fails to explain what 'last_n' represents (e.g., number of history items to return). The parameter name is somewhat self-explanatory, but the lack of any description leaves room for misinterpretation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description '최근 클릭 히스토리 ([5-C]) — 최신순 [{id, ts}, ...]' clearly identifies the resource (recent click/selection history) and specifies the ordering and output structure. The tool name 'get_selection_history' reinforces the retrieval action. It is distinct from sibling tools, which focus on findings, nodes, or graph state.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, typical use cases, or conditions under which another tool (e.g., list_findings, get_graph_summary) would be more appropriate. The description is purely declarative and offers no selection logic.

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

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

No annotations were provided, so the description carries the full burden. It discloses that the tool returns null if the state is unset, and that with multiple browsers it returns the most recent active client's state. This is beyond what the schema (which has no parameters) would suggest, providing useful behavioral context. However, it doesn't mention read-only status or any side effects, but given the tool is a getter, that is implied.

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

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

The description is exceptionally concise—two short sentences that convey the purpose, the key data points, and a critical edge case (null and multi-browser behavior). It is front-loaded with the main purpose and adds the nuance without any fluff.

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

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

The tool has an output schema (though not provided here), so return values are likely specified. The description explains the view state components (mode, zoom, camera) and the null behavior. For a zero-parameter getter, this is sufficient. It doesn't mention what the output schema looks like, but that's outside its scope since an output schema exists.

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

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

The tool has zero parameters, and the schema coverage is 100% (vacuously). Since there are no parameters to document, the description doesn't need to add parameter semantics. The baseline for zero params is 4, and the description appropriately focuses on what the tool returns and its edge cases.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool retrieves the view state (mode/zoom/camera) of the person screen, with a specific reference to [5-C] and [9-C]. This is a specific verb and resource, and the scope is clear. It is distinguishable from siblings like get_graph_summary or get_visible_nodes, though it doesn't explicitly name alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool: to retrieve the current view state, including mode, zoom, and camera. It also notes that if multiple browsers are attached, it returns the most recent active client's state, which is a key usage nuance. However, it doesn't explicitly state when not to use it or alternatives.

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

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

With no annotations provided, the description carries the full burden. It reveals deterministic sorting and pagination, which is useful, but doesn't explicitly state that it's a read-only operation or disclose any side effects, costs, or rate limits. The behavior is lightly covered but incomplete for a fully undisclosed context.

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

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

The description is two concise sentences, front-loaded with purpose and functional details. It avoids fluff and is appropriately sized for a simple tool, earning a high score in this dimension.

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

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

The tool has an output schema (not shown), so return-value details are covered. The description covers pagination and deterministic ordering, but misses critical context like the distinction from list_nodes and when to prefer this tool. It's adequate but not comprehensive.

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

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

Schema description coverage is 0%, so the description must explain the parameters. It mentions pagination but doesn't connect it to 'limit' or 'offset', nor does it explain their meaning, bounds, or effects. The agent must infer what the parameters do from the schema alone, which is insufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns node IDs visible on screen after filtering, which is a specific verb+resource. It distinguishes itself from generic list operations by mentioning the filter and human screen context, but does not explicitly differentiate from sibling 'list_nodes', so it's not a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives like list_nodes, get_node, or search. It doesn't mention conditions for selection or exclusions. The context is only implied by the name and description, not explicit.

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

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

No annotations are provided, so the description carries the full burden. It does disclose genuinely useful behavior: the server reads the file in-process, path is restricted to the data directory with absolute-path/.. traversal/outside-root rejected, and merge semantics mirror import_graph. However, it omits error behavior, outcome details, and any mutation consequences, leaving notable gaps for a tool with zero annotation coverage.

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

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

Four sentences with the core purpose and key constraints front-loaded; each sentence carries distinct information (scale, processing model, path restriction, merge semantics). Minor clutter comes from the opaque [5-E]/[11]/[100K+] spec references, but overall it is tight and efficient.

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

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

An output schema exists so return-value explanation is unnecessary. The description covers core semantics, scale, processing model, and path constraints, which is solid for a moderate-complexity import tool. Gaps remain: format parameter behavior, error handling on invalid paths or malformed files, and outcome/effect specifics. For a mutation tool with no annotations, a bit more would make it complete.

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

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

Schema description coverage is 0%, so the description must compensate. It adds real meaning for 'path' (directory restriction and rejection rules) and for 'merge' (points to import_graph semantics). But 'format' receives no explanation at all, and the compensation is only partial across the three parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource statement: bulk import from a file inside the server data directory. It also carves out its niche versus siblings by noting the 100K+ scale and that push_batch's MCP limit does not apply, making its scope distinct. The opaque spec references ([5-E], [11]) do not obscure the core purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied rather than explicit: the 100K+ scale and 'MCP 상한 미적용' note signal that this is the tool for large imports where push_batch would be capped. It references import_graph for merge semantics, giving a partial cross-tool pointer, but offers no explicit 'when not to use' conditions or a direct alternative-selection statement.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does well: 1MB payload limit, idempotent merge vs full replacement, WRITE validation path, and reserved-key/server-managed-field behavior are all disclosed. This goes well beyond the input schema.

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

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

The definition is compact and front-loaded, starting with purpose and constraint, then merge behavior, then validation/security. The bracketed spec references add some noise but do not seriously undermine readability.

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

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

For an import tool with an output schema and no annotations, the description is nearly complete: input structure, size limit, merge behavior, and validation consequences are covered. Minor omissions are format semantics and explicit error behavior on oversize payloads.

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

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

Schema description coverage is only 33%, so the description must compensate for undocumented parameters. It explains the data shape, the 1MB constraint, and the exact semantics of merge=True/False. The format parameter is not explained, though its name and default 'json' make the omission low-risk.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: '인라인 JSON 데이터를 임포트한다' (imports inline JSON data). The 'inline' qualifier distinguishes it from the sibling import_from_file, and the merge/replace behavior further clarifies what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear conditional guidance for merge=True vs merge=False, which is useful for parameter choice. However, it never explicitly names alternatives such as import_from_file or push_batch, nor states when to prefer one over the other. The 'inline' qualifier implies the boundary but no exclusions are spelled out.

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

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

The description discloses deterministic sorting and pagination, which are behavioral traits. However, with no annotations provided, it carries the full burden of behavioral disclosure. It does not mention whether the operation is read-only, any side effects, or potential error conditions (beyond what the schema hints at). This is a moderate disclosure but leaves safety and failure modes implicit.

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

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

The description is a single, concise Korean sentence that front-loads the purpose and key capabilities. It avoids redundancy and is appropriately brief for a straightforward list operation. No wasted words.

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

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

Given that an output schema exists (so return values are defined elsewhere) and the tool is a simple list operation with no required parameters, the description covers the core behaviors: filtering, deterministic sorting, and pagination. It is adequate for an agent to understand the tool's function, though it could benefit from explicit usage guidance.

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

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

Schema description coverage is only 33% (only the 'filter' parameter has a description). The top-level description mentions 'filter' and pagination but does not elaborate on parameter syntax or semantics. It relies on the schema for filter DSL details, which is acceptable, but it does not compensate for the undocumented 'limit' and 'offset' parameters. The description adds minimal value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'edge list' (엣지 목록) and specifies that it supports filtering, deterministic sorting, and pagination. This clearly distinguishes it from sibling list tools like list_nodes or list_findings, leaving no ambiguity about the resource and operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives. It does not mention scenarios where a different tool (e.g., list_nodes, search) would be more appropriate, nor does it provide any exclusions or conditions. The context of siblings is not leveraged.

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

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

With no annotations provided, the description carries the behavioral burden. It discloses ordering (created_at desc) and that the heavy body field is intentionally omitted from list results. It does not mention pagination or auth, but the key behavioral traits affecting use are surfaced.

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

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

Two compact, front-loaded sentences deliver the essential usage directive first, then ordering and body payload behavior. No filler or redundancy.

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

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

For a list tool with full schema coverage and an output schema, the description covers the critical operational details: when to call, ordering, and why body is absent. It could mention filtering by layer/node, but those are already in the schema, so the definition is sufficiently complete.

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

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

Schema description coverage is 100%, so the parameters are already fully documented. The description adds context about list ordering and body omission but does not enrich parameter meaning beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: lists findings, specifically the 'gold' findings from previous sessions. It differentiates itself from siblings by noting that details should be fetched via get_finding, making its role clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to call this first during handoff, giving clear contextual usage. It also explains that detailed content is available via get_finding, effectively routing the agent away from this list when body content is needed. It does not list exhaustive exclusions, but context is clear.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose deterministic ordering and pagination, which are genuinely useful behavioral traits. However, it stops there — it does not mention output shape, error behavior beyond a schema note, rate limits, or how large datasets are handled. Acceptable but thin for a tool with zero annotation coverage.

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

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

A single front-loaded sentence that states the core purpose before the behavioral qualifiers. There is zero waste and the key properties (filter, deterministic sort, pagination) appear early. It is efficient, though bordering on under-specification — but that is a completeness concern, not a structure one.

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

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

The tool is simple to invoke since all 5 parameters are optional (a no-argument call succeeds) and an output schema is present, so return format need not be described. However, the description is missing sibling-routing guidance, parameter interplay, and usage context. For a list tool this is adequate but leaves the agent to guess when it is the right choice among ~14 node/graph-related siblings.

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

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

Schema description coverage is only 40% (limit and filter documented; order, offset, sort_by left to enum values). Per the rubric, at <50% coverage the description must compensate, but it adds almost nothing: it references the filter generically and mentions pagination without linking it to limit/offset semantics. The description does not help the agent understand sort_by, order, or offset beyond what the bare schema already shows.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the verb+resource combination ('노드 목록' / node list) clearly and adds behavioral specifics (filter, deterministic sort, pagination). It does not explicitly differentiate from siblings like get_node, get_visible_nodes, or list_edges, but the resource scope is unambiguous and goes beyond a bare tautology of the tool name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only usage hint is 'filter 로 좁히고' (narrow with filter), which conveys implied context for narrowing results. There is no guidance about when to choose this tool over siblings (get_visible_nodes, search, suggest_filter, list_edges), no exclusions, and no mention that all parameters are optional so a bare call works. This is minimal guidance, closer to 'no guidance' than 'clear context'.

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

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

With no annotations, the description takes on the safety disclosure burden; it reveals ordering behavior and defines both possible kind values. It does not explicitly state that listing is side-effect free, but the verb 'list' makes this clear.

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

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

Two short sentences front-load the core purpose, then add the key usage hint and kind definition. Every sentence earns its place with no repetition.

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

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

For a zero-parameter list tool with an output schema, the description supplies the essential context: when to call it and what ordering/filter values to expect. Nothing critical is missing.

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

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

The tool has zero parameters, so the schema already covers all input requirements. The description adds useful context about result ordering and kind taxonomy, matching the baseline for parameterless tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('list saved snapshots') plus ordering ('newest first'), and its list semantics clearly distinguish it from sibling save_snapshot/load_snapshot. The intent is unambiguous and actionable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides an explicit usage context: call this first during handover. It does not name alternatives or exclusions, but for a simple list operation no strong alternative is needed.

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

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

No annotations are provided, so the description carries the full burden. It discloses the destructive nature of the operation ('replaces the entire graph') and adds a safety mechanism ('auto snapshot saved before replacement') that allows undo. This directly informs the agent of the primary behavioral trait and the built-in rollback, which is valuable context beyond the schema.

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

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

The description is two short sentences in Korean, front-loaded with the core action (load and replace) followed by the safety note. There is no redundant fluff; every word adds informational value. Structure is efficient and easy to parse.

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

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

Given the tool has a single required parameter and an output schema (not shown), the description covers the main effect and the rollback behavior. It does not explain where snapshot_id comes from or error cases, but these are relatively minor given the simplicity of the tool. The auto-save detail is a notable plus that mitigates potential user regret.

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

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

Schema description coverage is 0% and the description does not elaborate on the snapshot_id parameter at all. It does not explain what the ID refers to, how it is obtained (e.g., from list_snapshots), or any format requirements. Since the schema provides no description and the tool description ignores it, parameter meaning is entirely missing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('loads') and resource ('snapshot') and specifies the effect: it replaces the entire current graph. This distinguishes it from siblings like save_snapshot, list_snapshots, and import_graph, making the tool's purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (restoring a graph by loading a snapshot) and provides a safety note about auto-snapshot save, which hints at a benefit of using this over alternatives. However, it does not explicitly contrast with siblings (e.g., import_graph for external data, or save_snapshot for capturing state) nor state any conditions for when not to use it.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does explain the polling pattern, the cursor-based incremental semantics, and the push limitation. However, it doesn't disclose return format details, error behavior, or the 'dropped' overflow mechanism beyond what the schema already states — leaving behavioral depth mostly to the output schema.

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

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

Two short Korean paragraphs, front-loaded with the core purpose, followed by the rationale. The internal reference '[5-C]' is cryptic but harmless. Efficient overall, though the second paragraph's rationale could be tighter.

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

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

Given an output schema exists, return-value documentation is not the description's burden. It covers the polling pattern, cursor semantics, and the why. Minor gaps: it doesn't mention the 'dropped' loss notification or edge cases, but these are captured in the schema, making the definition reasonably complete for a polling tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description references the cursor concept and the ring-overflow 'dropped' mechanism, but it doesn't add parameter-level meaning beyond what the schema already documents. It stays at baseline without compensating further.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource+scope: polls user state changes (focus/filter) incrementally after a cursor. This clearly distinguishes it from all 40+ sibling tools, none of which poll events. The scope constraint ('커서 이후분만' — only after the cursor) is precise and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly explains when to call it: 'AI 는 작업 사이에 이걸 호출해 사람의 변화를 따라잡는다' (AI should call this between tasks to catch up on human changes), with the rationale that MCP is one-shot request/response so the server cannot push. This is clear usage context, though it doesn't name specific alternatives or state when not to use it.

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

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

With no annotations, the description carries the full behavioral burden, and it does so well: it discloses that nodes are applied before edges, that batch-internal references are allowed, and that there is a hard limit of 1,000 elements per call. It does not mention atomicity, error behavior on limit violations, or whether existing nodes/edges are overwritten, but it discloses the most operationally critical traits.

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

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

Three short sentences, each adding essential information: batch capability, ordering semantics, and the size limit with routing to import_from_file. No filler or repetition; the most important constraint is front-loaded.

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

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

The description covers core behavior, ordering, and the bulk alternative, which is good, but it omits detailed parameter semantics and failure/atomicity behavior. Since no annotations exist and the schema offers no property descriptions, the tool is not fully self-contained for an agent to call correctly without consulting sibling tools or external knowledge.

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

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

Schema description coverage is 0%, so the description must compensate, but it only names nodes and edges and their application order. It does not describe the expected shape of each node or edge object, required fields, or how cross-references are expressed. This is a meaningful gap for an agent trying to construct valid arguments.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: draw/apply multiple nodes and edges in one call. It goes beyond the name by clarifying the batch scope and explicitly distinguishes this from import_from_file for bulk ingestion. An agent can tell this is the batched counterpart to push_node/push_edge.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear usage context: use this when applying several nodes/edges at once, especially when they reference each other. It also states an explicit boundary: if the total exceeds 1,000 nodes+edges, use import_from_file. This provides a direct when/when-not decision rule.

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

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

Given that no annotations are provided, the description shoulders the behavioral burden. It discloses two non-obvious behaviors: repeated calls with the same identity tuple update the edge, and unpushed node references produce auto-created placeholders resolved by a later push_node. These go beyond a simple 'creates an edge' statement, though side effects of optional parameters like ttl or layer are not covered.

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

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

The description is two compact sentences with the core operation and update semantics front-loaded, followed by the placeholder behavior as a separate nuance. Every sentence earns its place and there is no filler.

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

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

For a tool with 11 parameters and no annotations, the description covers the essential operational semantics: what the tool does, its idempotent update behavior, and its interaction with push_node. The output schema covers return shape, so that is not a gap. The main missing piece is routing to sibling update_edge/push_batch, but the core calling context is sufficiently clear.

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

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

Schema description coverage is low at 27%, and the description adds meaning by casting source, target, relation, and key as the identity tuple that determines update-versus-insert behavior. However, it does not compensate for the many undocumented optional parameters (ttl, tags, layer, properties, style_hint, directed), leaving their semantics to inference from names and defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action: drawing a relationship between two nodes, and adds the key update semantics on repeated calls with the same (source,target,relation,key). It does not explicitly distinguish push_edge from sibling tools like update_edge or push_batch, so an agent has to infer the boundary from context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives practical usage guidance: referencing a not-yet-pushed node is allowed because a placeholder is auto-created and later resolved by push_node. This is clear context for when to use the tool, though it does not explicitly state when to prefer push_edge over update_edge or push_batch.

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

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

With no annotations, the description carries the full disclosure burden. It discloses the most important behavioral traits: repeated calls with the same id update the node, and properties are merged. It does not discuss TTL expiration or what happens to non-property fields on update, but core behavior is transparent.

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

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

Two short sentences, front-loaded with the primary action and usage timing, followed by the essential merge behavior. No filler or redundant restatement of the tool name.

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

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

The description covers purpose, timing, and upsert/merge semantics well. But for a 10-parameter tool with no annotations and 50% schema coverage, it leaves several optional parameter semantics and the distinction from update_node unaddressed. The output schema reduces the need to explain return values, but gaps remain.

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

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

The description adds meaning to id (re-use updates) and properties (merged rather than replaced), going beyond the schema. However, it does not help with several undocumented parameters like tags, layer, parent_id, style_hint, or position_hint, and schema coverage is only 50%.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the action and resource: draw a discovered node on the graph and update it if the same id is used again. It differentiates by context ('discovered during analysis') but does not explicitly distinguish itself from sibling update_node or push_batch.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tells the agent when to call the tool: immediately upon node discovery during analysis. It implies the primary use case but does not provide explicit exclusions or mention alternatives like update_node for post-hoc edits.

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

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

No annotations are provided, so the description carries the transparency burden. It usefully discloses that the finding is emphasized and separately queryable, implying a persistent create operation. However, it does not explicitly state that this creates a new record, nor mention side effects, error conditions, or return behavior.

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

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

The description is two short sentences with the action front-loaded and then the key benefit/context added. There is no filler, repetition of schema fields, or unnecessary detail.

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

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

For a create-focused tool with an output schema and well-described parameters, the description covers the core intent and distinctive outcome. It lacks explicit usage boundaries and finer side-effect detail, but the schema and finding-focused sibling names fill in much of the remaining context.

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

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

Schema description coverage is 86%, so most parameters (title, body, evidence, node_ids, confidence, tags) are already described in the schema. The description adds only conceptual framing around 'gold insight' rather than parameter-specific detail, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete action (못박는다/records) and a specific resource (critical insight/gold findings), and explains that these findings are kept separate from structural nodes. It is unambiguous about the tool's core function, though it does not explicitly contrast with finding-management siblings like update_finding or cite.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear context: use this when AI analysis surfaces a decisive insight that should be preserved and not buried among thousands of nodes. It does not provide when-not-to-use guidance or name alternative tools, so it falls short of a full routing guideline.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals two important non-obvious behaviors: the redo stack is invalidated by new graph changes, and the tool returns a specific error object when nothing can be redone. This is meaningful operational context for an agent.

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

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

The description is two sentences with no filler. The core action is front-loaded, and the additional behavioral constraints are stated succinctly in the second sentence.

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

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

For a zero-parameter tool with an output schema and a clear sibling relationship to 'undo', the description is complete. It explains when the operation applies, when it fails, and how the redo stack behaves, leaving no critical gap for an agent to call it correctly.

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

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

The input schema has zero parameters, so the baseline is 4; there are no parameter semantics for the description to enrich. The description does not need to compensate for any undocumented parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb and resource: reapplying changes that were just undone ('방금 undo 한 변경을 다시 적용한다'). It is immediately distinguishable from its sibling 'undo' by framing redo as the inverse operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly ties usage to the preceding 'undo' operation and states the invalidation condition: a new graph change clears the redo stack. It also defines the failure case ('nothing_to_redo'), giving the agent concrete conditions for when the tool will not work.

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

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

With no annotations, the description carries the behavioral disclosure burden and does so well: it discloses that the card is a server-generated self-contained snapshot, does not connect to serve, contains no secrets, and renders in a sandboxed iframe. It does not explicitly state read-only/no-mutation, but 'render' plus snapshot semantics strongly imply no live state changes.

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

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

The core behavior is front-loaded in the first sentence, followed by concise implementation and security caveats. The bracketed references [9-D] and [11] are internal documentation artifacts that add little agent-usable meaning, but the overall length is reasonable and dense.

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

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

For a one-parameter render tool with an output schema present, the description covers the client context, display mode, snapshot behavior, and security properties. A slight gap is the lack of an explicit side-effect or read-only statement, but the wording makes accidental mutation unlikely.

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

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

The only parameter, node_id, has 0% schema description coverage, so the description must compensate. It does so by making clear that the node identifies the entity whose neighboring subgraph will be rendered. It could explicitly name node_id, but the semantic intent is unambiguous.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description specifies a concrete action—rendering the target node's neighboring subgraph as an interactive chat card—and identifies the medium (sandboxed iframe for MCP Apps clients). It is clearly distinguishable from data-returning siblings such as get_neighbors or export_graph, though it never names a sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives useful context about where rendering happens (chat iframe in MCP Apps clients) and contrasts with the full live view being in a separate browser window, which is an implicit routing signal. However, it does not explicitly say when to choose this tool over alternatives or state exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action is 'save' (mutation), but does not disclose side effects such as overwriting existing snapshots, reversibility, or any permissions/rate limits. The note about 'next session taking over' adds some context but is insufficient for a mutation tool without annotation support.

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

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

The description is a single, concise sentence that front-loads the core purpose and includes a parenthetical clarifying the semantic context. It is efficient without unnecessary detail, though it could have added a sentence on usage without harming structure.

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

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

The tool is simple with only two parameters, and an output schema exists (though not shown). However, the description lacks critical details like whether snapshot names must be unique or whether saving overwrites existing snapshots. Given the absence of annotations, the description is minimally adequate but not fully complete for a mutation tool.

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

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

Schema description coverage is 100%, so the schema already documents both parameters (name and description). The description does not add extra meaning or examples beyond the schema, but the baseline of 3 is appropriate given high coverage. No gaps in parameter understanding exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (save snapshot), the resource (this session's graph), and adds context that it marks the point for the next session to continue. This distinguishes it from sibling tools like load_snapshot and list_snapshots by focusing on the save action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use it (when you want to preserve the graph state for a future session) but does not explicitly mention alternatives like load_snapshot for restoring or list_snapshots for viewing. No exclusions or conditional guidance are given, leaving the agent to infer usage from context.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does so comprehensively: case-insensitive substring matching, 'not regex/no ReDoS', deterministic id-ascending ordering, limit and total semantics, READ-only status with no dirty/events, and clear errors for reserved or unknown fields. This fully discloses side effects, ordering, and error behavior.

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

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

The description is front-loaded with purpose and then logically organized into matching semantics, field restrictions, result behavior, and read safety. Each sentence serves a functional role, though cryptic bracketed references like [5-B], [11], and [23-B] add noise without helping an AI agent.

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

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

Given that an output schema exists, the description does not need to restate return values. It covers query matching rules, the field whitelist, error behavior, deterministic ordering, limit/total semantics, and the read-only guarantee. No critical parameter or side-effect information is missing for correct invocation.

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

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

The schema already documents all three parameters with 100% coverage, establishing a baseline of 3. The description adds meaningful semantic clarity beyond the schema: in_fields is a plain field-name list rather than a filter DSL, only whitelisted fields and non-reserved properties are allowed, and invalid fields are rejected with clear errors. This lifts the score above baseline, though some additions like sorting and total are result behavior rather than parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence, '노드 부분 일치 검색', plus the detailed 'query 를 in_fields 각 필드에서 substring 매치' clearly identifies the tool as a node substring search. This distinguishes it from sibling tools like get_node (exact node retrieval) and list_nodes (generic listing) by specifying the search semantics and target fields.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description thoroughly explains how the tool behaves and what constraints apply, such as the whitelist fields and no-regex rule, but it never explicitly says when to prefer this tool over alternatives or when not to use it. Usage context is only implied by the search-focused semantics.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely says 'changes layout' without mentioning whether the operation is reversible, what side effects occur on node positions, or any permission requirements. This is a significant gap for a mutation tool.

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

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

The description is a single, front-loaded sentence with zero fluff. It states the purpose first and adds the enum context efficiently. Every word earns its place.

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

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

Despite having an output schema, the description is too thin for a mutation tool with no annotations. It lacks guidance on when to use the tool, behavioral details, and any potential side effects. An agent would need additional information to call it confidently in varied contexts.

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

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

Schema coverage is 100%, so both parameters are documented. The description adds valuable context by noting that the 'preset' algorithm passes node coordinates via the options parameter, and that the enum matches tab names. This enriches the schema's raw definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear purpose: changing the layout of the detailed cytoscape view. It is specific about the resource (layout) and the action (change), and the note about enum alignment with tabs adds useful context. However, it does not explicitly differentiate from sibling tools, though none appear to share this exact purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives only a hint that the enum matches specific tabs, but no explicit guidance on when to use this tool versus alternatives or when not to use it. An agent is left to infer that this is for layout changes, which is obvious, but there is no mention of prerequisites or exclusions.

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

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

With no annotations provided, the description must carry the behavioral burden. It clearly states that the tool does not apply the filter but shows a banner, and that invalid DSL expressions are rejected. This discloses the non-mutating nature and error handling behavior, which is adequate for a suggestion tool. It does not mention every edge case, but the key behaviors are covered.

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

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

The description is exceptionally concise, consisting of two short sentences that front-load the core distinction (proposal vs. application) and the rejection behavior. There is no redundant wording, and each sentence earns its place.

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

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

The tool is simple with two parameters and an output schema present. The description captures the essential behavior (proposal, not application) and the DSL rejection rule. For an agent to invoke it correctly, nothing critical is missing. The reference to 'banner' provides sufficient detail about the delivery.

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

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

Both parameters are fully described in the input schema (100% coverage). The description adds no extra meaning beyond what the schema already provides for reason and dsl_expr. Since the schema covers the semantics well, the baseline of 3 is appropriate; the description does not need to compensate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states a specific action (propose a filter) and the target (the human). It contrasts with applying, clarifying that this is a suggestion mechanism, not a direct modification. This distinguishes it from sibling tools like get_active_filter or apply_style, even without naming them, and uses the specific verb 'propose'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the use case: when the AI wants to recommend a filter it thinks the user should see, and the human decides whether to apply it. This provides clear context for invocation but does not explicitly name alternative tools or state when not to use it. The contrast with 'not applying' gives partial guidance, so it scores slightly above average but lacks explicit exclusions.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It explains the side effect (broadcast event causing open views to update), the no-op case (returns ok: false with nothing_to_undo), and the scope limitation (view states are not affected). This is rich, non-obvious behavior.

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

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

Three compact sentences cover the purpose, the broadcast side effect, the error case, and the exclusions. Every sentence adds necessary information, and the core action is front-loaded.

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

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

Given zero parameters and an output schema, the description sufficiently covers operation, effects, error handling, and non-targets. It stops short of explaining whether multiple successive undos are supported, which is a minor ambiguity for an undo tool.

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

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

The tool has zero parameters, so the baseline is 4. There are no parameter semantics to clarify, and the description appropriately focuses on behavior rather than inventing unnecessary parameter guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb (revert) with a clear resource (the last graph change) and enumerates the affected operations (push/update/delete/clear/cite/import). It clearly differentiates from the redo sibling by describing the inverse of a graph mutation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly states when to use the tool: to revert the last graph change. It also explicitly excludes view-state changes (filter/style/focus/snapshot), which helps the agent avoid misusing it, though it does not explicitly name redo as the alternative for reapplying changes.

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

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.

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.

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.

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.

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.

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.

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'partial update' and does not mention side effects, history behavior, permissions, or irreversibility. The reason parameter's behavioral nuances (correction vs supersede) live in the schema, not in the tool description.

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

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

The description is a single compact sentence that front-loads the core action and includes a useful sibling distinction in parentheses. Every element earns its place with no filler.

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

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

The input schema is rich, including patch structure, server-managed fields, and reason semantics, and an output schema exists, which reduces the need for the description to explain return values. The description itself is minimal, but combined with the schema it is adequate for correct invocation; the main gap is the lack of mutation-safety context due to absent annotations.

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

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

Schema description coverage is 100%, so the schema already documents finding_id, patch format, and reason semantics thoroughly. The tool description adds no parameter-level meaning beyond the generic notion of a partial update, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the action ('기존 finding 을 부분 갱신한다' - partially update an existing finding) and clearly distinguishes it from record_finding for the same-finding update case. This lets an agent select it correctly 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description names the alternative ('record') and gives an explicit condition: use this when updating an existing finding rather than recording a new one. It does not enumerate exclusions beyond that, but the sibling context makes the main decision clear.

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

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.

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.

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.

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.

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.

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.