Skip to main content
Glama
Sign In
Kybase

Kybase

by Kyrzin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

create_note

Create a new note in Kybase with a unique title, Markdown content, tags, and folder placement to capture and organize knowledge that is searchable and linkable.

Instructions

Create a new note. Embedding is generated automatically in the background. The server instructions' wikilink and tag rules apply: search_notes for the topic first and link the related notes it finds, and call list_tags before coining a new tag.

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": {
      "title": "<title>"
    },
    "name": "create_note"
  }
}

Input Schema

NameRequiredDescriptionDefault
tagsNoTags for the new note: lowercase, kebab-case, in the language already in use. Call list_tags first and reuse an existing tag where one fits
titleYesUnique across live notes, case-insensitively; a clash is refused rather than merged. This is the string other notes link to as [[Title]]
contentNoMarkdown body. Empty by default, so a note can be created first and filled with append_to_note
folder_idNoFolder UUID. Omit or pass null for the vault root; use folder_path instead when you have the path rather than the id
folder_pathNoFolder path (e.g. "Projects/Kybase") as alternative to folder_id

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.3.1
    • addedInput schema / properties / content / description
      Added value: +"Markdown body. Empty by default, so a note can be created first and filled with append_to_note"
    • changedInput schema / properties / folder_id / anyOf
      Previous value: -[
-  {
-    "format": "uuid",
-    "pattern": "^([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)$",
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "format": "uuid",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedInput schema / properties / folder_id / description
      Added value: +"Folder UUID. Omit or pass null for the vault root; use folder_path instead when you have the path rather than the id"
    • addedInput schema / properties / tags / description
      Added value: +"Tags for the new note: lowercase, kebab-case, in the language already in use. Call list_tags first and reuse an existing tag where one fits"
    • addedInput schema / properties / title / description
      Added value: +"Unique across live notes, case-insensitively; a clash is refused rather than merged. This is the string other notes link to as [[Title]]"
  2. First observedv1.3.0

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that embeddings are generated in the background and that wikilink/tag rules apply, but it does not cover permissions, failure modes, or other side effects beyond the basic create operation.

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?

The description is front-loaded with the core action and contains no obvious filler. The third sentence is dense and references external server instructions, but it still earns its place by conveying required workflow rules.

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?

For a create tool with a fully described five-parameter schema and no output schema, the description supplies the essential behavioral context: note creation, background embedding, and tag/link workflow. It is not fully comprehensive on failure or permission behavior, but it is sufficient for correct invocation.

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 100%, so the parameters are already well documented. The description adds little parameter-specific detail beyond process guidance around tags, which the schema also covers.

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 states a clear verb and resource: "Create a new note." It is immediately understandable, but it does not explicitly differentiate itself from nearby sibling tools such as append_to_note or update_note, so it falls just short of a 5.

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?

It gives explicit prerequisite behavior: search_notes first and call list_tags before inventing a new tag. That is useful usage context, though it does not state when to choose create_note over alternatives like append_to_note or create_folder.

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