What can you do with this server?

A read-only MCP server that lets AI clients browse and read documents from DMS repositories through a local bridge. * Check bridge availability with bridge_health. * List configured DMS connections with list_connections. * Browse files and folders at a connection:/path location with list_items. * Search natively below a path with search_items, with optional files-only filtering and result limits. * Resolve Alfresco/eDoCat share URLs to exact DMS paths and inspect folder contents with open_share_url. * Get metadata for a specific file or folder with get_item_info. * Read size-limited documents with read_document, decoding text or base64-encoding binary content. * No upload, move, copy, mkdir, or delete tools; DMS credentials never enter the MCP server.

How do I use dms-mcp-server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@dms-mcp-server Show me the documents in connection:/Projects" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

dms-mcp-server

by mergi72

Overview Schema Related Servers Score Discussions

Python

Local

dms-mcp-server

Python MCP SDK Release

Read-only Model Context Protocol server for DMS repositories exposed by dms-provider-bridge. The MCP server never receives DMS usernames, passwords or tokens. It forwards only the connection-owned credential_id reference and leaves credential resolution to the bridge.

The server uses the official Python MCP SDK v2 with Streamable HTTP. The server supports stateless HTTP so a long-running DMS operation does not block independent MCP clients. Existing calls remain backward compatible; search_items adds the optional search_mode parameter.

MVP tools

bridge_health
list_connections
list_items
search_items
search_metadata
open_share_url
get_item_info
read_document

All DMS paths use connection:/path. The server intentionally has no upload, move, copy, mkdir or delete tools.

open_share_url accepts an Alfresco-compatible shared URL, resolves its exact connection:/path, returns item metadata and lists the contents when the URL targets a folder. eDoCat DIR-... links are resolved through their same-host redirect to the underlying Alfresco document-library path.

Related MCP server: local-tools-mcp-server

Architecture

MCP client --HTTP--> dms-mcp-server --HTTP--> dms-provider-bridge --> DMS
                                                       |
                                                       +--> credential resolution

For a connection path, the MCP server reads the connection auth contract from the bridge and passes only its credential_id reference back to the bridge operation. The bridge owns resolution and use of DMS secrets. Secrets never enter the MCP process, tool results or MCP configuration.

Configuration

Runtime data lives in config/mcp.json, separately from application code:

{
  "bridge": {
    "url": "http://127.0.0.1:8765",
    "minimumVersion": "0.2.0"
  },
  "server": {
    "host": "127.0.0.1",
    "port": 8781,
    "path": "/mcp",
    "statelessHttp": true
  },
  "runtime": {
    "timeoutSeconds": 30,
    "maxDocumentBytes": 1048576
  },
  "debug": {
    "enable": true,
    "path": "%APPDATA%\\DMS MCP\\logs",
    "loggerLevels": {
      "httpx": "WARNING",
      "httpcore": "WARNING"
    }
  }
}

server.statelessHttp is enabled by default for the SDK v2 runtime. Logger levels are data-driven; the defaults keep low-level HTTP transport chatter out of Laděnka while preserving MCP tool and operation events.

The service always writes UTF-8 operational events to mcp.log. When debug.enable is true, detailed events are also written to mcp-debug.log in the configured directory. Tool logs never contain credentials or downloaded document content.

The machine configuration provides the required base document. Optional user overrides are loaded from %APPDATA%\\DMS MCP\\config\\mcp.local.json and merged over that base. Set DMS_MCP_MACHINE_CONFIG_DIR or DMS_MCP_USER_CONFIG_DIR to use other config directories.

The distributed application keeps config/mcp.json beside the application, not inside the Python package. A packaged executable therefore has this layout:

dms-mcp-server/
|-- dms-mcp-server.exe
`-- config/
    `-- mcp.json

User overrides in %APPDATA%\\DMS MCP\\config\\mcp.local.json are merged on top of that default. Environment variables have the highest priority. A wheel is only an installer input: a bare pip install is not a complete application deployment unless the installer also places config/mcp.json beside the application or sets DMS_MCP_MACHINE_CONFIG_DIR.

Environment variables remain available as final runtime overrides:

Variable	Default	Purpose
`DMS_BRIDGE_URL`	`http://127.0.0.1:8765`	Local bridge URL
`DMS_MCP_SERVER_HOST`	`127.0.0.1`	Local MCP bind address (`127.0.0.1`, `localhost` or `::1`)
`DMS_MCP_SERVER_PORT`	`8781`	MCP service port
`DMS_MCP_SERVER_PATH`	`/mcp`	Streamable HTTP endpoint path
`DMS_MCP_TIMEOUT_SECONDS`	`30`	Upstream HTTP timeout
`DMS_MCP_MAX_DOCUMENT_BYTES`	`1048576`	Maximum document returned to MCP
`DMS_MCP_MIN_BRIDGE_VERSION`	`0.2.0`	Minimum compatible bridge version

Credential IDs are owned by bridge connection configuration and are never selected by the AI or duplicated in MCP configuration.

The Bridge HTTP client ignores system proxy environment variables. This keeps local Bridge traffic on its configured direct connection instead of routing it through HTTP_PROXY or ALL_PROXY.

Development

python -m venv .venv
.\.venv\Scripts\pip.exe install -e ".[dev]"
.\.venv\Scripts\python.exe -m pytest

Run the MCP HTTP service:

.\.venv\Scripts\dms-mcp-server.exe

The default endpoint is http://127.0.0.1:8781/mcp. Diagnostic scripts invoke the same executable with the explicit --stdio compatibility switch.

The HTTP listener remains localhost-only. If a trusted loopback reverse proxy such as Tailscale Serve preserves an external Host header, opt in to that single exact host in the user-local mcp.local.json:

{
  "server": {
    "allowedHosts": ["vfs-node.example.ts.net:8443"]
  }
}

Localhost hosts remain allowed automatically. Wildcards are rejected so this setting cannot silently disable the MCP SDK's DNS-rebinding protection.

Run the read-only live smoke test while the bridge and its configured credential resolution service are running:

.\.venv\Scripts\python.exe scripts\run_live_smoke.py alfresco edocat

The smoke test exercises the original browsing and document tools. It prints document metadata, size and SHA-256 only; document content is never printed.

Display a bounded tree of DMS folders and files through the MCP server:

.\.venv\Scripts\python.exe scripts\debug_dms.py alfresco edocat --max-depth 2

Optionally verify one document without printing its content:

.\.venv\Scripts\python.exe scripts\debug_dms.py alfresco `
  --document "alfresco:/Shared/report.docx"

The debug command prints names and available item metadata. Document verification prints only MIME type, byte size and SHA-256. Traversal is bounded by --max-depth, --max-directories and --max-items.

Run the local web inspector to see every MCP request and response side by side:

.\.venv\Scripts\python.exe scripts\web_debug.py

Then open the address configured by inspector.host and inspector.port in config/mcp.json (default http://127.0.0.1:8780). Command-line --host and --port values may temporarily override the JSON configuration. The inspector exposes the original six browsing and document tools and binds only to localhost; open_share_url remains available to MCP clients without adding another diagnostic UI control. Its Search control calls native provider search below the selected DMS path. For read_document, it displays MIME type, byte size and SHA-256 of the original bytes while omitting document content. Switch between the raw MCP Response and a clickable UI View for connections, folders, files and metadata; .. navigates to the parent folder. Its API accepts only local Host/Origin values and JSON requests.

Example HTTP MCP client configuration:

{
  "mcpServers": {
    "dms": { "url": "http://127.0.0.1:8781/mcp" }
  }
}

Available Tools

7 tools

bridge_healthA

Check whether the local DMS Provider Bridge is available.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It indicates a read-only check by saying 'check whether available', but it does not disclose return format, potential side effects, or any requirements. The minimal description is adequate 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 a single, focused sentence that earns its place. It is front-loaded and contains no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter health check with no output schema, the description is nearly complete. It tells the agent the purpose and implies a Boolean or status result, though it does not explicitly state the return format.

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 baseline is 4. There is nothing to explain beyond what the schema already shows, and the description correctly omits parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function with a specific verb ('check') and resource ('local DMS Provider Bridge availability'). It is distinct from siblings like list_connections or read_document, 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 Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage as a health check but does not explicitly state when to use it versus alternatives or any prerequisites. It lacks guidance on when to call this tool (e.g., before other operations).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_item_infoA

Return metadata for one file or folder at connection:/path.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes

TDQS

A3.7/5.0

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 disclosing behavioral traits. It only states the core function (return metadata) without mentioning error handling, permissions, return structure, or any side effects. This lack of disclosure is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, front-loaded and free of fluff. It communicates the essential information efficiently, earning every word.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema, no annotations), the description is minimally viable. It states what the tool returns and the path format, but lacks guidance on when to use it relative to siblings and does not detail the nature of 'metadata' or error behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the schema only defines 'path' as a string. The description adds critical semantic detail by specifying the expected format 'connection:/path', which is not present in the schema. This compensates well for the single parameter.

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 'Return metadata for one file or folder at connection:/path.' It uses a specific verb (Return), defines the resource (metadata for a single file/folder), and distinguishes itself from sibling tools like list_items and search_items by focusing on a single item rather than listing or searching.

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 metadata of a specific item via a path, but it does not explicitly state when to prefer this tool over siblings like list_items or search_items, nor does it provide exclusions or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_connectionsA

List DMS connections available through the bridge.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. 'List' implies a read-only operation and 'available through the bridge' adds scope, but it does not disclose return details, potential empty results, or any side effects. This 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 a single, front-loaded sentence with no redundant words. It communicates the essential purpose efficiently and is appropriately sized for the tool's simplicity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (0 params, no output schema), and the core action is stated clearly. However, the description does not mention what the returned connection data includes or any empty/error behavior, leaving some gaps in the context provided to the agent.

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?

This tool has zero parameters and 100% schema coverage, so there are no parameter semantics to add. The baseline of 4 applies because the schema already fully covers parameters, and the description needs no parameter-level details.

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 the specific verb 'List' and names the resource 'DMS connections available through the bridge', clearly distinguishing it from sibling tools like list_items (items vs connections) and bridge_health. It is direct 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?

There is no guidance on when to use this tool versus alternatives, no mention of prerequisites or ordering with sibling tools, and no exclusions. The description only states what the tool does, not when to choose it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_itemsB

List files and folders at a connection:/path location.

ParametersJSON Schema

Name	Required	Description	Default
`path`	No		/

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavior. It only states the listing action and does not cover important aspects like whether the listing is recursive, how hidden files are handled, authentication requirements, sorting, or the output format.

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 with no wasted words.

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 one-parameter tool, the description covers the basic purpose but lacks detail on return values, path syntax, and behavioral expectations. Given no output schema or annotations, the description is minimally sufficient but incomplete.

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 'path' with no description, and schema description coverage is 0%. The description adds context by indicating the path is in the 'connection:/path' format, but it does not explain the default value ('/') or provide examples or constraints.

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 the specific verb 'List' and explicitly names the resource ('files and folders') and the location ('connection:/path location'). This clearly distinguishes from sibling tools like list_connections (which lists connections) and search_items (which searches).

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 such as search_items or get_item_info. It does not mention exclusions, prerequisites, or scenarios where another 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.

open_share_urlA

Open an Alfresco or eDoCat DMS share URL read-only. Resolve its exact path, return item metadata, and list contents when it targets a folder.

ParametersJSON Schema

Name	Required	Description	Default
`share_url`	Yes
`connection`	No		auto

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses the read-only nature, a key behavioral trait, and details the output: resolved path, metadata, and folder listing. It does not mention potential errors, connection requirements, or invalid URLs, but it carries the transparency burden well given the absence of annotations.

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 front-loads the action and then adds specific details. Every word contributes to understanding the tool's behavior without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description appropriately explains that the tool returns item metadata and lists contents for folders. It also covers path resolution. Missing are details on error handling and the role of connection, but overall it is fairly complete for a small tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema lists share_url and connection, but the description only implicitly references share_url as the resource. No explanation is given for connection or its default 'auto', leaving the agent to infer its meaning from the name alone, which is insufficient given 0% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: opening an Alfresco or eDoCat DMS share URL read-only, resolving its path, returning metadata, and listing folder contents. This verb+resource structure is specific and distinguishes it from siblings like read_document or get_item_info, which operate on already-resolved items.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: use this tool when you have a DMS share URL to open and explore. However, it does not explicitly mention when not to use it or name alternatives like search_items or read_document for cases when the path is already known.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_documentA

Read a size-limited document; text is decoded and binary data is base64 encoded.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses key behaviors: the document is size-limited, text is decoded, and binary data is base64-encoded. These details go beyond a simple 'read' and help set expectations about response format and potential limitations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with two concise clauses. It packs essential information (limit, decoding, encoding) without any filler, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool with no output schema, the description is largely complete: it explains what is returned (text vs. base64 binary) and notes the size limitation. It lacks error handling or a detailed size threshold, but these are not critical for the basic read functionality.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has a single 'path' parameter with no description (coverage 0%). The tool description does not mention the parameter at all, offering no additional meaning beyond the schema's type and required flag. Since coverage is low and the description fails to compensate, this dimension is severely under-served.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Read' with resource 'document', and adds specificity with 'size-limited' and encoding behavior. This distinguishes it from sibling tools like get_item_info and open_share_url, which focus on metadata or sharing rather than content reading.

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 this tool is for reading document content, making it the go-to choice when the full text or binary payload is needed. It doesn't explicitly name alternatives or exclusions, but the context is clear enough for an agent to choose it over sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_itemsA

Search natively below connection:/path. Returned paths are exact and must be reused verbatim; never shorten or rewrite them. By default return unique files only.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`query`	Yes
`files_only`	No
`max_results`	No

TDQS

A3.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses two important constraints: returned paths are exact and must be reused verbatim, and by default only unique files are returned. These add significant clarity beyond what the schema conveys, though it does not cover all potential behaviors (e.g., recursion, authorization).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three short sentences, front-loaded with the core purpose. Each sentence adds value: the first states the action, the second gives a critical usage constraint, and the third notes the default behavior. There is no wordiness or repetition.

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 4 parameters, no output schema, and no annotations, the description is somewhat incomplete. It conveys essential constraints but omits details about the 'query' and 'max_results' parameters and does not fully describe the return format. However, it does provide enough for basic usage, and the noted constraints are crucial.

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 partially explains the 'path' parameter via 'below connection:/path' and the 'files_only' parameter via 'By default return unique files only', but it does not mention 'query' or 'max_results' at all. Users must infer that 'query' is the search term, and max_results is unexplained.

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 performs a search operation 'below connection:/path', which distinguishes it from sibling tools like list_items (which likely lists items) and get_item_info (which retrieves specific item info). While it does not explicitly name alternatives, the verb 'search' and the scoping to a path are specific enough to convey the primary purpose.

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 searching below a given path, but it does not explicitly state when to choose this tool over alternatives like list_items or read_document. It provides no exclusions or alternative recommendations, so guidance is mostly implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

7 tool updatesv0.5.2Aug 3, 2026
- First observedbridge_health
- First observedget_item_info
- First observedlist_connections
- First observedlist_items
- First observedopen_share_url
- First observedread_document
- First observedsearch_items

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: health check, connection listing, item listing, search, share URL resolution, metadata retrieval, and document reading. There is no overlapping functionality that would cause confusion.

Naming Consistency4/5

Most tools follow a verb_noun pattern (list_connections, list_items, search_items, open_share_url, get_item_info, read_document), but bridge_health deviates by using a noun phrase. The inconsistency is minor and does not impede readability.

Tool Count5/5

With 7 tools, the server is well-scoped for a DMS read-access bridge. Each tool serves a necessary function, and the count falls comfortably within the ideal range.

Completeness4/5

The server comprehensively covers browsing, searching, metadata retrieval, and document content access. However, it lacks any write operations (create, update, delete), which may limit functionality if full DMS management is expected. For read-only access, it is nearly complete.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

ORANO MCP Server
io.github.infotik
Read-only MCP server exposing a user ORANO library to their own AI agent.
1
HubSpotOAuth
com.hubspot.app
The HubSpot MCP Server acts as a bridge that enables AI assistants and Large Language Models to securely interact with HubSpot CRM data through natural conversation, without requiring users to understand complex API structures. It provides read-only access to standard CRM objects (contacts, companies, deals, tickets, products, invoices, and more) and their associations, secured via OAuth 2.0, allowing AI agents to perform tasks like summarizing deals, fetching company updates, and looking up record changes.
Customer Data Platforms Databases Marketing
3
The Quiet Protocol Growth Offense MCP A
com.thequietprotocol.www
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
Databases Research & Data Finance
292
docbaseOAuth
io.github.krayinc
DocBase MCP server for AI agents
Documentation Access Search Developer Tools
2

Related MCP Servers

maha-mcp-bridgeofficial
Databases Knowledge & Memory Search
Maha-Strategies
A
license
Not graded
quality
B
maintenance
Zero-trust local MCP bridge that exposes read-only database tools and structured book navigation to AI agents, with two-tier PII redaction and MPS audit integration.
Updated a month ago (2026-08-07 12:51 UTC)
13
1
MIT
local-tools-mcp-server
fenhuayue
F
license
A
quality
C
maintenance
A read-only MCP server that enables AI assistants to search files, list directories, retrieve system info, and get file metadata on the local file system.
Updated 2 months ago (2026-07-20 09:22 UTC)
4
-
FileManager MCP Server
File Systems Search
Surf-Team
F
license
Not graded
quality
C
maintenance
Read-only MCP server for AI clients to browse and search project files securely, with configurable permissions, virtual paths, and key-based access.
Updated a month ago (2026-08-03 09:02 UTC)
-
sources-mcp
File Systems Email Databases
Eingin
F
license
Not graded
quality
C
maintenance
Read-only MCP server exposing homelab data sources (files, mail, calls) to Cloudflare OS, enabling read-only access to documents, emails, and call records.
Updated 24 days ago (2026-08-13 04:48 UTC)
-

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/mergi72/dms-mcp-server'

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

dms-mcp-server

MVP tools

Architecture

Configuration

Development

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

maha-mcp-bridgeofficial

Latest Blog Posts

MCP directory API