mcp-minis

Overview Schema Source Related Servers Discussions Admin

update_note

Modify an existing vault note by ID, changing only the title, body, or tags you pass; omitted fields stay unchanged and empty strings clear content or tags.

Instructions

Update an existing note in the vault.

Only the fields you pass are changed; omit a field (or pass None) to keep its current value. Passing a field replaces it wholesale: content="" empties the note's body and tags="" clears all its tags. A title cannot be cleared — a passed title must be non-empty (the same rule save_note applies).

Args: note_id: The numeric ID of the note to update. title: New title, or omit to keep the current one. content: New body text, or omit to keep the current one; "" clears the body. tags: New comma-separated tag list replacing the whole list, or omit to keep current tags; "" clears all tags.

Returns: A confirmation, or an error message if the note does not exist or nothing was provided to change.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`tags`	No
`title`	No
`content`	No
`note_id`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv0.6.0Oct 1, 2026
- addedInput schema / properties / content / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
- changedInput schema / properties / content / default
```
Previous value: -""New value: +null
```
- removedInput schema / properties / content / type
```
Removed value: -"string"
```
- addedInput schema / properties / tags / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
- changedInput schema / properties / tags / default
```
Previous value: -""New value: +null
```
- removedInput schema / properties / tags / type
```
Removed value: -"string"
```
- addedInput schema / properties / title / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
- changedInput schema / properties / title / default
```
Previous value: -""New value: +null
```
- removedInput schema / properties / title / type
```
Removed value: -"string"
```
First observedv0.1.0Sep 30, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses wholesale replacement semantics, that content="" empties the body and tags="" clears tags, that a title cannot be cleared, and the two error conditions. It omits permissions/auth requirements and whether the change is reversible.

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-loaded with the key replacement rule in the first sentences, then structured Args/Returns. Slightly redundant with the schema on parameter names, but every sentence adds behavioral meaning rather than restating types.

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

Completeness5/5

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

For a mutation tool with no annotations and 0% schema coverage, the description supplies the missing mutation semantics, clearing rules, and error cases. An output schema exists, so the brief Returns note is sufficient and no return-value detail is needed.

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

Parameters5/5

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

Schema coverage is 0%, yet the description documents all four parameters with meaning beyond the schema: note_id is the numeric ID, and title/content/tags each have explicit omit-vs-empty semantics that the bare schema types/nullable defaults cannot convey.

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 a specific verb and resource ("Update an existing note in the vault"), which clearly separates it from get_note/list_notes/delete_note. It partially differentiates from save_note by referencing the shared title rule, but never explicitly says save_note is for creation, so sibling routing is only implied.

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

Usage Guidelines4/5

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

Gives concrete usage semantics: only passed fields change, omit or pass None to keep current value, and "nothing was provided" is an error. It stops short of naming save_note as the create alternative or stating any preconditions/permissions.

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

Deploy Server