Skip to main content
Glama

yuque_update_note

Modify a note's content or delete it permanently; deletion requires explicit 'DELETE' confirmation to prevent accidents.

Instructions

Update or delete a note. ⚠️ Deleting (status=9) requires confirm='DELETE'. PUT /notes/:id. 详见 references/api/note_api.md

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rawNoReturn raw full JSON (default false, returns trimmed fields)
bodyNoNew content (plain text or Markdown, unchanged if omitted)
statusNoStatus: 0=active, 9=deleted (unchanged if omitted)
confirmNoConfirmation token. Must be set to the exact string 'DELETE' to proceed. This is a safety guard against accidental deletion.
note_idYesNote ID (required)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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 correctly discloses the destructive deletion safety guard (confirm='DELETE') and the HTTP endpoint, which is valuable. It omits whether deletion is reversible/restorable, permission requirements, and the update-vs-delete side effects, leaving meaningful gaps 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.

Conciseness4/5

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

Front-loads the warning about deletion and the confirm requirement, then the endpoint. It is compact and every sentence earns its place, with only the Chinese reference pointer adding minor noise.

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

Completeness3/5

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

For a mutation-with-delete tool that has no annotations and no output schema, the description covers the safety guard and endpoint but leaves the update semantics (which fields, restore possibility) and reversibility unstated. Adequate but not complete.

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

Parameters3/5

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

Schema coverage is 100%, so all five parameters (including body, status, confirm, raw, note_id) are already documented in the schema, establishing the baseline of 3. The description's status=9=delete note merely restates what the schema already says.

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

Purpose4/5

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

States specific verbs (update/delete) and the resource (note), and the endpoint PUT /notes/:id pins down the operation. It distinguishes itself reasonably from yuque_get_note and yuque_create_note, though the dual update/delete purpose in one tool is slightly conflated.

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

Usage Guidelines3/5

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

Provides one key usage condition (deleting via status=9 requires confirm='DELETE'), which is genuinely useful to select the delete path. However, it offers no guidance on when to use this tool versus yuque_create_note or yuque_get_note, and no exclusions or prerequisites beyond the confirm token.

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