Slipbox MCP Server

Overview Schema Source Related Servers Discussions Admin

slipbox_create_note

Create a new atomic Zettelkasten note with one idea. Choose note type, add tags and references, then receive a note ready for linking to related concepts.

Instructions

Create a new atomic Zettelkasten note.

    Each note should contain exactly one idea. After creating, immediately
    link to related notes using slipbox_create_link.

    Note Types:
    - fleeting: Quick captures, unprocessed thoughts (process within 24-48 hours)
    - literature: Ideas extracted from sources. REQUIRES at least one entry
      in references (citation or URL). If you don't yet have the citation,
      use 'fleeting' as a staging type and promote to 'literature' once
      the source is attached.
    - permanent: Refined ideas in the user's own words (the core of your Zettelkasten)
    - structure: Maps organizing 7-15 related notes on a topic
    - hub: Entry points into major knowledge domains

    Authoring:
    - Store `content` exactly as the user provided it. Do NOT rewrite,
      expand, or restructure their words. Compose or refine content only
      when explicitly asked (e.g. "draft", "refine", "make it standalone").

    Best Practices:
    - Title should express the idea in brief (understandable without reading content)
    - A refined permanent note typically runs 3-7 paragraphs and stands
      alone; match the length of what the user gave you, though — a
      one-line capture stays one line.
    - Use 2-5 specific tags; prefer existing tags when they fit
    - Search first (slipbox_search_notes) to avoid duplicating existing notes

    Args:
        title: Concise title expressing the core idea
        content: Full note content in markdown
        note_type: One of fleeting/literature/permanent/structure/hub (default: permanent)
        tags: Comma-separated tags, e.g. "poetry,revision,craft"
        references: Newline-separated citations to external sources (e.g. "Ahrens, S. (2017). How to Take Smart Notes.

https://zettelkasten.de")

Input Schema

TableJSON Schema

Name	Required	Default
`tags`	No
`title`	Yes
`content`	Yes
`note_type`	No	permanent
`references`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.5.4Sep 22, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "title": "Result",
+      "type": "string"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "slipbox_create_noteOutput",
+  "type": "object"
+}

First observedv0.1.0Aug 2, 2026

TDQS

A5/5.0

Behavior5/5

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

With no annotations, the description carries full behavioral burden and excels: it mandates exact content preservation ('Store content exactly as the user provided it'), explains note type behavior, requires references for literature notes, and warns against rewriting unless explicitly asked. This goes far beyond what the schema alone conveys.

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 long but appropriately structured into labeled sections (Note Types, Authoring, Best Practices, Args), with every section adding practical guidance. The core purpose is front-loaded in the first sentence, and the Args section maps cleanly to the schema.

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 complex creation tool with no annotations, the description covers note type semantics, staging workflow, content fidelity, tagging, duplicate avoidance, linking, and parameter formats. An agent has enough context to invoke it correctly without needing return-value details, especially since an output schema exists.

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 description coverage is 0%, so the description is the only source of parameter meaning. It defines title, content, note_type, tags, and references with formats, examples, defaults, and type-specific constraints, fully compensating for the empty schema descriptions.

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?

The description opens with 'Create a new atomic Zettelkasten note,' a specific verb, resource, and core constraint. It clearly differentiates itself from siblings like slipbox_create_link and slipbox_update_note by focusing on note creation and atomicity.

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?

The description gives explicit guidance: search first with slipbox_search_notes to avoid duplicates, create links immediately after with slipbox_create_link, and use 'fleeting' as a staging type when citations are missing. These are concrete when/when-not and alternative-tool instructions.

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