Skip to main content
Glama
Sign In
Kybase

Kybase

by Kyrzin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

delete_note

Move a note to the trash by ID so it disappears from lists, search, and the graph, while staying recoverable for 30 days before permanent purge.

Instructions

Soft-delete a note by id — it disappears from list_notes/search/get_note/the graph, but is recoverable with restore_note for 30 days before being purged for good. Use list_notes with trashed:true to see what's currently in the trash.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "delete_note"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesThe note's UUID. An unknown or already-trashed id is refused rather than reported as deleted

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.3.1
    • addedInput schema / properties / id / description
      Added value: +"The note's UUID. An unknown or already-trashed id is refused rather than reported as deleted"
    • removedInput schema / properties / id / pattern
      Removed value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"
  2. First observedv1.3.0

TDQS

A4.7/5.0
Behavior5/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 so: it discloses the soft-delete semantics, the 30-day recovery window, eventual permanent purge, and the downstream visibility effects across four read surfaces. It also reinforces that unknown or already-trashed ids are refused rather than silently reported as deleted.

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

Conciseness5/5

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

Two sentences with no waste. The lifecycle consequence (soft delete, recoverable, then purged) is front-loaded, and the trash-inspection tip follows as supporting detail.

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 single-parameter mutation with no annotations and no output schema, the description supplies everything an agent needs: mutability model, reversibility window, postconditions, and where to verify state afterward.

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% and the id parameter's description already documents UUID format plus the refusal behavior for unknown/already-trashed ids. The prose only adds 'by id', so the schema is doing the heavy lifting; baseline 3 is appropriate.

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

Purpose5/5

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

States a specific verb and resource ('Soft-delete a note by id') and immediately disambiguates from hard deletion by naming the surfaces it disappears from (list_notes/search/get_note/the graph). An agent can distinguish it from delete_folder or a permanent purge without opening a schema.

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

Usage Guidelines5/5

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

Explicitly names the recovery alternative ('restore_note for 30 days') and the inspection alternative ('list_notes with trashed:true'), covering both when to use this tool and where to go next. No inference is required.

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

Deploy Server

Other Tools