Alfresco MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between search tools (advanced_search, cmis_search, search_by_metadata, search_content) that could cause confusion about which to use for specific queries. The core document/folder management tools (create, delete, upload, download, checkout, checkin) are clearly differentiated.
Naming Consistency4/5
The naming follows a consistent verb_noun pattern (e.g., create_folder, delete_node, download_document) with one minor deviation: get_repository_info_tool uses 'tool' suffix inconsistently. Otherwise, the naming is predictable and readable.
Tool Count5/5
With 15 tools, this server is well-scoped for Alfresco document management, covering essential operations like CRUD, search, version control, and metadata handling. Each tool appears to serve a specific purpose without bloat.
Completeness5/5
The toolset provides comprehensive coverage for Alfresco repository management, including full CRUD for nodes, version control (checkout/checkin), multiple search methods, metadata operations, and repository info. No obvious gaps are present for core workflows.
Average 2.9/5 across 15 of 15 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 2 commits in the last 12 weeks
- Last stable release on July 25, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'sorting and filtering capabilities' but doesn't explain what the tool returns (though an output schema exists), how results are limited, or any constraints like rate limits or permissions. It's minimal and lacks crucial operational details.
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, efficient sentence with no wasted words, making it appropriately concise. However, it's front-loaded with basic information but lacks depth, which slightly limits its effectiveness despite the brevity.
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 (4 parameters, 1 required) and the presence of an output schema, the description is incomplete. It doesn't clarify what's being searched (e.g., documents, nodes) or how it differs from siblings, leaving gaps in context. The output schema mitigates some issues, but the description should do more to guide usage.
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 for undocumented parameters. It only vaguely references 'sorting and filtering' without explaining the four parameters (query, sort_field, sort_ascending, max_results) or their semantics. This adds little value beyond the schema's titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Advanced search with sorting and filtering capabilities' states the tool's purpose (searching) and mentions additional features (sorting/filtering), but it's vague about what resources are being searched and doesn't distinguish it from sibling tools like 'search_by_metadata' or 'search_content'. It provides a basic verb+scope but lacks specificity.
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 offers no guidance on when to use this tool versus alternatives like 'search_by_metadata' or 'search_content', nor does it mention prerequisites or exclusions. It implies usage for advanced search needs but lacks explicit context or comparisons with siblings.
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 'AFTS query language' which hints at syntax requirements, but lacks critical behavioral details: whether this is read-only, pagination behavior (implied by max_results but not explained), rate limits, authentication needs, or what 'content' includes (documents, folders, etc.).
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, efficient sentence with no wasted words. It's appropriately sized for a search tool, though it could be more front-loaded with key differentiators given the sibling context.
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?
With 3 parameters (1 required), 0% schema coverage, no annotations, but an output schema exists, the description is minimally adequate. The output schema likely covers return values, but the description lacks context on search scope, AFTS syntax examples, and differentiation from siblings, leaving gaps for 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. It only mentions 'AFTS query language' for the query parameter, but provides no context for max_results (default 25 but no range/limits) or node_type (no examples or valid values). The description adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Search for content') and target ('in Alfresco'), but is vague about scope and differentiation. It mentions 'AFTS query language' which adds specificity, but doesn't clarify what 'content' encompasses or how this differs from sibling tools like 'search_by_metadata' or 'cmis_search'.
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. With multiple search-related siblings (advanced_search, cmis_search, search_by_metadata), the description offers no context about use cases, prerequisites, or exclusions, leaving the agent to guess based on tool names 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 of behavioral disclosure. It states 'browse' but does not explain key traits: whether it's read-only (implied but not explicit), how it handles permissions, pagination behavior (hinted by 'max_items' but not described), or error conditions. This leaves significant gaps for a tool that interacts with a repository structure.
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 directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized for a basic tool, making it easy to parse quickly. Every word earns its place, avoiding 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's moderate complexity (2 parameters, no annotations, but has an output schema), the description is minimally adequate. The output schema likely covers return values, reducing the need for description details. However, it lacks context on usage, parameters, and behavioral traits, making it incomplete for safe and effective use without additional inference.
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 for undocumented parameters. It mentions 'repository structure' but adds no meaning to 'parent_id' (e.g., starting point for browsing) or 'max_items' (e.g., pagination limit). Without this, users may not understand how to use these parameters effectively, failing to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'Browse the Alfresco repository structure,' which clearly indicates it navigates or lists items in a repository. However, it lacks specificity about what 'browse' entails (e.g., listing folders/files) and does not differentiate from siblings like 'search_content' or 'get_node_properties,' which might offer similar functionality. It avoids tautology but remains vague on the exact action.
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 does not mention prerequisites, context for browsing (e.g., initial exploration vs. targeted search), or exclusions. Given siblings like 'search_content' and 'cmis_search,' users might be confused about when browsing is preferred over searching, leading to potential misuse.
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 mentions searching by metadata fields but does not cover critical aspects like whether this is a read-only operation, potential rate limits, authentication requirements, or what happens on errors. For a search tool with no annotations, 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 a single, efficient sentence that directly states the tool's function without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly. Every word earns its place, achieving optimal conciseness.
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 an output schema (which reduces the need to describe return values), but no annotations and 0% schema description coverage for 4 parameters, the description is incomplete. It covers the basic purpose but lacks details on parameter usage, behavioral traits, and differentiation from siblings. This makes it minimally viable but with clear gaps for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description only vaguely mentions 'metadata fields' without explaining what parameters like 'term', 'creator', 'content_type', or 'max_results' mean or how they should be used. This fails to compensate for the lack of schema documentation, leaving parameters ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as searching for content in Alfresco by metadata fields, which is clear but vague. It specifies the resource (content in Alfresco) and method (search by metadata fields), but lacks specificity on what metadata fields are available or how it differs from sibling tools like 'search_content' or 'cmis_search'. This makes it minimally adequate but not distinctive.
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. With sibling tools such as 'search_content', 'advanced_search', and 'cmis_search' available, there is no indication of what makes this tool unique or when it should be preferred. This leaves the agent without clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool performs a check-in operation, implying a write/mutation action, but doesn't disclose behavioral traits such as required permissions, whether it creates new versions, what happens to the checked-out state, or error conditions. The mention of 'Alfresco REST API' adds some context but is insufficient 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, efficient sentence that front-loads the core purpose ('Check in a document') and adds necessary context ('after editing using Alfresco REST API'). There is no wasted verbiage or redundancy, making it appropriately concise for the tool's complexity.
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 (5 parameters, mutation operation, no annotations) and the presence of an output schema (which might cover return values), the description is incomplete. It lacks critical details like parameter meanings, usage constraints, and behavioral transparency needed for safe and effective invocation, especially for a write tool with multiple inputs.
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 adds no parameter information. It doesn't explain what 'node_id' refers to, the purpose of 'comment' or 'major_version', or how 'file_path' and 'new_name' interact with the check-in process. With 5 parameters undocumented in both schema and description, this is a significant 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 ('Check in') and resource ('a document') with the specific context 'after editing using Alfresco REST API.' It distinguishes from siblings like 'cancel_checkout' and 'checkout_document' by focusing on the check-in operation. However, it doesn't explicitly differentiate from all siblings, such as 'update_node_properties' which might also modify documents.
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 with 'after editing,' implying usage post-modification, but lacks explicit when-to-use rules, prerequisites (e.g., document must be checked out first), or alternatives. No mention of when not to use this tool or comparisons to siblings like 'update_node_properties' for non-versioned changes.
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. While 'Delete' implies a destructive operation, it doesn't specify whether this requires special permissions, what happens to linked content, if deletion can be undone, or what the output contains. The 'permanent' parameter hints at behavioral nuance, but the description doesn't explain it.
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, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it efficient for quick understanding.
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 tool with 2 parameters (one with behavioral implications like 'permanent'), 0% schema coverage, no annotations, and multiple sibling tools, the description is inadequate. It doesn't address permissions, consequences, alternatives, or parameter meanings, leaving significant gaps despite the existence of an output schema.
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?
With 0% schema description coverage for both parameters, the description adds no parameter information beyond what's inferred from the tool name. It doesn't explain what 'node_id' represents, how to obtain it, or what 'permanent' means in context (e.g., vs. moving to trash).
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 the resource ('a document or folder from Alfresco'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential alternatives like 'cancel_checkout' or 'checkin_document' that might also remove content in different ways.
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. With siblings like 'cancel_checkout' and 'checkin_document' that might handle document lifecycle states, there's no indication of whether this tool is for permanent deletion, version management, or specific document states.
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 states the tool checks out a document for editing, implying a mutation that likely locks the document, but doesn't describe effects (e.g., locks document, prevents others from editing), permissions required, or error conditions. This is inadequate for a mutation 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 front-loads the core purpose ('Check out a document for editing') and adds necessary context ('using Alfresco REST API'). Every word earns its place, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), no annotations, and low schema coverage, the description is minimally complete. It states the basic action but lacks details on behavior, parameters, and usage context. For a mutation tool with siblings, it should do more to guide the agent, but the output schema mitigates some 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 schema provides no parameter details. The description adds no information about parameters beyond what the schema names imply. It doesn't explain what 'node_id' represents or how 'download_for_editing' affects behavior. The description fails to compensate for the low schema coverage.
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 ('check out') and resource ('a document') with the specific method ('using Alfresco REST API'). It distinguishes from siblings like 'checkin_document' and 'cancel_checkout' by focusing on the checkout operation, though it doesn't explicitly contrast with them. The purpose is specific but lacks explicit 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., document must be checked in), exclusions (e.g., not for folders), or compare with siblings like 'download_document' or 'checkin_document'. Usage is implied only by the tool name, with no explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Download' implies a read operation, it doesn't specify whether this requires authentication, what happens with the downloaded file (e.g., where it's saved), or if there are rate limits. The description is too minimal to adequately inform the agent about the tool's behavior beyond the basic action.
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 that directly states the tool's purpose without any unnecessary words. It's front-loaded with the core action and resource, making it efficient for quick understanding.
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 that there's an output schema (which should document return values) and no annotations, the description minimally covers the basic purpose. However, for a download operation with 3 parameters that are completely undocumented, the description should provide more context about how the tool works and what the parameters mean to be truly complete.
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?
With 0% schema description coverage and 3 parameters, the description provides no information about what 'node_id', 'save_to_disk', or 'attachment' mean or how they affect the download. The description doesn't compensate for the complete lack of parameter documentation in the schema, leaving the agent with no semantic understanding of the inputs.
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 ('Download') and resource ('a document from Alfresco repository'), making the purpose immediately understandable. However, it doesn't distinguish this tool from potential alternatives among its siblings, such as 'get_node_properties' which might also retrieve document information but not the file content itself.
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. With siblings like 'get_node_properties' or 'search_content' that might provide document metadata, there's no indication that this tool is specifically for retrieving the actual file content for download rather than just document information.
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 full burden but only states it 'updates' without clarifying behavioral aspects like permissions needed, whether changes are reversible, rate limits, or what the output contains. It mentions 'metadata and properties' but doesn't detail scope or constraints.
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?
Single sentence is efficient and front-loaded with the core action. However, it could be more structured by explicitly listing updatable fields or adding brief context without becoming verbose.
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 complexity (mutation tool with 5 params, no annotations) and an output schema (which reduces need to describe returns), the description is minimally adequate but lacks details on error conditions, idempotency, or example use cases. It covers the basic purpose but leaves gaps for safe invocation.
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 but only vaguely references 'metadata and properties'. It doesn't explain parameter meanings (e.g., 'node_id' identifies the target, 'name' vs 'title' differences) or usage context. Baseline is 3 due to moderate parameter count (5) but lack of detailed compensation.
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 ('Update') and target ('metadata and properties of a document or folder'), which distinguishes it from siblings like 'delete_node' or 'get_node_properties'. However, it doesn't specify what types of metadata/properties are updatable beyond what's implied by the input schema.
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 'checkin_document' or 'create_folder'. The description implies it's for modifying existing nodes, but doesn't mention prerequisites (e.g., node must exist), exclusions, or comparisons to sibling tools.
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 full burden for behavioral disclosure. It states this is an upload operation (implying a write/mutation) but doesn't mention authentication requirements, file size limits, supported formats, error conditions, or what happens on success. This leaves 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, efficient sentence with no wasted words. It's appropriately sized for a basic tool description and gets straight to the point without unnecessary elaboration.
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 this is a mutation tool with 4 parameters (0% schema coverage) and no annotations, but with an output schema present, the description is minimally adequate. The output schema will handle return values, but the description should do more to explain parameters and behavioral context for a write operation.
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 provides zero parameter information. It doesn't explain what 'parent_id' means, the relationship between 'file_path' and 'base64_content', or what 'description' applies to. With 4 undocumented parameters, this is inadequate.
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 ('Upload') and target ('a document to Alfresco'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'checkin_document' or 'download_document', which prevents 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 no guidance on when to use this tool versus alternatives like 'create_folder' for folders or 'checkin_document' for version control scenarios. There's no mention of prerequisites, constraints, or typical use cases.
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 the tool performs a search but doesn't describe what the search returns (e.g., results format, pagination), any rate limits, authentication requirements, or error conditions. The mention of a default query hints at behavior but lacks depth.
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 that are front-loaded with the core purpose. Every word earns its place, with no redundant information, 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 has an output schema (which handles return values) and no annotations, the description is minimally adequate but incomplete. It covers the basic action and default behavior but lacks details on usage context, parameter nuances, or behavioral traits, leaving gaps for a search tool with 2 parameters.
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 description adds minimal meaning beyond the input schema. It implies 'cmis_query' uses CMIS SQL syntax and defaults to searching for PDFs, but the schema already provides the default value and title. With 0% schema description coverage, the description doesn't compensate by explaining parameter formats or constraints, though it hints at the query's purpose.
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: 'Search using CMIS SQL syntax.' It specifies the verb ('Search') and the method ('CMIS SQL syntax'), and mentions the default query targets PDF documents. However, it doesn't explicitly differentiate from sibling tools like 'search_by_metadata' or 'search_content', which likely offer alternative search methods.
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 mentions the default query searches for PDF documents, but doesn't explain when CMIS SQL syntax is preferred over other search methods available in sibling tools, nor does it specify prerequisites or exclusions for 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 full burden for behavioral disclosure. It states the tool creates a folder but doesn't mention any behavioral traits: no information about required permissions, whether the operation is idempotent, what happens on conflicts, rate limits, or what the output contains. The description is minimal and lacks crucial context for a mutation 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—a single sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by conveying essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values) and no annotations, the description is minimally complete for stating what it does. However, for a mutation tool with 3 parameters and no annotation coverage, it should provide more context about behavior, usage, and parameters to be fully helpful to an agent.
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 description adds no parameter semantics beyond what the input schema provides. With 0% schema description coverage, the schema titles ('Folder Name', 'Parent Id', 'Description') give basic hints, but the description doesn't explain what these parameters mean (e.g., what 'parent_id' format is, what '-shared-' default implies). Baseline is 3 since schema coverage is low but description doesn't compensate.
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') and resource ('a new folder in Alfresco'), making the purpose immediately understandable. It distinguishes this as a creation tool among siblings that include deletion, download, search, and update operations, though it doesn't explicitly differentiate from similar creation tools like 'upload_document'.
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 parent folder permissions), when not to use it (e.g., for creating documents instead of folders), or direct alternatives among the sibling tools like 'upload_document' for files.
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 the action ('Get metadata and properties') but doesn't mention permissions, rate limits, response format, or whether it's a read-only operation. This leaves significant gaps in understanding how the tool behaves beyond its basic function.
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, clear sentence that efficiently conveys the core purpose without unnecessary words. It's front-loaded and appropriately sized for a simple retrieval tool, 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 (1 parameter) and the presence of an output schema, the description is minimally adequate. However, with no annotations and multiple sibling tools, it lacks context on usage and behavioral traits, making it incomplete for optimal agent understanding.
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 has 1 parameter with 0% description coverage, and the tool description doesn't add any details about the 'node_id' parameter, such as format or examples. Since schema coverage is low, the description fails to compensate, but with only one parameter, the baseline is slightly higher than minimal.
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 ('Get') and resource ('metadata and properties of a document or folder'), making the purpose understandable. However, it doesn't distinguish this tool from similar siblings like 'get_repository_info_tool' or 'update_node_properties', which might also involve node properties, so it misses full 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. With siblings like 'search_by_metadata', 'browse_repository', and 'get_repository_info_tool', there's no indication of when this specific retrieval method is preferred, leaving usage context unclear.
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 full burden for behavioral disclosure. It states this is a 'get' operation which implies read-only behavior, but doesn't specify authentication requirements, rate limits, error conditions, or what specific repository information is returned. The mention of Discovery Client adds some implementation context but doesn't sufficiently describe operational behavior for a tool with no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise at one sentence that directly states the tool's purpose and implementation approach. It's front-loaded with the core functionality ('Get Alfresco repository information') and adds useful context about the Discovery Client. There's no wasted verbiage, though it could be slightly more structured for better readability.
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 zero parameters, 100% schema coverage, and an output schema exists, the description's job is simplified. However, as a read operation among many repository tools with no annotations, it should better explain what distinguishes it from siblings and what specific information is returned. The presence of an output schema reduces the need to describe return values, but the description could provide more context about when this tool is the appropriate choice.
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 schema description coverage is 100%. The description appropriately doesn't waste space discussing non-existent parameters. A baseline of 4 is appropriate for parameterless tools where the schema fully documents the empty parameter set, and the description focuses on the tool's purpose rather than parameter details.
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: 'Get Alfresco repository information' specifies both the verb (get) and resource (repository information). It distinguishes from siblings by mentioning the Discovery Client approach, though it doesn't explicitly differentiate from similar read operations like get_node_properties. The purpose is clear but could better highlight uniqueness among sibling tools.
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 usage guidance. It mentions using 'Discovery Client (as tool instead of resource)' which hints at architectural context, but doesn't specify when to use this tool versus alternatives like browse_repository or get_node_properties. No explicit when/when-not scenarios or prerequisites are provided, leaving the agent with little guidance on appropriate usage contexts.
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 mentions 'discarding any working copy,' which indicates a destructive action, but does not cover other critical aspects like permissions required, whether the action is reversible, error conditions, or response behavior. This is inadequate for a mutation 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 that front-loads the core action and effect without unnecessary words. Every part of the sentence contributes directly to understanding the tool's purpose, making it appropriately concise 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 that there is an output schema (which may cover return values), the description does not need to explain outputs. However, for a destructive tool with no annotations and minimal parameter guidance, the description is incomplete—it lacks details on behavioral implications, error handling, and usage context, which are crucial for safe and effective tool invocation.
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 has one parameter ('node_id') with 0% description coverage, and the tool description does not add any parameter-specific information. With a single parameter, the baseline is higher, but the description fails to explain what 'node_id' represents (e.g., document identifier) or its format, leaving semantics unclear beyond the schema's basic structure.
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 ('Cancel checkout') and the resource ('a document'), specifying the effect ('discarding any working copy'). It distinguishes from sibling tools like 'checkout_document' and 'checkin_document' by focusing on cancellation rather than initiation or completion of checkout.
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 when a checkout needs to be canceled, but does not explicitly state when to use this tool versus alternatives like 'checkin_document' or other document management tools. It lacks guidance on prerequisites (e.g., must have an active checkout) or exclusions, leaving usage context partially inferred.
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:

[![python-alfresco-mcp-server MCP server](https://glama.ai/mcp/servers/stevereiner/python-alfresco-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/stevereiner/python-alfresco-mcp-server)

Score Badge

Copy to your README.md:

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

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