Private Extension Modules

Private Extension Modules (EPLAN_MCP_EXTENSIONS)

The server can load extra tool modules from outside this repo — for company-specific or private tooling (custom add-in test harnesses, internal workflows) that must not live in a public repository.

< Back to Home

---

How it works

Set the EPLAN_MCP_EXTENSIONS environment variable on the MCP server entry to one or more directories (os.pathsep-separated — ; on Windows). Every top-level *.py file there (not starting with _) is imported at startup and its __all__ functions are registered as MCP tools, exactly like the built-in actions:

# my_company_tools.py  (in a private repo, NOT in eplan-rag-mcp)
TOOL_PREFIX = "acme_"          # optional, default "eplan_"
__all__ = ["run_smoke_test"]

import actions                  # the server's api/ folder is on sys.path
from actions._base import _get_connected_manager

def run_smoke_test(project_path: str) -> dict:
    """Docstring becomes the tool description the LLM sees."""
    clone = actions.scratch_project_create(project_path)
    ...
    return {"success": True}

Rules and behavior

• TOOL_PREFIX namespaces the tools (acme_run_smoke_test above).
• Extensions can import everything the built-in actions use: actions, actions._base, actions.scripted._execute_script (run C# inside EPLAN), eplan_connection.
• A broken extension is reported on stderr and skipped — it never prevents the server from starting.
• eplan_list_extensions (see Connection and Server Tools) shows what was loaded.

Why it exists

Combined with the lifecycle and scratch-fixture tools, this enables a fully unattended loop for developing private EPLAN add-ins: build the DLL → deploy → eplan_app_restart → verify the add-in's actions registered (e.g. via a FindAction script) → run them against a disposable scratch project → eplan_get_system_messages to catch anything EPLAN complained about — without ever needing to upstream your internal tooling into this public repo.