nextcloud-mcp

Server Quality Checklist

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

Latest release: v1.3.0
Disambiguation4/5
Tools are mostly distinct, with clear separation between resources (tasks, calendar, notes, mail, files, deck). The only potential overlap is between get_notes and get_note_content, where get_notes might be assumed to return content, but descriptions clarify that get_note_content fetches the full body. Overall, minor ambiguity.
Naming Consistency4/5
All tools follow a verb_noun pattern in snake_case, but the verb for retrieving collections is inconsistent: 'get' for tasks, calendar, notes, and deck boards, but 'list' for files. This minor inconsistency prevents a perfect score.
Tool Count4/5
20 tools is on the high end but appropriate for a multi-app integration covering six distinct Nextcloud apps. Each tool has a clear role, though the count feels heavy for a single server.
Completeness2/5
The server lacks delete operations for any resource type, and calendar events and notes have no update operations. Email support is read-only, which are significant gaps for common workflows.
Average 3.7/5 across 20 of 20 tools scored. Lowest: 2.5/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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action and does not mention side effects, permissions, reversibility, return values, or whether existing notes with the same title are overwritten. This is a significant transparency gap 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, complete sentence that is efficiently worded and front-loaded with the action. It contains no filler, but its brevity results in under-specification rather than concise completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three parameters, no output schema, and no annotations. The description fails to explain parameter behavior, return values, or any other contextual details an agent would need to invoke it correctly. This is a minimal viable description but lacking essential operational context.
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?
Schema description coverage is 0%, and the description does not mention any of the three parameters (title, content, category). It provides no additional meaning beyond the bare schema, so the agent cannot infer what values are expected for content or how the optional title and category behave.
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 specifies the exact action ('Create') and the resource ('a new note') within the Nextcloud Notes app. This clearly distinguishes it from sibling tools like create_task or create_calendar_event, making the tool's 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. While the action is self-explanatory, it does not mention prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name 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?
With no annotations present, the description carries the full burden of behavioral disclosure. It only says 'retrieve all notes' without explaining whether it returns metadata or full content, whether pagination applies beyond the limit parameter, or what fields appear in the response. These are significant gaps for a list operation.
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, front-loaded sentence that directly states the action and target. It is efficient with no wasted words, though slightly too sparse to fully support the other dimensions.
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 simplicity, the description still misses key contextual details: the return format (list of metadata vs. full content), whether the limit parameter applies to the response, and how this relates to the sibling get_note_content tool. This incompleteness could lead to incorrect assumptions.
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%, and the description does not mention the 'limit' parameter at all. The parameter name is somewhat self-explanatory, but the description fails to clarify that 'limit' controls the maximum number of notes returned or how the default of 50 behaves. The description does not compensate for the 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 tool retrieves all notes from the Nextcloud Notes app, using a specific verb and resource. It distinguishes from the sibling get_note_content by indicating a bulk operation ('all notes'), though it does not explicitly name 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?
No guidance is provided about when to use this tool versus alternatives like get_note_content or create_note. The description neither specifies exclusions nor mentions context preferences, leaving the agent to infer from the name and sibling list.
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. It only indicates the action ('create') but does not explain side effects, permission requirements, return values, idempotency, or error behavior—leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately communicates the core purpose without any filler or redundancy. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple create operation, but the description lack essential context such as return behavior, timezone handling, or auth considerations. With no output schema and no annotations, the description is too minimal to be considered complete for real-world usage.
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% and every parameter has a description, so the schema itself provides sufficient meaning. The tool description does not add parameter-specific semantics beyond what is already in the schema, warranting a 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 ('Create') and resource ('calendar event') with clear scope ('in Nextcloud'), effectively distinguishing it from sibling tools like get_calendar_events. It is unambiguous and action-oriented.
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 only states what the tool does and provides no guidance on when to use it vs alternatives, prerequisites, or exclusions. It does not mention any related tools or scenarios where a different tool would be more appropriate.
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 responsibility for behavioral disclosure. It does not mention side effects, required permissions, whether null values clear fields, or what happens to unspecified fields. The only extra cue is 'existing,' which is already implied by 'update.'
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, focused sentence that directly states the action and scope. It contains no filler, redundant phrases, or unnecessary context energy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with six parameters, no annotations, and no output schema, the one-line description is insufficient. It does not cover return values, error cases, prerequisites (e.g., card existence), or the effect on other fields, leaving the agent without enough functional context.
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 covers 100% of parameters with descriptions, so the baseline is 3. The tool description merely restates the updatable fields (title, description, due date) without adding details like the null-to-clear behavior for dueDate, which is already present in 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 uses a specific verb ('Update') and clearly identifies the resource ('an existing Deck card') and the mutable fields ('title, description, or due date'). This distinguishes it from sibling tools like create_deck_card and move_deck_card.
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 relative to alternatives, such as create_deck_card or move_deck_card. It simply states what the tool does, leaving the usage context entirely implicit.
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. 'Create a new task' implies mutation but does not mention potential side effects, required permissions, default values, or what the response contains. This is insufficient for a creating 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, concise sentence that conveys the essential purpose without any filler. It is well-structured and front-loaded.
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?
While the schema thoroughly documents all parameters, the description lacks any detail about return values, error behavior, or side effects. In the absence of an output schema and annotations, the description should provide more context for a mutation tool, making it minimally complete but with clear 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?
Schema coverage is 100% with each parameter described in the schema. The description itself adds no additional meaning beyond the schema fields, which is acceptable given the complete schema coverage, but it does not reinforce or enhance understanding of any parameters.
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 'Create a new task in Nextcloud' clearly states the action (create) and the resource (task), and distinguishes it from sibling tools like get_tasks and update_task. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as update_task or get_calendar_events. There are no explicit use cases, prerequisites, or exclusion criteria.
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?
Annotations are absent, so the description must carry the full burden of behavioral disclosure. It mentions 'Move or rename' but does not disclose potential overwrite behavior, permission requirements, or whether the operation is reversible.
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, direct sentence with zero redundant information. It is appropriately front-loaded and concise.
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?
For a simple 2-parameter tool, the description adequately conveys the core purpose and the schema covers parameter details. However, missing usage guidelines and behavioral transparency leave minor gaps, making it minimally 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?
The input schema fully documents both parameters (fromPath and toPath) with descriptions. The tool description adds no additional parameter context, so the baseline score of 3 applies given 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 states exactly what the tool does: 'Move or rename a file or folder in Nextcloud.' It uses a specific verb and resource, and clearly distinguishes from sibling file tools like get_file, upload_file, and create_folder.
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 about when to use this tool, prerequisites, or alternatives. The description simply states the action without any contextual direction, leaving the agent to infer usage.
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 for behavioral disclosure. It only states 'Retrieve' and 'Can specify date range,' but does not disclose read-only nature, return format, pagination, or any side effects. This is a significant gap for a tool with zero annotation support.
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 short sentences with no redundant wording. It is extremely concise and every word serves a purpose, earning a high score for structure.
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 output schema and annotations, the description is under-specified. It does not mention return value structure, sorting, or any caveats about calendar events. This leaves the agent with insufficient context to understand what the tool actually returns.
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's mention of 'date range' adds no meaning beyond the schema's startDate and endDate descriptions. It does not compensate or provide additional parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve calendar events from Nextcloud', using a specific verb and resource. It distinguishes from sibling tools like get_tasks and create_calendar_event by focusing on calendar events and the retrieval action.
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 retrieving calendar events but provides no explicit context on when to use this tool over alternatives, no exclusions, and no references to sibling tools. It is a generic action statement without guidance.
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 must carry the full burden of disclosing behavior. 'Retrieve' implies a read-only operation, and 'from inbox' scopes the behavior. However, it doesn't specify what 'recent' means, return format, or any prerequisites like authentication. The text is minimal but not misleading.
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 short sentences with no filler. It is front-loaded with the action and quickly states scope. Every word earns its place.
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 has no annotations, no output schema, and schema descriptions are absent. The description only gives a high-level action and scope, but fails to explain parameter semantics or what the returned emails look like. This is inadequate for an agent to reliably invke the tool with correct arguments.
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 schema provides two parameters (limit and accountId) with zero description coverage. The description does not mention these parameters at all, so an agent has no guidance on what values to pass or what they control. This is a critical gap for a tool with undocumented parameters.
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: 'Retrieve emails from Nextcloud Mail app.' It specifies the resource (emails) and the action (retrieve), with scope ('from inbox'). Since all sibling tools are for different domains (tasks, calendar, notes, files, deck), this tool is unambiguously distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool fetches recent inbox emails from the Nextcloud Mail app, making its intended use apparent. There are no sibling email tools, so no explicit alternatives are needed. However, it could explicitly state when not to use it, but this is a minor gap.
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 discloses the important overwrite behavior, which is a key safety aspect. Without annotations, this is the main behavioral trait an agent needs to know. However, it doesn't mention other potential behaviors like permission requirements or whether existing files are replaced atomically.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and target. Every word is necessary, and there is no 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 tool with only two simple parameters and no output schema, the description provides sufficient context: it says what the tool does, that it can overwrite, and where it operates. It could mention behavior when parent folders don't exist, but this is a minor gap given the tool's simplicity.
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 complete descriptions for both parameters (path and content), covering 100% of schema definitions. The tool description adds no additional parameter semantics, but it doesn't need to since the schema is self-explanatory.
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 (create/overwrite) and resource (file in Nextcloud), making the purpose unambiguous. It doesn't explicitly differentiate from sibling tools like create_note, but 'file' versus 'note' is implied and the action is distinct.
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 tool's usage is implied by the description: you use it when you need to write text content to a file. However, there is no explicit guidance on when to choose this over alternatives or any exclusions, such as whether it works for binary files or if parent directories must exist.
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 only states the action without disclosing behavior such as whether intermediate directories are created, what happens if the folder already exists, or any permission requirements. This is a minimal statement that lacks critical behavioral context.
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 states exactly what the tool does with no redundant words. It is front-loaded with the verb and resource, making it highly concise and effective.
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 one well-documented parameter, but the description lacks behavioral details like error handling or side effects. The path example implies nested folder creation, but the description itself does not clarify this. It is minimally adequate for basic use but not comprehensive for edge cases.
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 provides 100% coverage for the single 'path' parameter, including an example. The description adds no additional parameter information. Per the rubric, high schema coverage yields a baseline of 3, and the description does not exceed that.
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 'Create a new folder in Nextcloud' with a specific verb and resource, making it unambiguous what the tool does. It distinguishes itself from sibling create tools by specifying 'folder' in 'Nextcloud', so an agent can easily select it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this when you need to create a folder in Nextcloud. It does not explicitly mention alternatives or exclusions, but the name and resource make the use case obvious. This meets the 'clear context, no exclusions' criterion.
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 merely states the action without mentioning side effects, prerequisites, error behavior, or whether the card is removed from the source stack. This is a significant gap 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 with a relevant example. It is concise, with no wasted words or 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?
For a relatively simple mutation with fully documented parameters, the description is adequate to convey the primary action. However, the lack of annotations and behavioral detail (e.g., validation requirements, return value) leaves some gaps, making it minimally complete rather than 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?
Schema description coverage is 100%, with clear descriptions for all four parameters. The description adds an example but does not provide additional parameter semantics beyond what the schema already offers. 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?
Description clearly states the action ('Move a Deck card') and the resource ('to a different stack'), with a concrete example. This distinguishes it from sibling tools like create_deck_card, update_deck_card, and move_file, which operate on different resources or actions.
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?
Provides clear context for when to use the tool via the example of moving from 'To Do' to 'In Progress'. However, it does not explicitly mention alternatives or exclusions, such as using update_deck_card instead if only card properties change. The context is clear but lacks explicit 'when not to use' 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 must disclose behavioral traits on its own. It mentions 'update' which implies mutation, but does not detail any side effects, prerequisites (like needing the task to exist), or whether it does partial updates. There is no mention of permissions, rate limits, or error behavior. The description is too brief to be transparent about the tool's runtime 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?
A single sentence that is directly informative, with the core verb and resource front-loaded and examples in parentheses. Every word earns its place, with no waste or redundancy.
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 5 parameters and a conditional requirement (listId), but the schema fully documents them. However, with no annotations and no output schema, the description doesn't clarify return values, partial update semantics, or failure behavior, leaving some contextual gaps. It is adequate but not rich enough to fully compensate for missing annotations.
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 provides 100% coverage with descriptions for all five parameters, including relevant details like status enum values and optionality. The description adds minimal extra meaning beyond the schema by giving examples of what 'update' might mean, but doesn't introduce new param semantics. A baseline of 3 is appropriate when schema does the heavy lifting.
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 ('Update an existing task') and provides concrete examples ('mark as complete, change summary'), making it distinct from sibling tools like create_task and get_tasks. It unambiguously identifies the resource (task) and the operation (update).
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: use for modifying an existing task, with examples of common updates. It doesn't explicitly exclude creation or retrieval, but the verb 'update' and phrase 'existing task' clearly distinguish from create_task and get_tasks. No explicit alternatives are named, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 clearly indicates the tool mutates state (creates a card), but it doesn't add context about required permissions, side effects, or what the response contains. The pointer to get_deck_board is helpful but doesn't fully compensate for the lack of behavioral 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 two concise sentences with no redundancy. It front-loads the purpose and includes only the most important additional guidance, making it highly scannable and efficient.
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 relatively simple create tool with a fully documented schema, the description provides the essential prerequisite (getting stack IDs) and sufficient context. It doesn't explain return values or error behavior, but this is acceptable given the tool's simplicity and the lack of an output 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 input schema covers all 5 parameters with descriptions, so the baseline is 3. The description adds a small hint about stackId (that stack IDs come from get_deck_board), which is useful, but it doesn't enhance understanding of the other parameters beyond what the schema already provides.
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 ('Create a new card') and the specific resource ('Nextcloud Deck board stack (column)'), distinguishing it from sibling tools like update_deck_card and move_deck_card. It also mentions a necessary prerequisite tool (get_deck_board), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using get_deck_board to find stack IDs, providing a clear workflow for how to obtain required parameters. It doesn't explicitly mention when not to use this tool compared to alternatives, but for a create operation, the usage context is clear and well-supported.
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 of disclosing behavior. It implies a read-only operation ('Download and return') and notes a limitation (best for text files), but does not explicitly state that it does not modify the file, or address potential issues with binary files. It is adequate but leaves some behavioral aspects implicit.
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 the primary action stated first and no unnecessary words. It is front-loaded and perfectly 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?
The tool is simple (one parameter, no output schema), and the description covers its purpose, usage, and return value ('content of a file'). It does not mention error conditions, but that is not critical for such a straightforward operation. Overall, it is sufficiently 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?
The single parameter 'path' is fully described in the schema with an example. The tool description adds no additional parameter semantics beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Download and return') and resource ('content of a file from Nextcloud'), clearly distinguishing it from sibling tools like list_files or upload_file. It states exactly what the tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance by stating it is 'Best suited for text files', implying when to use it and hinting that binary files may not work well. It does not explicitly mention alternatives for non-text files, but the context is clear enough for basic usage decisions.
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 states 'get full content', which conveys a read operation, but does not disclose what happens if the note ID does not exist, the return format, or any access restrictions. For a simple get-by-ID, this is minimally adequate but could be richer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word adds value: 'full content', 'specific note', 'by ID' all contribute to understanding the tool's purpose.
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 tool with one parameter, no output schema, and no annotations, the description covers the core need: it tells the agent that given a note ID, it retrieves the full content. It does not describe the exact return structure (e.g., whether it includes metadata), but given the simplicity, this is a minor gap.
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 only parameter, noteId, is given meaning by 'by ID' in the description, but the schema itself has no description for noteId. With 0% schema coverage, the description only partially compensates; it confirms noteId is the ID of the note but does not explain the ID type or source beyond the numeric type in 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 gets the full content of a note by ID, using a specific verb (get) and resource (note content). It distinguishes itself from siblings like get_notes, implying get_notes lists metadata while this retrieves full content.
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 when you need the full content of a specific note, identified by its ID. It does not explicitly name alternatives or exclusions, but the context of siblings (e.g., get_notes) provides enough differentiation for typical selection.
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 discloses the return fields (name, type, size, last modified) and implies a read-only operation through the verb 'List'. However, with no annotations, it does not address edge cases such as whether the listing is recursive, how hidden files are handled, or what happens for invalid paths. This leaves some ambiguity about the tool's exact 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 exactly two sentences, front-loaded with the primary action and resource, and contains no redundant or unhelpful information. Every sentence contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter, no output schema), and the description explains the return values adequately. However, it misses some contextual details like whether the listing is non-recursive or path semantics beyond the schema, which would round out the picture. It is complete enough for basic use but not exhaustive.
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 parameter 'path' is fully documented in the schema with examples and a default value, so the description adds no additional meaning. Per the rubric, when schema coverage is 100%, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and explicitly identifies the resource ('files and folders in a Nextcloud directory'), making the tool's purpose immediately clear. It also distinguishes itself from sibling tools like get_file, upload_file, and create_folder, which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool (when you need to see the contents of a directory), and the sibling context naturally differentiates it from file manipulation tools. However, it does not explicitly state exclusions or name alternative tools, so it lacks the explicit 'use this instead of X' guidance that would earn 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 full burden for behavioral disclosure. It explicitly states that the tool returns a board along with all its stacks and cards, which is valuable context for the agent. While it doesn't mention error handling or auth, it sufficiently discloses the main return scope for a read 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 extremely concise: two sentences, front-loaded with the main purpose and followed by a practical usage hint. Every sentence earns its place without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter, no output schema, and no annotations, the description is fully sufficient. It explains what the tool returns, how to obtain the required input, and gives clear usage guidance relative to sibling 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 already provides 100% coverage for the single parameter boardId, with a description stating 'Board ID from get_deck_boards.' The tool description echoes this same relationship without adding new parameter-specific information, so the baseline of 3 for high schema coverage applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get a Deck board with all its stacks (columns) and cards.' It uses a specific verb (get) and resource (a specific board's stacks and cards), distinguishing it from sibling tools like get_deck_boards (which lists boards) and card creation/update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context by instructing to 'Use get_deck_boards first to find the board ID.' This clearly indicates a prerequisite and correct sequencing, helping the agent understand when this tool is appropriate relative to its sibling get_deck_boards.
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 clearly implies a read-only operation ('List') and discloses the return fields (board IDs, titles, colors). It does not mention ordering, archived boards, or pagination, but for a simple list operation this is decent.
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 an active verb and no filler. It states purpose and output in a compact way.
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 zero-input, no-output-schema tool, the description covers the essential aspects: what it lists, scope, and return values. Minor omissions like sorting order or inclusion of archived boards prevent a 5, but it is sufficiently 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 tool has zero parameters, so the schema coverage is trivially 100%. Per the baseline for 0 params, the description does not need to add parameter semantics. It focuses on output instead, which 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 uses specific verb 'List' and resource 'Nextcloud Deck boards' with a clear user-access scope. This distinguishes it from the sibling tool get_deck_board, which likely retrieves a single board, and from other list tools.
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 indicates this is for listing all accessible boards, which provides clear context for when to use it. However, it does not explicitly mention when not to use it or alternatives like get_deck_board for a single board.
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?
The description discloses key behavior: when listId is omitted, all VTODO-capable lists are queried and results are tagged with source list. Being a retrieval operation, no side effects are expected, and the description adds value beyond the schema's parameter descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each adding information: purpose, listId omission behavior, and prerequisite. No redundant phrasing.
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 read operation with three well-documented parameters, the description covers the essential behavior and output tagging. It lacks detailed return structure but that is not critical given the simple tool and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes limit, listId, and status (100% coverage). The description elaborates on the listId parameter by mentioning all VTODO-capable lists and result tagging, which goes beyond the schema's note to query all lists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves tasks from Nextcloud, distinguishing from calendar/notes/files siblings. The scope of querying all lists when listId is omitted is specified, and the prerequisite relationship with get_task_lists is noted.
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?
Provides guidance to call get_task_lists first to discover list IDs, which helps with parameter selection. Does not explicitly contrast with create/update tools, but the read-only nature is implicit and the sibling names suffice.
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 burden of behavioral disclosure. It explains the return format (id as the CalDAV path segment and display name) and the semantics of 'task lists'. It implies a read-only discovery operation but doesn't explicitly state it or mention edge cases, though the disclosure is sufficiently specific for this simple 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 only two sentences and front-loads the main purpose. Every sentence earns its place: the first states the scope and definition, the second reveals the return fields and a direct usage instruction, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no annotations), this description is complete. It explains what the tool returns, how to interpret the returned id, and how to use it with related tools. The CalDAV/VTODO context also clarifies the domain without overwhelming detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty, which the description correctly doesn't discuss. The baseline for zero parameters is 4, and the description adds value by explaining the output semantics, which is meaningful given there is no output 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 ('Discover') and resource ('all task lists'). It also distinguishes itself from siblings by defining task lists as 'CalDAV calendars that support VTODO' and noting the returned list id and display name.
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 gives clear context for when to use this tool: it provides the necessary list IDs for calling get_tasks or create_task. It doesn't explicitly mention alternatives or exclusions, but the integration with sibling tools is explicit, making the usage scenario clear.
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-mcp MCP server](https://glama.ai/mcp/servers/Jaypeg-dev/nextcloud-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Jaypeg-dev/nextcloud-mcp)

Score Badge

Copy to your README.md:

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

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