A Python toolkit for automating MicroStrategy / Strategy One via its REST API: reading out project objects, comparing environments, driving migrations, running regression tests, and exporting dashboards to Open Semantic Interchange (OSI) YAML so BI content can be consumed by LLM agents.
Built against a real MicroStrategy estate and shared as-is. The API surface is not stable yet — expect changes between 0.x releases.
OSI export. osi_exporter walks a MicroStrategy dossier and emits an OSI
semantic model — datasets, fields, metrics and relationships — plus a dashboard
document describing chapters, pages and visualizations. MicroStrategy's native
visualization types are mapped onto neutral OSI ones (BarChart → bar_chart,
KpiWidget → kpi_card, …), and add_ai_context() annotates any node with
free-text context for downstream agents.
MCP servers. mstr_robotics.mcp_servers exposes the toolkit over the Model
Context Protocol, so an assistant can find the right dashboard for a natural-language
question, resolve objects by folder path, execute a report, and answer from the
result together with its OSI context.
Environment comparison. json_compare diffs object definitions between two
MicroStrategy environments with configurable path filtering and checksums —
the basis for "what actually changed between dev and prod".
Requires Python 3.12+ and network access to a MicroStrategy Library REST endpoint.
git clone https://github.com/magerdaniel/MSTR_Robotics.git
cd MSTR_Robotics
python -m venv .venv
.venv\Scripts\Activate.ps1 # Windows; source .venv/bin/activate on Unix
pip install -e .Then two steps, both covered in detail by docs/SETUP.md:
- Deploy the Object Manager packages from
Object_Manager_Packages/— they create the cubes, reports and dossiers the notebooks read from. - Run
notebooks/00_setup.ipynbtop to bottom. It creates the output folders, copies the config templates, checks what you filled in, verifies the connection, and resolves your environment's object GUIDs automatically.
That last part is the one worth knowing about: deploying the packages creates objects
that MicroStrategy assigns new GUIDs, but their names are fixed — so the setup
notebook searches your project by name and writes the right GUIDs into
config/jupyter_objects_d.yml instead of you hunting ~30 of them by hand.
The base install stays small on purpose. Add only what you need:
pip install -e ".[rag]" # OpenAI/Perplexity, FAISS, LangChain — chat & RAG notebooks
pip install -e ".[redis]" # Redis-backed metadata analysis
pip install -e ".[azure]" # Azure Blob staging for migrations
pip install -e ".[servers]" # MCP servers
pip install -e ".[all]" # everything above
pip install -e ".[dev]" # ruff, vulture, jupyterAll data locations resolve relative to the repo by default and can be repointed with environment variables:
| Variable | Default | Holds |
|---|---|---|
MSTR_REPO_ROOT |
auto-detected from config/user_d.yml |
repo root |
MSTR_OSI_DIR |
<repo>/data/osi |
generated OSI YAML |
MSTR_OSI_SCHEMA_DIR |
MSTR_OSI_DIR |
osi-schema-with-dashboards.json |
MSTR_OUTPUT_DIR |
<repo>/output |
exports, logs, MCP data |
| Module | Purpose |
|---|---|
_connectors |
MstrApi — REST session handling |
read_out_prj_obj |
Read schema, facts, attributes, prompts, reports, cubes |
osi_exporter |
Build OSI semantic models and dashboard documents |
json_compare |
Diff object definitions across environments |
select_mig_objects |
Change-log driven migration package building |
regam |
Regression testing against Platform Analytics data |
cube_load |
Parallel cube publish with follow-up chains |
report, dossier, navigation |
Report/dossier execution and prompt answering |
user_rag |
FAISS vector store, OpenAI and Perplexity clients |
redis_db |
Redis-backed BI metadata analysis |
prepare_ai_data |
Normalize MSTR metadata JSON for AI consumption |
mcp_servers |
MCP tool groups over the above |
setup |
First-run helpers driven by 00_setup.ipynb |
cube_load.handle_cube_load(conn, execution_list) publishes cubes in parallel and can
trigger a follow-up cube once one finishes. Each entry takes a project_id, a cube_id,
run_any_time, and an optional follow_up — see mstr_robotics/cube_load_sample.json
for the shape. Running the module directly executes the demo chain in its __main__
block:
python -m mstr_robotics.cube_loadStart with 00_setup.ipynb — it configures everything else. After that:
| Notebook | Does |
|---|---|
jup_prj_obj_exporter.ipynb |
Read objects out of a project |
jup_schema_monitor.ipynb |
Monitor schema changes over time |
jup_migrate.ipynb |
Build and run migration packages |
jup_REGAM.ipynb |
Regression testing against Platform Analytics |
jup_load_rag_cubes.ipynb |
Export metadata cubes for RAG |
jup_chat_answer_prompt_page.ipynb |
Answer BI questions over exported context |
jup_mstr_admin.ipynb |
Administrative queries |
Object IDs come from config/jupyter_objects_d.yml rather than being hardcoded, so the
same notebooks run against any environment. Outputs are stripped before commit.
See LICENSE.