notes-mcp

by sheimaz

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct operation: create, update, delete, get, search, and list tags. There is no overlap or ambiguity between them.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (create_note, update_note, delete_note, get_note, search_notes, list_tags). This makes the API predictable and easy to navigate.
Tool Count5/5
Six tools is an appropriate scope for a notes management server, covering core CRUD, search, and tag listing without unnecessary bloat or sparse coverage.
Completeness4/5
The tool surface provides complete CRUD for notes (create, read, update, delete) plus search and tag listing. A minor gap is the lack of an explicit 'list all notes' tool, but search_notes likely can serve this purpose with empty query.
Average 3.8/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

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 behavioral burden. It discloses a key behavior: 'Only the fields you pass are changed' (partial update), which is genuinely useful. However, it does not mention error cases, authentication requirements, return value, or whether the operation is reversible, leaving notable gaps.
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 main action ('Update an existing note by id') and a concise explanation of partial update. There is no redundant or filler content.
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?
With no annotations and no output schema, the description is minimal for a mutation tool. It does not explain the success/failure behavior, whether the updated note is returned, or what happens if the id does not exist. This is a significant gap in context for an agent deciding whether and how to invoke the tool.
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?
Only 25% of parameters have schema descriptions (only id), and the description does not compensate by explaining body, tags, or title semantics. It only generically refers to 'the fields you pass', which is behavioral rather than parameter-specific. The partial update hint does not clarify what each field means or how it will be used.
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 'Update an existing note by id', which uses a specific verb and resource, and it is easily distinguished from sibling tools like create_note, delete_note, and get_note. The partial-update behavior is also clarified with 'Only the fields you pass are changed'.
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 when to use the tool (when you have an existing note id and want to change it), but it doesn't explicitly mention alternatives or exclusions. The partial-update note adds some usage context, but there is no direct guidance contrasting it with delete_note or create_note.
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 must carry the behavioral transparency burden. It does add value by noting 'including its full body', which clarifies the return content, and 'Retrieve' implies a read-only operation. However, it does not disclose behavior for missing/nonexistent ids, authentication requirements, or any other edge-case behavior. It provides some transparency but not comprehensive detail.
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, efficiently worded sentence that starts with the verb 'Retrieve' and immediately conveys the action, target, and relevant distinguishing detail ('by id', 'full body'). There is no filler, redundant phrasing, or unnecessary prose, making it highly concise and well-structured.
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 get-by-id tool with only one parameter and no output schema, the description covers the core purpose and return content (full body). It stops short of covering id-not-found behavior or providing pointers to sibling tools like search_notes for alternative retrieval scenarios. Given the low complexity, this is still largely complete, but those omissions keep it from being fully comprehensive.
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 fully describes the 'id' parameter as 'The note id', achieving 100% schema description coverage. The description's 'by id' restates the schema without adding new semantic detail, such as expected format or error behavior. Since the schema provides complete coverage, the baseline of 3 applies, and the description does not elevate param understanding beyond the schema.
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 ('Retrieve'), the resource ('a single note'), the identifier ('by id'), and the scope ('including its full body'). This distinguishes it from sibling tools like create_note and search_notes, which are either mutations or return multiple notes. The mention of 'single' and 'full body' further sharpens the specific purpose.
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 explicit guidance on when to use this tool versus alternatives like search_notes. It does not state when to use it, when not to use it, or mention any alternative tools. The only implicit hint is 'full body', but that is not developed into actionable guidance.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and parameters but does not mention what the tool returns, whether the operation is idempotent, potential side effects, or required permissions. For a mutation tool, this is a notable gap.
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 front-loaded with the core action and includes the key parameters. Every word earns its place, with no redundant information.
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 (3 params, no output schema, no annotations), and the schema covers all parameters, but the description lacks any information about return values or error conditions. Given the lack of annotations and output schema, the description should provide a bit more context to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description merely restates them ('title, markdown body, and optional tags') without adding any deeper meaning or usage details, earning the baseline score.
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 and resource ('Create a new note') and clearly distinguishes from siblings like update_note, delete_note, and get_note. It unambiguously states the action and the primary inputs.
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 clearly implies the tool is for creating new notes, which differentiates it from updating or deleting existing notes. However, it does not explicitly state when not to use it or mention alternatives, but the verb 'create' provides sufficient context.
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 burden of behavioral disclosure. It provides useful details about matching semantics (AND logic) and result ordering, but omits which note fields are searched, case sensitivity, pagination, or any limit behavior.
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, front-loaded with the tool's action, and contains no filler. Every sentence adds meaningful information.
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 there is no output schema, the description should explain return shape more thoroughly. It states 'Returns matching notes newest-first' but does not mention the fields included or any limits, leaving some ambiguity for a potentially large result set.
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 both parameters are already well-documented. The description does not add parameter-level semantics beyond the schema; it only restates the matching logic in a different way.
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 a search over notes, with specific matching rules (all terms must match) and ordering (newest-first). This distinguishes it from sibling tools like get_note (likely single-note retrieval) and list_tags (tag 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 the tool is for searching notes by query and/or tag, but does not explicitly state when to use alternatives like get_note or list_tags. The usage context is clear but exclusions are not mentioned.
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 present, so the description carries the full burden of behavioral disclosure. It clearly states the deletion is permanent, alerting users to its irreversible nature. However, it does not disclose return values, error behavior, or permission requirements, leaving some gaps for a destructive 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 that immediately states the verb and object. It is concise with no wasted words, and the 'by id' qualifier efficiently conveys the required input.
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 (1 parameter, no output schema, no nested objects), the description fully covers the action, target, and permanence. The lack of return-value or error-handling details is a minor gap but not critical for a straightforward delete operation in the context of sibling CRUD tools.
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 provides a full description for the 'id' parameter ('The note id') with 100% coverage. The description's 'by id' reinforces the parameter's role but adds no new semantic information beyond the schema. Baseline 3 applies since the schema carries the burden.
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 a specific verb ('delete'), resource ('note'), and required identifier ('by id'). It clearly distinguishes from siblings like create_note, update_note, and get_note. The word 'permanently' adds important specificity about the operation's effect.
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 when to use the tool (to remove a note) but does not explicitly state when not to use it or name alternatives like update_note or get_note. The permanence warning provides some context, but no direct comparison to sibling tools is given.
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?
The description adds the behavioral nuance that only tags 'currently in use' are returned, which is useful. However, with no annotations provided, it does not disclose other traits such as read-only behavior, sorting, or potential performance implications of scanning all notes.
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, well-structured sentence that leads with the action and resource. Every word contributes meaning 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 zero-parameter tool with no annotations or output schema, the description fully conveys what it does and the scope of the result. The phrase 'list every tag' adequately implies the return value.
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 accepts zero parameters, so the schema provides complete coverage by default. The description adds no parameter-specific meaning, but none is required. The baseline of 4 is appropriate for zero-parameter tools.
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 'List' with the resource 'tags' and a specific scope ('currently in use across all notes'). It distinguishes itself from sibling note-centric tools by focusing exclusively on tag enumeration.
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 context is clear: this is the only tool for listing tags, while siblings handle notes. There are no competing alternatives, so no explicit exclusion is needed. However, it stops short of explicitly stating when to use it over other tools.
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/sheimaz/notes-mcp/badges/card.svg)](https://glama.ai/mcp/servers/sheimaz/notes-mcp)

Score Badge

Copy to your README.md:

[![notes-mcp MCP server](https://glama.ai/mcp/servers/sheimaz/notes-mcp/badges/score.svg)](https://glama.ai/mcp/servers/sheimaz/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/sheimaz/notes-mcp'

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