Skip to main content
Glama

cortexpad

by com.cortexpad

create_note

Create a new note owned by the current user.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleNo
contentNoNote body. Wrap copyable snippets/commands in a fenced code block (```lang ... ```) to render a one-click copy button. Checklist items MUST be written as "- [ ] text" (unchecked) or "- [x] text" (checked) — the space inside the brackets is required, e.g. "[] text" or "[]text" will NOT render as a checkbox and shows up as plain text instead. Nest an item under the one above it with two leading spaces per level, e.g. " - [ ] sub-item" (one level) or " - [ ] deeper" (two levels) — indentation must be a multiple of two spaces. Section headings are written as "## Heading" (1-3 #'s). Inline `code spans` (single backticks) and **bold** are supported inline within text. Links and other markdown are NOT supported — they render as literal characters, so don't use them.
reminderAtNoISO datetime for a due reminder. Call get_settings first to get the user's IANA timezone and convert any spoken local time correctly — never guess. A past timestamp is clamped to now.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedInput schema / properties / content / description
      Previous value: -"Note body. Wrap copyable snippets/commands in a fenced code block (```lang ... ```) to render a one-click copy button. Checklist items MUST be written as \"- [ ] text\" (unchecked) or \"- [x] text\" (checked) — the space inside the brackets is required, e.g. \"[] text\" or \"[]text\" will NOT render as a checkbox and shows up as plain text instead. Section headings are written as \"## Heading\" (1-3 #'s). Inline `code spans` (single backticks) and **bold** are supported inline within text. Links and other markdown are NOT supported — they render as literal characters, so don't use them."New value: +"Note body. Wrap copyable snippets/commands in a fenced code block (```lang ... ```) to render a one-click copy button. Checklist items MUST be written as \"- [ ] text\" (unchecked) or \"- [x] text\" (checked) — the space inside the brackets is required, e.g. \"[] text\" or \"[]text\" will NOT render as a checkbox and shows up as plain text instead. Nest an item under the one above it with two leading spaces per level, e.g. \"  - [ ] sub-item\" (one level) or \"    - [ ] deeper\" (two levels) — indentation must be a multiple of two spaces. Section headings are written as \"## Heading\" (1-3 #'s). Inline `code spans` (single backticks) and **bold** are supported inline within text. Links and other markdown are NOT supported — they render as literal characters, so don't use them."
  2. Changed1 schema field changed
    • addedInput schema / properties / reminderAt
      Added value: +{
+  "description": "ISO datetime for a due reminder. Call get_settings first to get the user's IANA timezone and convert any spoken local time correctly — never guess. A past timestamp is clamped to now.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
  3. First observed

TDQS

B3.4/5.0
Behavior2/5

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

With no annotations, the description carries full burden. It reveals only that a new note is created, but nothing about side effects (e.g., persistence, return value), auth requirements, or failure modes. The schema provides formatting details for content, but that is not behavioral disclosure about the tool itself.

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 a single, front-loaded sentence that directly states the core function without excess words. It is appropriately minimal for a tool whose other details are handled by the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite the rich schema descriptions for two parameters, the overall definition lacks contextual completeness. There is no output schema indicating the return format, no guidance on when to choose this tool among many siblings, and no mention of implications like the note appearing immediately in lists. An agent calling this tool would need to infer several operational details.

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 67% (title lacks description, but content and reminderAt are richly described). The main description adds no parameter information beyond what the schema already provides. Since coverage is neither high nor low, baseline 3 applies, and the description offers no compensatory detail.

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?

Clearly states the action (Create a new note) and ownership ('owned by the current user'), which distinguishes it from tools like update_note or delete_note. The verb and resource are specific and unambiguous.

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

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this is for creating a standalone note, but it does not explicitly differentiate from siblings like append_to_note or add_checklist_item. No when/when-not guidance or mention of alternative tools for similar but distinct operations.

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

All cortexpad toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation5/5

Each tool targets a distinct resource or action: note CRUD, checklist operations, label management, changelog entries, settings, and task queries. Descriptions explicitly differentiate between append vs. update, list vs. get, check vs. uncheck, and add vs. remove, so there is no ambiguity.

Naming Consistency5/5

All tool names follow a verb_noun snake_case pattern (e.g., add_label, get_note, check_item, update_note), with consistent verb choices. Even 'get_my_tasks' and 'uncheck_item' fit the pattern, so the naming is predictable and uniform.

Tool Count5/5

14 tools is well-scoped for a notes application with checklist, label, and changelog features. Each tool covers a distinct operation without redundancy or bloat, and the count sits comfortably within the ideal 3-15 range.

Completeness4/5

The tool set covers full CRUD for notes, plus checklist management (add, check, uncheck), label management (add/remove), changelog entries, settings retrieval, and task aggregation. Minor gaps like archive/unarchive and a dedicated label list are workable, so the surface is near-complete for the domain.

Resources