Nextcloud Notes MCP Server

by rncz

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a distinct purpose with clear boundaries: login check, folder management, note CRUD operations, and listing functions are well-separated. No overlapping functionality exists, making tool selection straightforward for an agent.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern (e.g., create_note, delete_category, list_notes_of_a_category). The naming is uniform and predictable throughout the set, enhancing readability and usability.
Tool Count5/5
With 13 tools, the server is well-scoped for managing notes and categories in Nextcloud. Each tool serves a specific role in the domain, covering essential operations without bloat or redundancy.
Completeness5/5
The toolset provides complete coverage for note and category management, including CRUD operations for both, folder setup, login verification, and listing functions. No gaps are apparent, supporting full agent workflows without dead ends.
Average 3.4/5 across 13 of 13 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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

Behavior1/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 'Delete' without detailing effects (e.g., permanent deletion, no undo), permissions required, error handling, or output behavior. This is inadequate for a destructive operation with zero annotation coverage.
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, efficient sentence with no wasted words, making it front-loaded and easy to parse. It directly conveys the core action without unnecessary elaboration.
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 tool's complexity (destructive operation with 2 parameters), lack of annotations, and 0% schema coverage, the description is incomplete. It doesn't address behavioral risks, parameter usage, or output details, even though an output schema exists. More context is needed for safe and effective 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?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It adds no meaning beyond the schema, failing to clarify what 'filename' and 'category' represent (e.g., file path, optional category for organization) or how they interact. This leaves parameters undocumented.
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 verb 'Delete' and the resource 'a note file inside Notes', making the purpose specific and understandable. However, it doesn't differentiate from sibling tools like 'delete_category' or 'rename_note', which would require mentioning it targets individual note files rather than categories or other operations.
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. It doesn't mention prerequisites (e.g., the note must exist), exclusions (e.g., cannot delete categories), or refer to sibling tools like 'delete_category' for different deletion contexts, leaving usage ambiguous.
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 provided, the description carries the full burden of behavioral disclosure. 'Delete' implies a destructive operation, but the description doesn't specify whether this is permanent, reversible, what happens to notes within the category, or what permissions are required. For a destructive operation with zero annotation coverage, this is a significant gap in 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence with zero wasted words. It's front-loaded with the core action and target. While it may be too brief for completeness, as a standalone statement it's efficiently structured.
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 destructive operation with no annotations, 0% schema coverage, and multiple sibling tools, the description is inadequate. While an output schema exists (which helps with return values), the description doesn't address critical context like what 'delete' means operationally, how it differs from related tools, or parameter requirements. A deletion tool needs more contextual information than this provides.
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?
Schema description coverage is 0%, meaning the single parameter 'category_name' has no documentation in the schema. The description provides no additional information about this parameter - it doesn't explain what constitutes a valid category name, whether case matters, or how to reference existing categories. The description fails to compensate for the complete lack of schema documentation.
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') and target ('a category folder inside Notes'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from similar sibling tools like 'edit_category' or 'delete_note' - it only tells what it does, not how it differs from alternatives.
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 about when to use this tool versus alternatives. With sibling tools like 'edit_category', 'delete_note', and 'list_categories', there's no indication of when deletion is appropriate versus editing or when to check what categories exist first. No prerequisites or exclusions are mentioned.
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. It discloses the destructive behavior ('Always overwrites the old file'), which is critical for a mutation tool. However, it lacks details on permissions, error handling, or response format, leaving significant behavioral 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 extremely concise with two sentences that are front-loaded and waste no words. Every phrase adds value, making it efficient and well-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?
Given the tool's complexity (mutation with 3 parameters), no annotations, and an output schema (which reduces need to describe returns), the description is incomplete. It covers the basic action and destructive nature but misses parameter explanations, usage context, and error handling, making it minimally adequate but with clear gaps.
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?
Schema description coverage is 0%, so the description must compensate. It mentions 'Markdown (.md) file' and 'content', hinting at 'filename' and 'new_content', but doesn't explain 'category' or provide any parameter-specific details beyond what's implied. This is insufficient for 3 parameters with no schema documentation.
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 ('Edit'), resource ('a Markdown (.md) file'), and effect ('updating its content'), distinguishing it from siblings like 'create_note' or 'rename_note'. However, it doesn't explicitly differentiate from 'read_note' or 'delete_note' beyond the verb, which keeps it from a perfect score.
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 minimal guidance: 'Always overwrites the old file' implies a destructive update, but it doesn't specify when to use this tool versus alternatives like 'create_note' for new files or 'rename_note' for renaming. No explicit when-not-to-use or prerequisite context is given.
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 full burden. It mentions 'creating a subdirectory', which hints at a mutation operation, but doesn't disclose behavioral traits like permissions needed, whether it overwrites existing categories, error handling, or rate limits. This leaves significant gaps for a tool that modifies data.
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, efficient sentence that front-loads the purpose ('Create a new category') and adds clarifying detail ('inside Notes by creating a subdirectory'). Every word earns its place with no redundancy 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 tool has 1 parameter, no annotations, and an output schema exists (which covers return values), the description is minimally adequate. However, as a mutation tool with no behavioral disclosure, it lacks completeness regarding how the operation works, potential side effects, or integration with sibling tools like 'list_categories'.
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 0%, so the description must compensate. It doesn't add any meaning beyond the schema, which only shows 'category_name' as a required string. No details on format, constraints, or examples are provided. With 1 parameter and no schema descriptions, the baseline is 3 as it doesn't worsen understanding but adds no value.
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 ('Create a new category') and the resource ('inside Notes'), with the specific mechanism 'by creating a subdirectory'. It distinguishes from siblings like 'edit_category' or 'delete_category' by specifying creation. However, it doesn't explicitly contrast with 'ensure_notes_folder_exists', which might be related.
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 explicit guidance on when to use this tool versus alternatives like 'edit_category' for modifying existing categories or 'ensure_notes_folder_exists' for setup. The description implies usage for creating new categories but lacks context on prerequisites, such as whether the parent directory must exist.
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 of behavioral disclosure. It usefully adds that the tool 'Overwrites the target if it already exists,' which is a critical behavioral trait not inferable from the schema. However, it lacks other important details like permission requirements, error handling (e.g., if the note doesn't exist), or whether the rename is atomic/reversible. This partial disclosure earns a baseline 3.
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 with zero wasted words. The first sentence states the purpose, and the second adds crucial behavioral context. It's front-loaded and efficiently communicates essential information without 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 tool's moderate complexity (3 parameters, mutation operation) and the presence of an output schema (which likely covers return values), the description is partially complete. It covers the core action and a key behavioral trait but misses parameter semantics and usage guidelines. With no annotations, it should do more to compensate, making it only minimally adequate.
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?
Schema description coverage is 0%, so the description must compensate but fails to do so. It doesn't explain any parameters—what 'filename' and 'new_filename' represent (e.g., paths, basenames), what 'category' means, or format constraints (e.g., .md extension). The agent must rely solely on schema titles, which are minimal. This is inadequate given the coverage gap.
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 ('Rename') and resource ('a Markdown (.md) note inside Notes or a category'), making the purpose immediately understandable. It distinguishes the tool from siblings like 'edit_note' (which likely modifies content) and 'create_note' (which creates new notes). However, it doesn't explicitly differentiate from all siblings (e.g., 'edit_category' might also involve renaming), so it's not a perfect 5.
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. It doesn't mention prerequisites (e.g., the note must exist), compare to similar tools like 'edit_note' for content changes, or specify scenarios where renaming is appropriate versus creating/deleting. The agent must infer usage from context alone.
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. It states the tool checks login success and returns a message, but lacks details on authentication requirements, error handling, rate limits, or what the success/failure messages contain. For an authentication tool with zero annotation coverage, this is insufficient behavioral disclosure.
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 with zero waste: it states the purpose and the return value. It's front-loaded and appropriately sized for a simple tool, with every sentence earning its place.
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 tool's simplicity (0 parameters, output schema exists), the description is minimally adequate. However, as an authentication tool with no annotations, it should provide more context on authentication mechanisms or error cases. The output schema likely covers return values, so that gap is mitigated, but behavioral aspects are under-specified.
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 0 parameters, and schema description coverage is 100%. The description doesn't need to add parameter semantics, so it meets the baseline. No compensation is required, and it appropriately doesn't discuss parameters.
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's purpose: 'Check if WebDAV login is successful.' It specifies the verb ('Check') and resource ('WebDAV login'), making the intent unambiguous. However, it doesn't differentiate from sibling tools, which are all note/category management tools unrelated to authentication, so no sibling distinction is needed or provided.
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. It doesn't mention prerequisites (e.g., needing credentials), context for invocation, or exclusions. The sibling tools are unrelated, so no explicit comparison is given, but general usage context is missing.
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 states this is a rename operation, implying mutation, but lacks details on permissions needed, error handling (e.g., if 'old_name' doesn't exist), side effects (e.g., whether notes in the category are affected), or rate limits. For a mutation tool with zero annotation coverage, this is a significant gap 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 highly concise and well-structured, with a clear purpose statement followed by brief parameter explanations. Every sentence earns its place by directly contributing to understanding the tool's function and inputs, with no redundant or vague language.
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 tool's moderate complexity (a mutation operation with 2 parameters), no annotations, and the presence of an output schema (which handles return values), the description is minimally adequate. It covers the basic action and parameters but lacks behavioral context like error conditions or side effects, leaving gaps for the agent to navigate without full guidance.
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 description adds meaningful semantics beyond the input schema, which has 0% description coverage. It explicitly defines 'old_name' as 'Current name of the category' and 'new_name' as 'New name for the category', clarifying their roles and intent. With only 2 parameters and no schema descriptions, this compensates well, though it doesn't cover constraints like name length or allowed characters.
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 verb ('Rename') and resource ('an existing category inside Notes'), making the purpose specific and understandable. It distinguishes from siblings like 'create_category' and 'delete_category' by focusing on modification rather than creation or deletion. However, it doesn't explicitly contrast with 'rename_note', which might cause some ambiguity in sibling differentiation.
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. It doesn't mention prerequisites (e.g., the category must exist), when not to use it (e.g., for non-existent categories), or direct alternatives among siblings (e.g., 'create_category' for new categories). The agent must infer usage from the tool name and parameters alone.
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. It states what the tool does but lacks behavioral details such as whether it requires authentication, how it handles errors (e.g., if /Notes doesn't exist), the format of the output (though an output schema exists), or any rate limits. This is a significant gap for a tool with zero annotation coverage.
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, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly.
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 tool's low complexity (0 parameters, output schema provided), the description is minimally adequate. However, with no annotations and missing behavioral context (e.g., error handling, prerequisites), it leaves gaps that could hinder an agent's correct invocation, especially for edge cases like missing directories.
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 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter semantics beyond the schema, but with no parameters, a baseline of 4 is appropriate as it doesn't need to compensate for gaps.
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 ('List all categories') and the resource ('directories inside /Notes'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'list_notes_of_a_category' or 'list_uncategorized_notes', which also list content but with different scopes.
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. It doesn't mention prerequisites (e.g., whether /Notes must exist), exclusions, or comparisons to siblings like 'list_notes_of_a_category' for listing notes within a specific category.
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 key behavioral traits: it creates a file with Markdown format and specifies storage paths based on category. However, it doesn't mention permissions, error handling, or what happens if a file already exists, leaving 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by bullet points that efficiently explain storage rules without wasted words. Every sentence earns its place by adding actionable information, making it appropriately sized and 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?
Given the tool's moderate complexity (3 parameters, no annotations, but with an output schema), the description is fairly complete. It covers the creation action and storage logic, but lacks details on permissions or error cases. The output schema likely handles return values, so this isn't a major gap, but more behavioral context would enhance 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 description coverage is 0%, so the description must compensate. It adds significant meaning beyond the schema by explaining how 'category' affects storage paths (e.g., '/Notes/<filename>' vs. '/Notes/<category>/<filename>'), which clarifies parameter impact. It doesn't detail 'filename' or 'content' specifics, but the path logic is crucial and well-explained.
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 ('Create a new Markdown (.md) note') and resource ('note'), making the purpose immediately understandable. It distinguishes from siblings like 'edit_note' or 'delete_note' by specifying creation. However, it doesn't explicitly differentiate from 'rename_note' in terms of file creation vs. modification, keeping it from a perfect score.
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 through the storage rules (e.g., when to use category vs. not), but doesn't explicitly state when to choose this tool over alternatives like 'edit_note' for updates or 'ensure_notes_folder_exists' for setup. It provides context for parameter usage but lacks clear when/when-not guidance relative to siblings.
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 of behavioral disclosure. It describes the basic operation (reading a file) and return value (content as a string), but lacks details on error handling (e.g., what happens if the file doesn't exist), permissions, or performance aspects. It adds some context but is not comprehensive.
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 appropriately sized and front-loaded, starting with a clear purpose statement followed by structured sections for arguments and returns. Every sentence earns its place by providing essential information without redundancy, making it easy to scan and understand.
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 low complexity (2 parameters, no nested objects) and the presence of an output schema (implied by the 'Returns' section), the description is mostly complete. It covers the purpose, parameters, and return value adequately. However, it could benefit from more behavioral context, such as error handling, to be fully comprehensive.
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 description adds significant meaning beyond the input schema, which has 0% schema description coverage. It explains that 'filename' is the name of the note file with an example ('note1.md') and clarifies that 'category' is an optional folder, defaulting to '/Notes root' if None. This compensates well for the low schema coverage, though it doesn't cover all potential edge cases.
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 verb ('Read') and resource ('a Markdown (.md) file'), making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from potential siblings like 'list_notes_of_a_category' or 'list_uncategorized_notes', which might also involve reading notes but with different scopes or outputs.
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 by specifying that it reads a single note file and mentions an optional category parameter for folder-based reading, but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'list_notes_of_a_category' or 'edit_note'. No exclusions or prerequisites are stated.
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 the key behavioral trait (conditional creation) and the target resource, but does not mention authentication requirements, error handling, or what 'exists' means (e.g., permissions, exact path). It adds some value but lacks comprehensive behavioral details.
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 with two sentences that are front-loaded and waste no words. Every sentence earns its place by stating the purpose and the conditional action directly.
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 (0 parameters, no annotations, but has an output schema), the description is complete enough for basic understanding. It covers what the tool does and its conditional behavior. However, it could benefit from mentioning the output or any side effects for full completeness, though the output schema mitigates this gap.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter details, which is appropriate. A baseline of 4 is applied as it correctly avoids redundancy, though it doesn't enhance parameter 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 tool's purpose with a specific verb ('ensure exists') and resource ('/Notes folder in Nextcloud'), and distinguishes it from siblings like create_category or create_note by focusing on a specific system folder. It explicitly mentions the conditional creation behavior.
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 ('if it doesn't exist') but does not explicitly state when to use this tool versus alternatives like checking folder existence manually or using other folder management tools. It provides clear intent but lacks explicit comparison to sibling 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?
No annotations are provided, so the description carries the full burden. It discloses the tool's scope and file type filtering, which is useful behavioral context. However, it does not mention potential outputs, error conditions, or other behavioral traits like performance or 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 a single, efficient sentence that front-loads the key information with zero waste. It uses clear language and is appropriately sized for the tool's simplicity.
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 low complexity (0 parameters, no annotations, but with an output schema), the description is mostly complete. It explains what the tool does and its scope. However, it could benefit from mentioning the output format or any constraints, though the output schema mitigates this gap.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter details, which is appropriate. Baseline is 4 for 0 parameters, as it avoids redundancy.
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 ('List'), resource ('Markdown (.md) files'), and scope ('directly inside /Notes, not in subfolders'). It distinguishes itself from sibling tools like 'list_categories' and 'list_notes_of_a_category' by focusing on uncategorized files in the root directory.
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 by specifying 'directly inside /Notes (not in subfolders)', which helps differentiate it from tools that might list files recursively or in categories. However, it does not explicitly state when to use this tool versus alternatives like 'list_notes_of_a_category' or provide exclusions.
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 discloses that the tool lists notes from a subfolder, but does not mention behavioral traits like permissions needed, error handling, or whether it's read-only (implied by 'List' but not explicit). It adds basic context but lacks details on limitations or 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 front-loaded with the purpose, followed by clear sections for Args and Returns. Every sentence earns its place with no wasted words, making it efficient and easy to parse.
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 low complexity (1 parameter, no nested objects) and the presence of an output schema (which covers return values), the description is mostly complete. It explains the purpose, parameter, and return format, but could improve by adding more behavioral context (e.g., error cases or prerequisites).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining the parameter's meaning: 'category_name: The subfolder name inside /Notes'. This adds crucial semantics beyond the bare schema, clarifying the parameter's role and format.
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') and resource ('notes in a given category inside /Notes'), specifying the scope and distinguishing it from siblings like list_categories (which lists categories) and list_uncategorized_notes (which lists notes without categories).
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 by specifying 'in a given category inside /Notes', but does not explicitly state when to use this tool versus alternatives like list_uncategorized_notes or list_categories. It provides clear scope but lacks explicit exclusions or named alternatives.
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:

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

Score Badge

Copy to your README.md:

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

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/rncz/nextcloud-notes-mcp-server'

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