notes-mcp

by eliotshea

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes, but read_note and read_checklist both expose checklist state, and the trio of clear_checklist, check_all_items, and set_checklist_items operate on checklists in overlapping ways. Descriptions clarify the differences, so ambiguity is low but not zero.
Naming Consistency5/5
All tool names use lowercase snake_case with a clear verb_noun pattern (e.g., read_note, create_folder, list_notes). The pattern is consistent across the entire set, with only minor variations like append_to_note, which still follows the same structural style.
Tool Count5/5
With 15 tools, the server sits at the upper boundary of the ideal range but remains well-scoped. Every tool covers a distinct operation relevant to notes and folder management, and none feel redundant or unnecessary.
Completeness4/5
The note lifecycle is well covered with create, read, append, replace, and delete, and checklist operations are comprehensive. However, folder management is incomplete—there is no way to rename or delete folders—and there is no direct way to restore notes from Recently Deleted, which is a minor gap.
Average 3.8/5 across 15 of 15 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It only says 'Create a new folder,' omitting any side effects, permissions, or error conditions. This is minimal behavioral transparency.
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, concise sentence, which is structurally efficient. However, it is under-specified, providing no additional value beyond the tool name.
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?
Given the lack of annotations, output schema, and parameter documentation, this description is insufficient for an agent to use the tool correctly. It lacks context about folder creation location, required account, or naming constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (name, account) with zero description coverage, and the description does not explain either parameter. The agent cannot infer what 'account' refers to or what format 'name' should take.
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 clearly states the tool creates a folder, using a specific verb and resource. It distinguishes from sibling tools like create_note, though it lacks any contextual qualifiers. Overall purpose is clear but minimal.
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?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It simply states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It implies a mutating operation on a note but does not state that it permanently changes items, what happens if the note is missing, or how the 'force' parameter affects behavior. No side effects or reversibility are mentioned.
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 a single sentence of seven words, containing no fluff or redundant information. It is appropriately front-loaded and easy to parse. However, it may be too terse, sacrificing needed details for brevity, though this is still acceptable.
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 simple mutation tool with two parameters and no annotations, the description is incomplete. It does not explain the 'force' parameter, any return behavior, or failure modes. The presence of similar sibling tools increases the need for clearer context, which is missing.
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 description provides no information about the parameters 'note' and 'force'. Schema coverage is 50% (only 'note' has a description), and the description does not compensate for the undocumented 'force' parameter. An agent cannot infer the role or valid values of 'force' from this description.
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 uses a specific verb ('Check') and resource ('every checklist item in a note'), clearly identifying the tool's primary action. However, 'check' could mean 'mark as complete' or 'inspect', adding slight ambiguity. It does not distinguish from sibling tools like set_checklist_items, but the resource is specific enough.
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 is provided for when to use this tool versus alternatives like set_checklist_items or clear_checklist. The description does not mention exclusions, prerequisites, or typical use cases, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states the action without disclosing side effects, error handling, reversibility, or whether the folder must pre-exist. For a mutation tool, this is severely lacking.
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 zero filler. It is appropriately concise, though it sacrifices completeness for brevity.
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?
The tool is simple, but the description is too sparse given the absence of annotations and output schema. It omits behavioral context, error conditions, and preconditions, leaving the agent without essential guidance beyond the parameter schema.
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 fully describes both parameters (note name/id, destination folder name), and the description adds no additional meaning. Since schema coverage is 100%, the baseline is 3, and the description does not enhance it.
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 'Move a note to a different folder' clearly states the action (move), the resource (note), and the target (different folder). It distinguishes from sibling tools like create_note or delete_note, even though it lacks detail about the process.
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?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites (e.g., folder must exist) or exclusions. It is a bare statement with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the soft-delete behavior ('goes to Recently Deleted and can be restored') and the safety mechanism ('Requires confirm: true so it cannot fire accidentally'), which are important side effects and safety traits. However, it doesn't mention potential effects on related data (e.g., checklist items) or authorization requirements.
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 short sentences, each earning its place: the action, the soft-delete behavior, and the confirm requirement. It is front-loaded with the verb and resource, making the purpose immediately clear. No redundant information or fluff.
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 the simplicity of the tool (two params, no output schema, no annotations), the description is mostly adequate. It covers the key behavioral aspects (soft delete, confirm) and purpose. However, it omits the return value/response, potential side effects on related items (e.g., checklists), and permission requirements, leaving some gaps for an agent using the 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?
The input schema already describes both parameters (note and confirm) with 100% coverage, so the baseline is 3. The description adds extra meaning by explaining the rationale for confirm ('so it cannot fire accidentally'), which is not fully captured by the schema's 'Must be true to proceed'. This adds value beyond the structured data.
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 clearly states the action ('Delete a note') and the resource (note), which is specific and unambiguous. It doesn't explicitly differentiate from sibling tools, but the action of deletion is distinct enough. The added context about Recently Deleted and confirm requirement further clarifies scope.
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?
The description gives no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites or conditions, nor does it compare with similar tools like move_note or clear_checklist. The usage is implied only by the tool name and the first sentence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It indicates a verification action but does not state whether it is read-only, what occurs on failure, or any side effects. The verb 'Verify' suggests non-destructive behavior, but this is not explicit.
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 sentence that is direct and front-loaded. It contains no unnecessary words and clearly conveys the tool's purpose.
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?
The tool is simple with no parameters and no output schema, but the description does not mention what the tool returns or how to interpret the verification result. Without an output schema, a hint about the response format would make it more complete.
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 input schema has zero parameters, so the baseline is 4 per the rubric. The description correctly omits parameter information, as there are none to explain.
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 the verb 'Verify' and specifies the exact resources checked: 'Notes automation access' and 'bridge shortcuts'. This distinguishes it from sibling tools that operate on notes content.
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 the tool is used to confirm setup, but it does not explicitly state when to use it versus alternatives or provide exclusions. As there are no sibling tools with similar functionality, the implied usage is clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It discloses a key behavioral trait: Notes itself converts markdown, turning checklist syntax into real checkboxes. However, it omits other relevant behaviors such as failure on title collision (schemas say 'must not collide' but not what happens), return values, or permission requirements, leaving gaps in 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?
The description is extremely concise: two sentences. The first sentence delivers the core purpose, and the second adds a valuable behavioral nuance. Every word earns its place, and the structure is front-loaded and reader-friendly.
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?
The tool is simple, but with no output schema and no annotations, the description must provide more context. It explains markdown conversion but does not address collision behavior, success/failure indicators, or when to choose create_note over other write tools. It is minimally acceptable but has clear gaps in 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 covers all parameters (100% description coverage), providing a baseline of 3. The description adds extra meaning for the 'markdown' parameter by explaining how checklist syntax is converted into functional checkboxes, which is not evident from the schema's 'Body content in Markdown' description. This elevates the parameter semantics beyond the 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 starts with 'Create a note,' a specific verb+resource that clearly distinguishes this tool from siblings like append_to_note, replace_note_content, and delete_note. It also adds a concrete detail about Markdown-to-checklist conversion, which further sharpens the tool's unique function.
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 (creating new notes) but does not explicitly state when to use this tool versus alternatives like append_to_note or replace_note_content. There is no mention of exclusions, prerequisites, or comparison to sibling tools, so guidance is merely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the key behavioral trait that only metadata is returned, not content, which is a critical non-obvious trait. However, it does not mention pagination, ordering, or other limitations.
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 extremely concise: two short sentences with no wasted words. It front-loads the primary purpose and the most important 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?
The description covers the search scope and return type, but since there is no output schema, the exact metadata fields are unspecified. Additionally, no guidance on when to choose this over list_notes or read_note is provided. It is minimally adequate but leaves gaps.
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 already documents query and titles_only with descriptions. The description clarifies the default search scope (both titles and body), which adds context for titles_only. However, the limit parameter lacks a schema description and is not addressed in the 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 tool performs full-text search across note titles and body text, and explicitly notes it returns metadata not content. This distinguishes it from siblings like read_note (content retrieval) and list_notes (listing).
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 finding notes by search terms, but does not explicitly mention alternatives or when not to use it. The 'metadata, not content' note gives some guidance, but lacks direct sibling comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 transparently explains the core behavior: all items are unchecked and the items themselves remain. However, it does not disclose the force parameter's implication about potential rich-content loss, nor any persistence or side-effect details, which are meaningful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences, front-loaded with the action and followed by a concrete use case. No wasted words or redundant information.
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 operation with full schema coverage and no output schema, the description provides sufficient context for tool selection and invocation. It could mention the force behavior, but the absence is not critical given the schema documents it and the core behavior is well described.
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 baseline is 3. The description does not reiterate parameter details, but the schema already fully documents 'note' and 'force.' The description's mention of 'checklist item' adds minimal extra semantic value.
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 exact action ('Uncheck every checklist item in a note') and the resource ('a note'). It differentiates from siblings like check_all_items by specifying 'uncheck' and noting that items are left in place, making its 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 explicitly provides usage context: 'Use this to reset a recurring checklist, e.g. after a workout.' It does not name alternatives or exclusions, but the scenario is clear enough for an agent to know when to invoke this tool over similar checklist-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 the core operations (check, uncheck, toggle) and selection methods, but does not mention side effects, permissions, error handling (e.g., no matching items), or reversibility. This is a minimum viable disclosure 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the action, target, and selection methods with no wasted words. It is concise and appropriately structured.
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?
The tool has 6 parameters, no annotations, and no output schema. The description covers the essential action and selection methods but leaves gaps such as the 'force' parameter's role and expected return values. This is adequate but not fully complete.
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 83%, so the schema already describes most parameters. The description adds value by linking indices to read_checklist and clarifying that text matching can be exact or contains-based. This goes beyond the schema's brief descriptions, though the undocumented 'force' parameter remains unexplained.
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 action: 'Check, uncheck, or toggle specific checklist items.' It also specifies the selection methods (by index or by matching text), which distinguishes it from siblings like check_all_items. This gives a specific verb+resource that is not a tautology.
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 when to use this tool: for specific checklist items rather than all items. It references read_checklist for indices, which provides context on how to obtain input. However, it does not explicitly exclude alternatives or state when not to use it, so it falls slightly 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses that the operation is non-destructive ('leaving existing content untouched') and that checklist formatting is transformed ('- [ ] item' becomes a real checklist item). This covers key behavioral traits for a simple append 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?
Two concise sentences. The first sentence front-loads the core action and scope, the second adds a meaningful example of special behavior. No filler or repetition.
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 low-complexity tool with two params and no output schema, the description adequately covers its purpose, non-destructive nature, and one notable edge case. It omits error behaviors (e.g., note not found) but these are not critical given the straightforward action.
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%, with both parameters already documented ('Note name (exact) or note id' and 'Markdown to append'). The description adds no new parameter-level semantics; the checklist behavior applies to the markdown parameter but is more behavioral than parameter-specific, 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?
Description clearly states the verb 'Append', the resource 'note', and the specific scope 'to the end'. It also distinguishes itself from replace-style tools by noting 'leaving existing content untouched', and adds the unique behavior of converting checklist syntax to real checklist 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?
The phrase 'leaving existing content untouched' implicitly contrasts with replace_note_content, but the description does not explicitly name alternatives or provide when-not guidance. It gives clear context for its intended use case without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the default exclusion of Recently Deleted (a behavioral trait) and mentions the inclusion of note counts. It does not describe format or ordering, but for a simple read-only list tool, this is sufficient. The description adds value 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?
Two sentences, front-loaded with the core function, and no filler. Every phrase earns its place: the first states what it does, the second clarifies a default behavior.
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 tool with one optional parameter and no output schema, the description is complete enough: it specifies the resource, the inclusion of counts, and the default exclusion. It does not mention ordering or edge cases, but these are not critical for a listing 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 description coverage is 100%, so baseline is 3. The description adds meaning by stating the default exclude behavior, which clarifies the include_deleted parameter's default (false). This provides useful context beyond the schema's simple 'Include Recently Deleted'.
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 'List all Notes folders with note counts' uses a specific verb (List), identifies the resource (Notes folders), and adds output detail (note counts), clearly distinguishing it from sibling list_notes. The additional 'Recently Deleted is excluded by default' scopes the operation unambiguously.
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?
Usage is implied: when you need a list of folders with counts, use this tool. However, there is no explicit when-not-to-use guidance or mention of alternatives like list_notes. The context suggests it but does not state it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 implies non-destructive behavior via 'read' and discloses the return structure (checked state, indices, nesting depth). It doesn't cover error handling or permissions, but for a read-only tool 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 a single concise sentence that leads with the core action and includes key output details without any unnecessary words.
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?
Despite lacking an output schema, the description specifies the essential return fields (checked state, indices, nesting depth). The tool is simple with one parameter, so this is adequate, though it could mention edge cases like notes without checklists.
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 provides a full description of the 'note' parameter (exact name or id, uniqueness requirement), so the description adds no extra parameter semantics. Baseline is 3 due to 100% schema 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 identifies the action (read) and the resource (checklist items of a note), and specifies the output fields (checked state, indices, nesting depth). It distinguishes this tool from siblings like read_note, which reads the full 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?
The phrase 'just the checklist items' implies exclusion of other note content, signaling when to use this tool over read_note. However, it does not explicitly name alternatives or state when not to use it, so it falls short of explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains the output format for checklist items (◦, ✓, ⁃) and nesting depth, and notes the exclusive access to checked state. It does not explicitly state read-only behavior, but the verb 'Read' and context imply no side effects.
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 sentences, front-loaded with the primary action, and every sentence adds value—covering purpose, output formatting, and unique capability. No wasted words.
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 one-parameter read tool with no output schema, the description adequately covers what the tool returns (full content, checklist markers, nesting depth). It also provides a key contextual note about checked state. Minor gaps like error behavior are not critical for this simple 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 input schema already provides 100% coverage with a clear description of the 'note' parameter (exact name or id, uniqueness). The tool description adds no additional parameter semantics beyond what the schema states, so the 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 ('Read a note's full content'), identifies the specific resource (note), and distinguishes it from siblings by highlighting the checklist marker representation and the fact that it is the only way to observe checked state.
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 when to use this tool: whenever full note content or checked state is needed. It explicitly says 'This is the only way to observe checked state,' which guides selection over alternatives like read_checklist. However, it does not name alternatives directly or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses preservation behaviors (keeps id, folder, creation date) and the refusal condition with force override. It does not mention irreversibility or error responses, but the core mutation behavior is reasonably transparent.
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 primary action and preservation behavior. Every word earns its place with no 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?
Covers the operation, what is preserved, and the refusal condition. Lacks error responses or return values, but given no output schema and moderate complexity, it is sufficiently complete for an agent to use the tool correctly.
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 coverage is 100%, so baseline is 3. The description adds a bit of meaning for force (overrides refusal) beyond the schema's 'Proceed even if rich content would be lost', but adds no new semantics for note or markdown.
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?
States clearly it replaces a note's entire body with new Markdown, preserving id, folder, and creation date. This specific verb+resource combination distinguishes it from siblings like append_to_note and create_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?
Describes the replace use case explicitly and mentions a key condition (refuses if attachments/tables unless force is set). However, it does not explicitly state when to prefer this over append_to_note or other alternatives, nor any exclusions beyond that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It proactively states that it is fast, does not read note content, and excludes Recently Deleted by default. This is valuable beyond a simple 'list' statement, though it omits details like return format or auth requirements.
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, front-loaded with the core purpose and each sentence adding a distinct, useful detail (speed, no content read, default filter). There is no redundant or filler language.
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 straightforward listing tool with no output schema, the description covers key aspects: what it lists, performance, and default filter behavior. It specifies 'folder and timestamps' as return fields but may omit other fields like note name/ID, leaving slight ambiguity. Still, it provides sufficient context for an agent to select and invoke correctly.
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 by clarifying the default value of include_deleted ('Recently Deleted is excluded by default'), which is not in the schema. It also implies that folder is a filter, though this is already described. This extra context justifies above 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 states 'List all notes with their folder and timestamps', which clearly specifies the verb (list), resource (notes), scope (all), and output fields. It distinguishes from siblings like read_note (content) and search_notes by explicitly noting it does not read content, making the purpose unmistakable.
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 phrase 'Fast; does not read note content' gives clear context for when to use this tool—when only metadata is needed without reading contents. It also explains the default exclusion of Recently Deleted, which sets usage expectations. However, it does not explicitly name alternative tools or when-not-to-use scenarios, 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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![notes-mcp MCP server](https://glama.ai/mcp/servers/eliotshea/notes-mcp/badges/card.svg)](https://glama.ai/mcp/servers/eliotshea/notes-mcp)

Score Badge

Copy to your README.md:

[![notes-mcp MCP server](https://glama.ai/mcp/servers/eliotshea/notes-mcp/badges/score.svg)](https://glama.ai/mcp/servers/eliotshea/notes-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/eliotshea/notes-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server