A
licenseNot graded
qualityC
maintenanceMCP server for AI agents to read, write, and organize notes in a local-first, human-in-the-loop note-taking app.
6
2
MIT
cortexpad
Server Details
Google Keep-style notes app with an MCP server for AI agents to read/write notes.
Ownership verified
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Available Tools
16 toolsadd_changelog_entryAInspect
Add a short, dated changelog entry to a note — structured evidence of a change (e.g. "Bumped reply target 3-5 → 8-10"), separate from and never touching the note body by default. Purely additive: does not overwrite or clobber content. Two ways to use it: (1) create a NEW numbered entry — if anchor is given (exact or substring text of an existing line), a small "((n))" marker pointing to the new entry is appended to that line, failing if anchor doesn't match any line (call get_note first if unsure of the exact text); without anchor the entry is note-wide with no inline marker. (2) append to an EXISTING entry via appendTo: n (e.g. 3 for an existing "((3))" marker) — adds another dated comment/update under that same marker without creating a new marker or number; fails if entry n doesn't exist yet. appendTo and anchor are mutually exclusive — anchor is ignored when appendTo is set. Use section (e.g. "update", "note") to label what kind of entry this is when a marker accumulates several over time — the UI groups/filters by section. Use this instead of update_note/append_to_note when recording a decision or change without altering the visible note text. Capped to the most recent 20 entries total across all markers.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| at | No | Optional ISO 8601 timestamp to backdate this entry to when the real-world event actually happened, instead of the moment this tool call runs — e.g. logging a reply that was posted on X two days ago should carry that post's actual date, not today's, since "day"/"week" goal progress reads this field. Defaults to now if omitted. | |
| id | Yes | Note ID | |
| text | Yes | One-line changelog entry text | |
| anchor | No | Optional: text of the line to mark with a new ((n)). Substring match, case-insensitive. Ignored if appendTo is set. | |
| section | No | Optional free-text label grouping this entry (e.g. "update", "note") — useful when a marker accumulates entries from different threads. | |
| appendTo | No | Optional: an existing changelog entry number (e.g. 3 for "((3))") to append this as another comment/update under, instead of creating a new marker. Fails if that entry number doesn't exist. |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: 'Purely additive: does not overwrite or clobber content', failure conditions ('fails if `anchor` doesn't match any line'), cap ('Capped to the most recent 20 entries'), and precedence ('`anchor` is ignored when `appendTo` is set').
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 detailed but well-structured, opening with purpose, then explaining modes, failure cases, and alternatives. Slightly long, but every sentence adds information relevant to correct invocation.
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?
Covers all major aspects: purpose, modes, failure, cap, section usage, and relation to alternatives. No output schema, but the tool's return is not central. Completeness is strong for a 6-param tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers all parameters (100%), and the description adds contextual meaning: explains how `anchor` and `appendTo` interact, how `section` groups entries, and backdating behavior for `at`. This exceeds the baseline of 3.
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 clearly states 'Add a short, dated changelog entry to a note' with scope ('separate from and never touching the note body by default'), and explicitly distinguishes from siblings like update_note/append_to_note via 'Use this instead of...'.
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?
Provides explicit guidance: 'Use this instead of update_note/append_to_note when recording a decision or change without altering the visible note text.' Also details two usage modes (new entry with anchor, appendTo existing) and when each applies, plus mutual exclusivity and failure conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
add_checklist_itemAInspect
Add an unchecked checklist item ("- [ ] text" line) to a note
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Note ID | |
| item | Yes | Item text | |
| indent | No | Nesting depth, 0 = top level (default), 1 = one level nested under whatever item precedes it, etc. |
TDQS
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the item is added as unchecked and specifies the exact markdown format, but it does not mention where the item is inserted (e.g., end of note), whether the note must exist, or any failure behavior. This is a reasonable baseline but lacks detail beyond the core operation.
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 with no filler. It immediately states the action and the specific format, making it efficient and scannable for an agent.
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?
Given no annotations, no output schema, and a relatively simple operation, the description is adequate but not complete. It does not disclose where the item is added (e.g., appended to the note's end) or how indentation interacts with existing items. An agent might need additional inference to understand the full effect on the note.
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?
The schema covers all parameters with descriptions (100% coverage), so the description does not need to repeat them. It does add value by clarifying the exact text format for the 'item' parameter, which is not in the schema, but this is marginal. The baseline 3 applies as the schema handles most semantics.
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 uses a specific verb ('add') and clearly identifies the resource: an unchecked checklist item in a note, with the exact line format '- [ ] text'. This distinguishes it from sibling tools like check_item, uncheck_item, and append_to_note, which serve different purposes.
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 usage for adding a new unchecked checklist item, but it does not explicitly state when to use this tool versus alternatives like append_to_note or add_label. It provides clear context about the operand ('to a note') but lacks explicit exclusions or guidance for selecting among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
add_labelAInspect
Add a label to a note (no-op if already present)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Note ID | |
| label | Yes |
TDQS
A3.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the idempotent no-op behavior, which is important, but omits other behavioral traits such as error handling (e.g., note not found) and whether the operation requires any permissions. The mutation aspect is implied by 'Add' but not elaborated.
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 states the core purpose and the most critical behavioral nuance (no-op) without any redundant or tangential information. It is appropriately concise for a simple tool.
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 simple two-parameter tool with no output schema, the description covers the primary action and a key behavioral trait (idempotency). It does not explain return values or error cases, but given the simplicity and the clear idempotency note, it is reasonably complete. A 5 would require even more detail, which is not necessary here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes 'id' as 'Note ID' but leaves 'label' with no description, and schema coverage is only 50%. The description does not explicitly explain the parameters; it only implies that 'id' refers to the note and 'label' is the label to add, providing minimal additional meaning beyond the schema. The label's format or constraints are left entirely unspecified.
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 clearly states the action ('Add') and resource ('a label to a note'), which precisely matches the tool name and differentiates it from the sibling 'remove_label'. The parenthetical 'no-op if already present' additionally specifies the exact scope of the operation, making the purpose unambiguous.
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?
The description implies usage context (adding labels to notes) and the no-op clarification gives a clear behavioral guideline (safe to call multiple times). However, it does not explicitly mention alternatives or when not to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
append_to_noteCInspect
Append text to an existing note
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| content | Yes | 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. |
TDQS
C2.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing behavior. It states 'append' but does not clarify whether text is added to the end, whether the note must already exist, or what happens on invalid id. No side effects, return behavior, or error handling are mentioned, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, so it is concise and front-loaded. However, it is so brief that it sacrifices necessary detail about behavior and usage, making it under-specified rather than efficiently concise.
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?
For a tool with no annotations and no output schema, the description is incomplete. It does not explain prerequisites (existing note), the exact append behavior, error conditions, or any formatting expectations beyond what the schema already covers. An agent would need to guess crucial details about how this tool behaves in practice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers the 'content' parameter extensively (formatting rules, checklists, code blocks), but 'id' has no description. The tool description itself adds nothing beyond what the schema already provides for content, and it does not compensate for the undocumented 'id' parameter. With schema coverage at 50%, the description should clarify parameter roles but does not.
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 specific action ('Append text') on a resource ('existing note'), clearly distinguishing it from siblings like create_note and update_note. The verb 'append' implies additive behavior, so the purpose is clear even without naming the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus update_note or create_note. The description does not mention that this is for adding content to an existing note without replacing it, nor any alternatives or exclusions. Agents must infer usage from the tool name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_itemAInspect
Check off a checklist item in a note, matched by text (case-insensitive, whole-item match, not substring). Fails with an error if no item matches — call get_note first if you're not sure of the exact wording. Prefer this over update_note for checking a single item; it also triggers the "all done" push notification when it completes the last item.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Note ID | |
| item | Yes | Text of the item to check (case-insensitive, must match a full item, not a fragment) |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It clearly states the error condition when no item matches, describes the matching nuances, and reveals the side effect of triggering the 'all done' push notification on the last item. This exceeds what structured data would provide.
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 compact and well-structured: it states the action first, then the failure mode and prerequisite, and finally an alternative and a distinctive side effect. Every sentence contributes useful information without repetition or fluff.
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?
Given the tool's simplicity (2 params, no output schema, no annotations), the description covers the essential aspects: action, matching behavior, error handling, usage alternatives, and a notable side effect. It does not explicitly describe the return value, but this is a minor gap for a mutation tool where the outcome is clear.
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?
The input schema already documents both parameters with descriptions (id='Note ID', item includes matching rules). The description reiterates the matching semantics but adds little new parameter-level meaning beyond what the schema already gives, so a baseline score of 3 is appropriate.
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 clearly states the tool's function with a specific verb and resource ('Check off a checklist item in a note') and adds precise matching criteria (case-insensitive, whole-item match, not substring). It distinguishes itself from related tools like update_note and uncheck_item.
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 usage guidance: 'Prefer this over update_note for checking a single item' names a clear alternative and the recommendation. It also instructs to 'call get_note first if you're not sure of the exact wording', providing a prerequisite for correct use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_noteBInspect
Create a new note owned by the current user.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | ||
| content | No | 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. | |
| reminderAt | No | 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. |
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.
delete_noteAInspect
Permanently delete a note by ID. Destructive and not reversible via the API — confirm with the user before calling this unless they clearly already asked for the note to be deleted.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the operation is destructive, permanent, and not reversible via the API, and adds the important instruction to confirm with the user. This is comprehensive for a delete tool with a single ID parameter.
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 only two sentences, front-loaded with the core action and immediately followed by a critical usage warning. Every word earns its place with 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?
Given the simplicity of the tool (one parameter, no output schema), the description covers the essential context: permanent deletion, irreversibility, and confirmation requirement. It lacks details on edge cases like non-existent IDs, but this is not critical for a straightforward delete operation.
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?
The schema has 0% coverage, so the description must compensate. It adds 'by ID' but does not elaborate on what ID format to expect or how to obtain it. For a single parameter, this is minimal but acceptable; the tool name and context make it clear that 'id' refers to a note ID.
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 clearly states the action ('Permanently delete a note by ID'), specifying the verb (delete), resource (note), and scope (by ID). It is unambiguous and distinguishes itself from sibling tools that perform other note operations.
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?
The description provides clear context on when to use the tool: only after user confirmation, unless the user explicitly asked for deletion. It does not explicitly mention alternatives, but the caution about irreversible deletion serves as implicit guidance, ensuring the agent does not call it prematurely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_my_tasksAInspect
Get the user's open (unchecked) checklist items across all unarchived notes, each with its note ID and title. Call this at the start of a session to pick up tasks the user left for you — items you can act on, act on; check them off with check_item when done.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral details: only open/unchecked items are returned, only unarchived notes are included, and each result carries note ID and title. It does not state whether the operation is read-only or if there are side effects, but the verb 'Get' and the suggestion to check off items afterwards imply a safe read. This is more transparent than many tool descriptions.
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 two sentences. The first sentence states exactly what the tool returns, and the second sentence provides actionable guidance. There is no wasted verbiage, and the information is front-loaded.
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?
The description is complete for a simple read-only tool. It covers the scope (open items, unarchived notes), the output (note ID and title), and usage context (start of session). Even without an output schema, the user understands what to expect. It also provides a helpful cross-reference to check_item, making it self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty (100% coverage). The description adds no parameter-specific details, but none are needed. Per the baseline for zero-parameter tools, this is appropriate.
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 clearly states the tool's function: retrieving the user's open (unchecked) checklist items across all unarchived notes. It specifies the output includes note ID and title, distinguishing it from sibling tools like list_notes or check_item. The verb 'Get' is specific and matches the tool name.
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 explicitly instructs when to use the tool: 'Call this at the start of a session to pick up tasks the user left for you.' It also provides follow-up guidance on how to act on results, including using check_item to complete tasks. This is clear, actionable usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_noteAInspect
Get a single note by ID, full content included. Only returns notes owned by the current user; an ID belonging to someone else or that doesn't exist fails. Use this before check_item/uncheck_item when you're not sure of a checklist item's exact text.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that only notes owned by the current user are returned and that invalid or unauthorized IDs fail. This is valuable context, though it doesn't detail error types or any limitations beyond ownership. For a simple getter, this is sufficient.
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 three concise sentences. The first front-loads the core purpose, the second clarifies ownership and failure, and the third gives actionable guidance. Every sentence earns its place with no redundancy.
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 simple one-parameter retrieval tool with no output schema or annotations, the description covers purpose, access restrictions, failure behavior, and a specific use case. The hint about checklist items implies the return content is comprehensive enough for such operations, making the description complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'id' as a string. The description adds meaning by stating that the ID must belong to the current user and that other IDs cause failure, clarifying the parameter's valid domain. It does not further specify format, but the added semantics are useful given 0% schema description coverage.
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 clearly states the tool's function: 'Get a single note by ID, full content included.' It uses a specific verb and resource, and the phrase 'single note' distinguishes it from list_notes and other sibling tools that operate on multiple items.
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?
Explicitly recommends using this tool 'before check_item/uncheck_item when you're not sure of a checklist item's exact text,' providing a concrete use case. However, it does not name alternatives for listing multiple notes or exclude other scenarios, so it lacks a comprehensive when-not/alternatives comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_settingsAInspect
Get the user's stored settings, including their IANA timezone (e.g. "Europe/Berlin") if set. Use this to convert a spoken local time ("6pm", "tomorrow at 9am") into the correct UTC reminderAt — never guess or assume the user's timezone.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the timezone may not be set ('if set') and explains the purpose of the setting, which aids the agent in interpreting results. However, it does not specify the full structure of settings or whether other settings are included, leaving minor uncertainty about the return payload.
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?
Two concise sentences, each earning its place. The first sentence states the tool's purpose and key data point. The second provides a specific usage rule with an example. No wasted words, and the most critical information is front-loaded.
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 no-parameter getter with no output schema, the description provides sufficient context: what it returns, that the timezone is optional, and when to use it. The example ('Europe/Berlin') clarifies the expected format. The use case for converting local times is fully explained, making the tool self-contained in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so there is nothing to document. The description adds context about the timezone value, which is more about the return data than parameters. With no parameters, the baseline of 4 is appropriate; description does not need to compensate for missing parameter info.
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 clearly states the tool retrieves the user's stored settings, with a specific emphasis on the IANA timezone. It distinguishes itself from siblings by focusing on settings retrieval, which no other sibling covers. The verb 'get' and resource 'settings' 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use this tool to convert spoken local times into UTC reminderAt, and instructs to never guess or assume the user's timezone. This provides clear when-to-use guidance and implicitly warns against alternatives (assuming timezone). The instruction is actionable and directly tied to a common use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_notesAInspect
List or search the current user's notes only. Search matches title or content, case-insensitive substring. Defaults to unarchived notes, newest/pinned first. Use this to find a note's ID before calling get_note, update_note, or the checklist/label tools, which all require one.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results | |
| query | No | Optional search query | |
| archived | No | Include archived notes |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description conveys key behaviors: it returns only the current user's notes, performs case-insensitive substring matching on title/content, defaults to unarchived notes, and orders by newest/pinned first. It does not mention pagination or response shape, but for a read-only list tool this is solid transparency.
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?
Two sentences, front-loaded with the verb and resource, then compressed search semantics and a clear usage directive. Every sentence earns its place without 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?
Without an output schema or annotations, the description covers purpose, behavior, and usage context well. It could clarify what fields are returned (e.g., full objects vs. just IDs), but it explicitly frames the tool as an ID-finder, which is sufficient for its intended workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema: it explains that 'query' matches title or content case-insensitively and that the default is unarchived notes, which clarifies the 'archived' parameter's default behavior. This enriches parameter understanding.
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 'List or search the current user's notes only,' clearly specifying the verb, resource, and scope. It also distinguishes itself from siblings by stating its use case: finding a note ID before calling get_note, update_note, or checklist/label tools.
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 explicitly says 'Use this to find a note's ID before calling get_note, update_note, or the checklist/label tools, which all require one.' This provides clear when-to-use guidance and names the alternatives, satisfying the highest bar for usage guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
remove_changelog_entryAInspect
Permanently remove a single changelog entry (e.g. a test/junk entry added by mistake). Strips the trailing "((n))" marker from content if the removed entry itself carried it, and decrements the lifetime section counter so a removed entry stops inflating it. A marker number is NOT a unique entry id -- appendTo lets many entries share one n as a running thread. If more than one entry shares n, this fails and lists each entry's at timestamp; pass the specific one you mean as at to remove only that entry, not the whole thread. Call get_note first if unsure which entries share a marker.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| n | Yes | The changelog entry number to remove, e.g. 4 for "((4))" | |
| at | No | Optional: the exact `at` ISO timestamp of the specific entry to remove, required when n has more than one entry chained onto it | |
| id | Yes | Note ID |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the irreversible destructive nature, the side effect of stripping the '((n))' marker, and the decrementing of the lifetime section counter. It also explains the failure mode when multiple entries share n, which is critical behavior beyond the schema.
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 front-loaded with the purpose and proceeds logically through side effects, caveats, and remediation. Every sentence adds necessary detail for a tool with nuanced behavior, making it appropriately sized and well structured.
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?
Given the tool's destructive nature, lack of annotations, and absence of an output schema, the description comprehensively covers its behavior: side effects, failure mode, and a suggested pre-step. It fully satisfies the need for contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all parameters with descriptions, but the description adds essential nuance by explaining that n is not a unique ID and that `at` differentiates entries sharing the same n. This enriches parameter understanding beyond the schema's baseline.
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 'Permanently remove a single changelog entry' which clearly states the verb, resource, and scope. It distinguishes from siblings like add_changelog_entry and delete_note by specifying it targets a single entry within a note, not the note itself.
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?
The description provides concrete usage guidance including when to pass `at` for disambiguation and recommends calling `get_note` first if unsure about shared marker numbers. It does not explicitly mention alternatives for other scenarios, but the get_note reference and the handling of ambiguous cases serve as effective direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
remove_labelBInspect
Remove a label from a note
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Note ID | |
| label | Yes |
TDQS
B3.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the bare operation without explaining side effects, error handling, idempotency, or permissions, leaving the tool's behavior largely opaque.
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 short sentence that communicates the essential action without any wasted words. It is perfectly concise and front-loaded.
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?
For a mutation tool with no annotations and no output schema, the description is too sparse. It does not address what happens if the label or note doesn't exist, whether prior conditions are required, or what the result is, making it incomplete for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 50% coverage (only 'id' is described). The description does not add any meaning to the 'label' parameter beyond its name, nor does it clarify constraints or formatting. It fails to compensate for the missing schema description.
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 clearly states the specific action ('Remove a label') on a specific resource ('a note'), distinguishing it from sibling tools like add_label. It is unambiguous and uses a strong verb+resource structure.
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 does not explicitly state when to use this tool versus alternatives such as add_label. The intended usage is implied by the tool name and description, but there is no guidance on exclusions, alternatives, or edge cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
set_item_indentAInspect
Change an existing checklist item's nesting depth, matched by text (case-insensitive, whole-item match, not substring). 0 = top level, 1 = nested one level, etc. Fails with an error if no item matches — call get_note first if you're not sure of the exact wording.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Note ID | |
| item | Yes | Text of the item to reindent (case-insensitive, must match a full item, not a fragment) | |
| indent | Yes | New nesting depth, 0 = top level |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It discloses the exact matching semantics (case-insensitive, whole-item, not substring), the error behavior on no match, and the meaning of indent values (0 = top level). Missing is whether the operation is reversible or has side effects on siblings, but for a simple mutation tool, this is largely sufficient, hence a 4.
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 three concise sentences, with the core action stated first, followed by precise matching rules and an important note about failure and fallback. Every sentence adds value with no redundancy or filler.
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?
Given the tool's simplicity (3 required params, no output schema, no nested objects), the description covers the essential operational aspects: what it changes, how matching works, and what happens when there's no match. It could mention potential side effects like renumbering, but that is not critically missing for correct invocation. Hence a 4.
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% and the schema already explains the item parameter (case-insensitive, full match) and indent (0 = top level). The description's added context about matching and error conditions does not introduce new semantic clarification for parameters beyond what the schema provides. Baseline 3 for high coverage is appropriate.
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 clearly states the verb ('Change'), the resource ('existing checklist item's nesting depth'), and the precise matching criteria (case-insensitive, whole-item, not substring). This is distinct from sibling tools like check_item or add_checklist_item, so an agent can immediately tell what it does and how it differs.
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?
It explicitly explains when to use it (to reindent an existing item), and provides a clear precondition: if unsure the exact wording, call get_note first because it fails when no match. This is direct guidance on correct invocation and a fallback action, exceeding basic use-case statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
uncheck_itemAInspect
Uncheck a checklist item in a note, matched by text (case-insensitive, whole-item match, not substring). Fails with an error if no item matches — call get_note first if you're not sure of the exact wording.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Note ID | |
| item | Yes | Text of the item to uncheck (case-insensitive, must match a full item, not a fragment) |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses matching semantics, error on no match, and a prerequisite. However, it does not specify behavior for multiple matches or idempotency when the item is already unchecked.
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?
Two sentences, front-loaded with the action, and no wasted words. Every phrase adds meaning.
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 simple 2-parameter tool with no output schema, the description covers the action, matching behavior, error case, and a fallback. Minor gaps about multiple matches and return value keep it from a 5.
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% for both parameters, and the description repeats the item-matching details already in the schema. No additional parameter insight is provided beyond the schema, so baseline 3 is appropriate.
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 clearly states the verb 'Uncheck' and the resource 'a checklist item in a note', with explicit matching rules (case-insensitive, whole-item match). This fully differentiates it from siblings like check_item or add_checklist_item.
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?
The description provides concrete guidance by advising to call get_note first if unsure of exact wording, and notes the error condition. It does not explicitly contrast with check_item, but the usage context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_noteAInspect
Update an existing note. Only the fields you pass are changed — omitted fields keep their current value, except labels, which is a full replace (see below). content, if passed, overwrites the whole body; use append_to_note instead if you only want to add text.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| color | No | Note color | |
| title | No | ||
| labels | No | Replaces the full label list, not additive — omitting an existing label removes it. Use add_label/remove_label instead if you only want to change one label without touching the rest. | |
| pinned | No | Pin or unpin the note | |
| content | No | 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. | |
| archived | No | Archive or unarchive the note | |
| reminderAt | No | ISO datetime for a due reminder, or null to clear it. 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. |
TDQS
A4.8/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. It discloses partial update semantics, label full-replace behavior, content overwrite, reminder clamping, exact markdown/checkbox formatting rules, and unsupported markdown — a very thorough transparency disclosure.
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 long, but every sentence carries useful information — no filler. Core behavior and alternatives are front-loaded, with detailed formatting rules placed under the content parameter where they belong. The length is justified by the complexity of content formatting requirements.
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?
Given 8 parameters and no annotations, the description is remarkably complete: it covers update semantics, label behavior, timezone handling, markdown syntax, and unsupported features. An agent has everything needed to call this tool correctly without further inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, so baseline is 3. The description adds value beyond schema: it clarifies the semantics of omitted fields, label replacement, and reminderAt timezone handling. It repeats some schema content (labels, content formatting) but also adds the important partial-update context that the schema doesn't convey.
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 'Update an existing note' — a clear verb+resource statement. It distinguishes itself from siblings by explicitly naming append_to_note for adding text and add_label/remove_label for single-label changes, so an agent can immediately tell what this tool is for and what it is not.
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?
Provides explicit when-to-use guidance: partial updates, full replace for labels, and direct alternatives ('use append_to_note instead...', 'Use add_label/remove_label instead...'). It also instructs calling get_settings first for timezone conversion on reminderAt — concrete prerequisites and routing to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
5 tool updates
- Changed
add_checklist_item1 field changed- added
Input schema / properties / indentAdded value: +{ + "description": "Nesting depth, 0 = top level (default), 1 = one level nested under whatever item precedes it, etc.", + "type": "number" +}
- Changed
append_to_note1 field changed- changed
Input schema / properties / content / descriptionPrevious 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."
- Changed
create_note1 field changed- changed
Input schema / properties / content / descriptionPrevious 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."
- Added
set_item_indent - Changed
update_note1 field changed- changed
Input schema / properties / content / descriptionPrevious 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."
1 tool update
- Changed
add_changelog_entry1 field changed- added
Input schema / properties / atAdded value: +{ + "description": "Optional ISO 8601 timestamp to backdate this entry to when the real-world event actually happened, instead of the moment this tool call runs — e.g. logging a reply that was posted on X two days ago should carry that post's actual date, not today's, since \"day\"/\"week\" goal progress reads this field. Defaults to now if omitted.", + "type": "string" +}
1 tool update
- Changed
remove_changelog_entry1 field changed- added
Input schema / properties / atAdded value: +{ + "description": "Optional: the exact `at` ISO timestamp of the specific entry to remove, required when n has more than one entry chained onto it", + "type": "string" +}
1 tool update
- Added
remove_changelog_entry
1 tool update
- Changed
add_changelog_entry3 fields changed- changed
Input schema / properties / anchor / descriptionPrevious value: -"Optional: text of the line to mark with ((n)). Substring match, case-insensitive."New value: +"Optional: text of the line to mark with a new ((n)). Substring match, case-insensitive. Ignored if appendTo is set." - added
Input schema / properties / appendToAdded value: +{ + "description": "Optional: an existing changelog entry number (e.g. 3 for \"((3))\") to append this as another comment/update under, instead of creating a new marker. Fails if that entry number doesn't exist.", + "type": "number" +} - added
Input schema / properties / sectionAdded value: +{ + "description": "Optional free-text label grouping this entry (e.g. \"update\", \"note\") — useful when a marker accumulates entries from different threads.", + "type": "string" +}
1 tool update
- Added
add_changelog_entry
3 tool updates
- Changed
check_item1 field changed- changed
Input schema / properties / item / descriptionPrevious value: -"Exact text of the item to check"New value: +"Text of the item to check (case-insensitive, must match a full item, not a fragment)"
- Changed
uncheck_item1 field changed- changed
Input schema / properties / item / descriptionPrevious value: -"Exact text of the item to uncheck"New value: +"Text of the item to uncheck (case-insensitive, must match a full item, not a fragment)"
- Changed
update_note1 field changed- changed
Input schema / properties / labels / descriptionPrevious value: -"Replaces the full label list"New value: +"Replaces the full label list, not additive — omitting an existing label removes it. Use add_label/remove_label instead if you only want to change one label without touching the rest."
2 tool updates
- Changed
create_note1 field changed- added
Input schema / properties / reminderAtAdded 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" + ] +}
- Changed
update_note1 field changed- changed
Input schema / properties / reminderAt / descriptionPrevious value: -"ISO datetime for a due reminder, or null to clear it"New value: +"ISO datetime for a due reminder, or null to clear it. 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."
13 tool updates
- First observed
add_checklist_item - First observed
add_label - First observed
append_to_note - First observed
check_item - First observed
create_note - First observed
delete_note - First observed
get_my_tasks - First observed
get_note - First observed
get_settings - First observed
list_notes - First observed
remove_label - First observed
uncheck_item - First observed
update_note
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Markdown-based note-taking with a hosted MCP server. Your notes serve you and your AI.
- TaprootOAuthcom.taproothq
Persistent memory layer for AI tools. Save and recall notes across Claude and other MCP clients.
MCP-native notes and memory for ChatGPT, Claude, and other AI tools.
Agent-native notes, tasks, dev-docs, vaults, sync & handoffs. MCP + OpenAPI dual surface.
Related MCP Servers
- AlicenseAqualityDmaintenanceA simple note-taking MCP server for recording and managing notes with AI models.42236GPL 2.0
- AlicenseNot gradedqualityCmaintenanceA local notes app that enables AI tools to manage notes via MCP (list, get, create, update, delete) using the same SQLite database as the GUI.16MIT
- FlicenseNot gradedqualityCmaintenanceMCP server for a full-stack note-taking application, exposing CRUD tools for notes with SSE transport for AI agent integration.1-
Try in Browser
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.