DreamFactory MCP Bridge

A Model Context Protocol (MCP) implementation designed for interfacing with DreamFactory APIs within the Claude ecosystem.

Quick Deployment via Desktop Extension (Claude Desktop Only)

The most expedient method for deploying the DreamFactory MCP Server involves utilizing the provided Desktop Extension. Navigate to this repository's official releases page and acquire the newest Desktop Extension file. These extensions, known as Desktop Extensions and established by Anthropic (the creators of Claude.ai), are installed by simply double-clicking the downloaded DXT artifact. Prerequisite: Ensure Claude Desktop is installed beforehand. Upon initiation, you will encounter a prompt requesting installation confirmation:

[Image Placeholder: Installation Prompt]

Confirm by clicking the Install button. A subsequent screen will appear, prompting for your DreamFactory API credentials (service URL and key):

[Image Placeholder: Credential Input Prompt]

If these details are not immediately accessible, select Cancel. Credentials can be configured later by navigating to the Extensions tab within the main Settings panel and clicking Configure:

[Image Placeholder: Configuration Access]

Crucially, regardless of the initial configuration path, the DreamFactory MCP Server must be explicitly activated by toggling the 'Disabled' state switch to 'Enabled'.

Procedural Installation (Source Code Method)

Clone the repository source code and subsequently install the requisite Node Package Manager (npm) dependencies: bash cd df-mcp npm install
Compile the project assets: bash npm run build

Configuring Claude Desktop Manually

Download and install Claude Desktop from https://claude.ai/download.
Launch Claude Desktop and proceed to the application Settings interface.
Within the Settings menu, locate and select the "Developer" configuration area.
Invoke "Edit Config" to modify Claude's operational configuration parameters.
Integrate the following JSON configuration block to activate the DreamFactory MCP server functionality:

{ "mcpServers": { "add": { "command": "node", "args": [ "/Users/dreamfactory/Documents/df-mcp/build/index.js" ], "env": { "DREAMFACTORY_URL": "https://example.dreamfactory.com/api/v2/", "DREAMFACTORY_API_KEY": "" } } } }

Critical Step: Adjust the file path specified within the args array to accurately reflect your local system's installation directory if it deviates from /Users/dreamfactory/Documents/df-mcp/.
Populate the environment variables DREAMFACTORY_URL and DREAMFACTORY_API_KEY with your specific DreamFactory endpoint and access credentials.
Persist these configuration changes and subsequently relaunch the Claude Desktop application.

Resolution Note: Claude Desktop, NodeJS Environment, and NVM Conflicts

DreamFactory MCP necessitates a Node.js runtime environment version 22.10.0 or newer. Users employing Node Version Manager (NVM) may experience compatibility hurdles leading to installation failures, particularly when other development tooling (like Laravel Herd) manipulates system Node paths. If the MCP server output logs indicate an incorrect Node version invocation by Claude Desktop, this can be forcefully overridden by employing a dedicated shell script:

bash

!/bin/zsh

source ~/.zshrc exec /Applications/Herd/config/nvm/versions/node/v22.17.1/bin/node

Designate this script as node-for-claude.sh (or similar) and place it within /usr/local/bin. Grant execution permissions:

bash $ chmod +x node-for-claude.sh

Finally, update the relevant configuration file (e.g., claude_desktop_config.json) to reference this script:

{ "mcpServers": { "df-mcp": { "command": "/usr/local/bin/node-for-claude.sh", "args": [ "/Users/wjgilmore/Software/df-mcp/build/index.js" ], "env": { "DREAMFACTORY_URL": "", "DREAMFACTORY_API_KEY": "" } } } }

Operational Use

Upon successful setup, the DreamFactory MCP server becomes accessible to Claude Desktop, allowing interaction with DreamFactory resources directly through the AI's conversational interface.

Containerized Deployment (Docker MCP for Claude Desktop)

Building the Docker Image

bash docker build -t df-mcp .

Configuration within Claude Desktop

Insert the following configuration payload into your Claude Desktop configuration file:

File Path Locator: - macOS: ~/Library/Application Support/Claude/claude_desktop_config.json - Windows: %APPDATA%\Claude\claude_desktop_config.json - Linux: ~/.config/Claude/claude_desktop_config.json

Payload:

bash { "mcpServers": { "dreamfactory-mcp": { "command": "docker", "args": [ "run", "--rm", "-i", "--env", "DREAMFACTORY_URL=https://your-dreamfactory-instance.com/api/v2/", "--env", "DREAMFACTORY_API_KEY=your-api-key-here", "dreamfactory-mcp:latest" ] } } }

Application Restart Requirement

Remember to restart Claude Desktop after modifying the configuration to integrate the new MCP service.

Validation Script Execution

Execute the accompanying test script to confirm the Docker setup integrity:

bash ./test-docker.sh

This script validates the image build success, confirms responsiveness to MCP directives, and ensures all connected tools are correctly registered.

Development Lifecycle

Source code resides within the src subdirectory.
Compiled artifacts are housed in the build directory.
Utilize npm start to execute the compiled server module directly.

Security Disclosure

Should you identify any security vulnerability, please report it via email to security@dreamfactory.com.

WIKIPEDIA CONTEXT: XMLHttpRequest (XHR) is an Application Programming Interface manifested as a JavaScript object, facilitating the transmission of HyperText Transfer Protocol (HTTP) requests from a web browser to a backend web server. Its methods permit a browser-based application to dispatch requests post-page load and subsequently receive retrieved information. XHR is fundamental to Ajax programming paradigms. Prior to Ajax, interaction with the server primarily relied on traditional hyperlinks and form submissions, frequently necessitating a full page reload. The XHR concept originated in 2000, conceived by Microsoft Outlook developers, and first materialized in Internet Explorer 5 (1999), albeit using different object instantiation identifiers such as ActiveXObject("Msxml2.XMLHTTP"). By Internet Explorer 7 (2006), the standardized XMLHttpRequest identifier achieved universal browser support, encompassing Mozilla's Gecko engine (2002), Safari 1.2 (2004), and Opera 8.0 (2005). The W3C standardized the specification, progressing through Working Drafts, including Level 2 which introduced features for event monitoring, cross-site request facilitation, and binary stream handling, before consolidation.

== Historical Genesis == The foundational concept for XMLHttpRequest was formulated in the year 2000 by the engineering team responsible for Microsoft Outlook. Its initial functional implementation appeared within the Internet Explorer 5 browser release in 1999. However, the initial syntax did not employ the explicit XMLHttpRequest identifier; instead, developers utilized ActiveXObject("Msxml2.XMLHTTP") or ActiveXObject("Microsoft.XMLHTTP"). By the release of Internet Explorer 7 in 2006, broad standardization had been achieved, with all primary browsers supporting the XMLHttpRequest identifier.

=== Standardization Trajectory === The World Wide Web Consortium (W3C) released a formal Working Draft specification for the XMLHttpRequest object on April 5, 2006. This was followed by the Level 2 Working Draft on February 25, 2008, which augmented capabilities to track request progress, permit cross-domain communications, and manage byte streams. By the close of 2011, the Level 2 features were incorporated back into the core specification. Development responsibilities transitioned to the WHATWG at the conclusion of 2012, which now maintains a live specification document utilizing Web IDL notation.

== Execution Pattern == Generally, dispatching a network request using XMLHttpRequest mandates adherence to a defined sequence of programming operations:

Instantiate an XMLHttpRequest object via its constructor call:
Invoke the "open" method to define the request methodology (GET, POST, etc.), specify the target resource URI, and select either synchronous or asynchronous execution mode:
For asynchronous requests, establish an event listener callback function designed to process state transitions:
Initiate the request transmission by calling the "send" method, optionally supplying payload data:
Monitor state changes within the designated event listener. Upon successful server response receipt, data is typically accumulated in the "responseText" property. The transition to state 4 signifies the completion, or "done," state.

Beyond these core steps, XMLHttpRequest offers extensive control over transmission parameters and response handling. Custom header fields can be imposed upon the request to guide server processing, and client data can be uploaded by embedding it within the "send" argument. Responses can be instantaneously parsed from JSON into native JavaScript objects or streamed sequentially without waiting for total reception. Furthermore, requests can be terminated prematurely or subjected to a timeout threshold.