Skip to main content
Glama

delete_note

Remove notes from your Obsidian vault by moving them to trash or deleting permanently to manage your knowledge base and maintain organized content.

Instructions

Delete a note (moves to .trash by default)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
permanentNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • MCP tool handler for 'delete_note' that validates input and calls the vault's delete_note method, handling errors and returning formatted responses.
    @mcp.tool(name="delete_note", description="Delete a note (moves to .trash by default)")
    def delete_note(path: str, permanent: bool = False) -> str:
        """
        Delete a note from the vault.
    
        Args:
            path: Relative path to the note
            permanent: If true, permanently delete; otherwise move to .trash folder
    
        Returns:
            Success message
        """
        if not path or not path.strip():
            return "Error: Path cannot be empty"
        if len(path) > 1000:
            return "Error: Path too long"
    
        context = _get_context()
    
        try:
            context.vault.delete_note(path, use_trash=not permanent)
    
            if permanent:
                return f"✓ Permanently deleted note: {path}"
            else:
                return f"✓ Moved note to trash: {path}"
    
        except FileNotFoundError:
            return f"Error: Note not found: {path}"
        except VaultSecurityError as e:
            return f"Error: Security violation: {e}"
        except Exception as e:
            logger.exception(f"Error deleting note {path}")
            return f"Error deleting note: {e}"
  • Core implementation of note deletion in ObsidianVault class, either moving to .trash or permanent delete with path validation.
    def delete_note(self, relative_path: str, use_trash: bool = True) -> None:
        """
        Delete a note from the vault.
    
        Args:
            relative_path: Path to the note
            use_trash: If True, move to .trash folder instead of permanent delete
    
        Raises:
            VaultSecurityError: If path is invalid
            FileNotFoundError: If note doesn't exist
        """
        file_path = self._validate_path(relative_path)
    
        if not file_path.exists():
            raise FileNotFoundError(f"Note not found: {relative_path}")
    
        if use_trash:
            # Move to .trash folder at vault root
            trash_dir = self.vault_path / ".trash"
            trash_dir.mkdir(exist_ok=True)
    
            # Create unique name if needed
            trash_path = trash_dir / file_path.name
            counter = 1
            while trash_path.exists():
                name_parts = file_path.stem, counter, file_path.suffix
                trash_path = trash_dir / f"{name_parts[0]}.{name_parts[1]}{name_parts[2]}"
                counter += 1
    
            # Move file
            file_path.rename(trash_path)
            logger.info(f"Moved to trash: {relative_path} -> {trash_path.name}")
        else:
            # Permanent delete
            file_path.unlink()
            logger.info(f"Deleted note: {relative_path}")
  • MCP tool registration decorator for the delete_note tool.
    @mcp.tool(name="delete_note", description="Delete a note (moves to .trash by default)")
Behavior3/5

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 that deletion typically moves notes to .trash unless 'permanent' is set, which is useful context about the tool's default safety behavior. However, it lacks details on permissions, error handling, or what the output schema might return.

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?

The description is extremely concise—a single sentence that efficiently conveys the core action and a key behavioral detail (default trash behavior). Every word earns its place, with no redundant or unnecessary information.

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?

Given the tool has an output schema (which handles return values) and no annotations, the description is moderately complete. It covers the basic purpose and a critical behavioral trait, but as a mutation tool with 2 parameters, it should ideally include more about usage context or parameter details to fully guide the agent.

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 description coverage is 0%, so the description must compensate. It implies the 'permanent' parameter's effect (default false means moves to trash), adding meaning beyond the schema. However, it doesn't explain the 'path' parameter or provide full parameter context, leaving gaps in documentation.

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?

The description clearly states the action ('Delete') and resource ('a note'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from other deletion tools (like 'delete_calendar_event') beyond mentioning notes, which keeps it from a perfect score.

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

Usage Guidelines2/5

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 like 'delete_calendar_event' or other note-related tools. It mentions the default behavior (moves to .trash), but doesn't specify scenarios or prerequisites for use, leaving usage context vague.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/getglad/obsidian_mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server