Skip to main content
Glama
Sign In
google-keep-mcp

google-keep-mcp

by suckerfish
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

delete_note

Permanently delete a Google Keep note. This action is irreversible and removes the note entirely.

Instructions

Permanently delete a note. This cannot be undone.

Args: note_id: The ID of the note to permanently delete.

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": {
      "note_id": "<note_id>"
    },
    "name": "delete_note"
  }
}

Input Schema

NameRequiredDescriptionDefault
note_idYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Clearly states permanence and irreversibility. With no annotations, description conveys core destructive behavior. Lacks details on error conditions or permissions, but sufficient for the action.

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 plus an argument list. Every sentence is essential, no filler. Front-loaded with the main action.

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

Completeness4/5

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

Given low complexity (1 param, no nested objects) and presence of output schema, description covers core action and parameter adequately. Missing: error behavior if note not found or already deleted.

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 0%, so description needed to add meaning. It explains note_id as 'the ID of the note to permanently delete', but that largely restates the tool's purpose. Minimal added value beyond schema.

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?

Specific verb 'delete' and resource 'note' clearly state the action. Permanence distinguishes from sibling 'trash_note' which implies reversible move.

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?

States 'cannot be undone' implying caution, but does not explicitly contrast with alternative 'trash_note' for reversible deletion. Limited guidance on when to use.

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