Skip to main content
Glama
rps321321

obsidian-mcp-pro

by rps321321
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Create Daily Note

create_daily_note

Create a daily note for today or a specific date in your Obsidian vault's daily-note folder, optionally seeding it from a template with date and time placeholders. Fails if the note already exists.

Instructions

Create a daily note for today (or a specific date) in the vault's configured daily-note folder using its configured filename format. Optionally seed the note from a template file with Obsidian-style placeholder substitution: {{date}} and {{title}} → the formatted date; {{time}} → local HH:mm; {{date:FORMAT}} / {{time:FORMAT}} → custom moment-style format. Fails if the daily note already exists.

Input Schema

NameRequiredDescriptionDefault
dateNoTarget date in YYYY-MM-DD format (defaults to today). Determines filename and {{date}} substitution.
contentNoInitial markdown body for the daily note. Ignored if templatePath is provided.
templatePathNoRelative path to a template note. Its content is copied into the new daily note with Obsidian-style placeholders substituted: {{date}}/{{title}} → formatted date, {{time}} → local HH:mm, and {{date:FORMAT}}/{{time:FORMAT}} → custom moment-style format.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv4.1.1
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Addedv2.0.0
  3. Removedv1.9.0
  4. Addedv0.1.6
  5. Removedv0.1.4
  6. Changed4 schema fields changedv0.1.2
    • changedInput schema / properties / content / description
      Previous value: -"Initial content for the daily note"New value: +"Initial markdown body for the daily note. Ignored if templatePath is provided."
    • changedInput schema / properties / date / description
      Previous value: -"Date in YYYY-MM-DD format (defaults to today)"New value: +"Target date in YYYY-MM-DD format (defaults to today). Determines filename and {{date}} substitution."
    • addedInput schema / properties / date / pattern
      Added value: +"^\\d{4}-\\d{2}-\\d{2}$"
    • changedInput schema / properties / templatePath / description
      Previous value: -"Path to a template note to use (replaces {{date}} placeholder)"New value: +"Relative path to a template note. Its content is copied into the new daily note with {{date}} replaced by the formatted date."
  7. First observedv0.1.0

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already declare the mutating, non-idempotent, non-destructive, closed-world profile, and the description adds substantive behavior: config-driven path/filename, template placeholder substitution semantics, and the failure condition when the note already exists. These are the non-obvious traits an agent needs before calling.

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?

Two dense sentences, front-loaded with the operation and scope, and the failure condition is included where it matters. The placeholder enumeration is somewhat long and partly duplicates the schema, but it earns its place as the core behavioral nuance.

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?

No output schema exists, yet the description never states what the tool returns (e.g., created note path/content) or whether parent folders are auto-created. For a creation tool with zero required params, the core behavior is covered but the return contract is a notable gap.

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 schema already documents date, content, and templatePath in depth. The description largely restates the placeholder rules already present in the templatePath schema description, adding little beyond the structured fields.

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+resource: creating a daily note in the vault's configured daily-note folder using its configured filename format. This clearly distinguishes it from the generic create_note and from get_daily_note by its config-driven placement, template seeding, and existence-failure behavior.

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?

Gives a clear context for use (today or a specific date, optional template) and surfaces the important 'fails if the note already exists' constraint, which implicitly steers the agent to check first. It does not explicitly name create_note or get_daily_note as alternatives, so no full when-not guidance.

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