Skip to main content
Glama
dezer32

openwhispr-mcp

by dezer32

Create a note

create_note

Create a new note in OpenWhispr's local app and store it. Provide a folder_id to file it in a specific folder, or omit it to use the default folder. Returns the saved note.

Instructions

Create a note in the local OpenWhispr app. Without folder_id the app files it into its own default folder — see the notice field in the reply. note_type is fixed at creation: update_note cannot change it. Returns the stored note.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYes
contentNo
folder_idNoFrom list_folders. Omit to let the app choose its default folder.
note_typeNopersonal
source_fileNo
audio_duration_secondsNoSeconds, not milliseconds.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already mark this as a write, non-idempotent, non-destructive operation. The description adds valuable behavior beyond those flags: default-folder side effect, a notice field in the reply, note_type immutability, and the returned stored note. There is no contradiction with the annotations.

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?

Three sentences, each earning its place: the operation, the folder default behavior, and the immutable note_type constraint. The main action is front-loaded, and there is no filler or redundancy.

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?

With no output schema, it correctly states that the stored note is returned and points to the notice field for default-folder information. It covers the main decisions an agent needs; the remaining gap is the parameter semantics for source_file and note_type enum values, but they are minor for a creation tool.

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 only 33%, so the description must compensate for some parameters. It does clarify folder_id behavior and note_type's immutability, but it leaves source_file and the practical meanings of the note_type enum values unexplained, creating a partial compensation.

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 a specific verb and resource: 'Create a note in the local OpenWhispr app.' It also differentiates the tool from the update_note sibling by stating that note_type is fixed at creation and cannot be changed by update_note.

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 practical context: omitting folder_id uses a default folder, the reply contains a notice field, and note_type must be chosen at creation because update_note cannot change it. There is no explicit 'use this instead of X' statement, but the create/update distinction is clear.

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