This server lets you drive a Domo-to-Databricks migration assessment and planning workflow conversationally.
Inventory the estate — domo_discover returns census counts, governance split, and source systems; domo_inventory gives a typed, searchable asset list (connectors, Magic ETL, SQL DataFlows, datasets, cards, beast modes, pages).
Assess and rationalize — domo_assess classifies assets by domain/source, infers governed vs shadow IT, and scores complexity/value.
Map to industry models — list_industry_models lists available Databricks Industry Data Models; industry_model_map draft-maps Domo DataSet columns onto canonical tables.
Evaluate ingestion paths — lakeflow_feasibility scores source systems GREEN/AMBER/RED for Lakeflow Connect and recommends the Databricks ingestion pattern.
Transpile migrations — transpile_lineage converts a Magic ETL/SQL lineage triplet into medallion Spark SQL, folds Beast Modes into a semantic view, swaps connectors, and returns a PASS/FAIL reconcile gate.
Build a migration plan — migration_plan aggregates census, assessments, and feasibility into a prioritized wave plan with governance split and recommended pilot.
Provides tools for migrating Domo assets to Databricks, including discovering, assessing, planning, and deploying Databricks Asset Bundles (SQL/Python pipelines) to a Databricks workspace with Unity Catalog integration.
Allows committing generated Databricks Asset Bundles to a GitHub repository as a pull request for version control and collaboration.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Databricks Domo Migration Accelerator MCP Server Discover and assess Domo assets for migration"
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.
Assess a Domo estate and migrate it to Databricks — via an MCP server and a web console.
The Python package is
pseudo_domo_mcp(it impersonates a Domo tenant's API surface so the whole workflow runs offline). The product is the Databricks Domo Migration Accelerator.
The methodology mirrors Databricks Lakebridge (Profiler + Analyzer → Convert → Reconcile), extended with a value-driven decision step:
Assess → Rationalize → Convert → Reconcile
Assess — inventory + governance inference + per-asset complexity, value, effort (1-5), and a usage proxy (dependent cards + refresh cadence + scale).
Rationalize — decide each asset's disposition (Retire · Repoint · Rebuild · Elevate · Consolidate) and target surface (AI/BI + Genie · Genie App Builder · Sigma Input Tables · Apps + Lakebase); suggestions are pre-filled from the assess signals. Filtered discovery narrows the estate, and a saved filter set is a migration wave.
Convert — transpile Magic ETL / SQL DataFlows to Lakeflow pipelines + Unity Catalog metric views; recover Domo orchestration (schedules + dataflow dependencies) and map it to Databricks Workflows.
Reconcile — schema-parity gate on the rebuilt gold.
A future-state estimate rolls the effort scores + decisions into migration FTE-weeks, a target consumption size, and (with your Domo spend) a savings frame.
It packages the Domo discovery / assessment / migration workflow two ways over one engine:
an MCP server (FastMCP, stdio + streamable-HTTP) so an AI client (Claude Code, Cursor, Genie Code, …) can drive the migration conversationally, and
an operator web console (FastAPI + a zero-build HTML/JS frontend) that lets you click a Magic ETL or dashboard, Analyze its data flow, Draft the Databricks pipeline code, and Create it — with catalog/schema config.
It runs fully offline on synthetic fixtures shaped after Domo's public REST API — no live tenant, no Databricks workspace, no network required. When you're ready, point it at a real Domo tenant (OAuth) and a real Databricks workspace (CLI/OAuth) via config, and the same tools deploy real Lakeflow Declarative Pipelines.
Everything ships customer-agnostic. The bundled data is a fictional company ("Northwind Manufacturing"). The industry data models under
models/are vendored from the open-source Databricks Industry Data Models; the MCP scaffold follows the ai-dev-kitdatabricks-mcp-serverpattern.
It impersonates the surface of a Domo tenant (datasets, dataflows, cards,
pages, sources) so the whole discover → assess → analyze → draft → create
workflow is exercisable before you have tenant credentials. All tenant reads go
through a provider abstraction (pseudo_domo_mcp/providers/): FixtureProvider
(default, offline) today; LiveProvider (real Domo REST — OAuth2
client_credentials) when creds land. Swapping is one config change; the tools
never change.
Related MCP server: Databricks MCP Server
The console is a wizard:
Configure ─► Connect ─► Discover ─► Assess ─► Plan ─► Build & DeployConfigure / Connect — set the Databricks target + Domo provider, then connect (fixture mode connects instantly to the bundled sample tenant).
Discover — a Discovery Scan builds a typed, searchable inventory of every asset: connectors, Magic ETL, SQL DataFlows, DataSets, cards, Beast Modes, pages. Search by name and filter by type. Connectors are first-class and each carries a Databricks ingestion remap plan (Lakeflow Connect / Auto Loader / Apps+Lakebase), because source connections are what must be explicitly re-mapped.
Assess — governed vs. shadow IT is inferred (Domo has no governance field) from source/connector type, writeback, owner shape, and refresh cadence, with a confidence score and the signals behind each call shown for confirm/override.
Plan — a value-driven wave plan + per-connector ingestion strategy.
Build & Deploy — pick a migratable asset →
Analyze: the Magic ETL DAG as a medallion-layered (bronze → silver → gold) SVG, built from the same parser that transpiles it.
Draft: the 6-agent transpiler returns bronze/silver/gold Spark SQL + a semantic view folding the card's Beast Modes + a PASS/FAIL reconcile gate.
Create (progressive): always writes a deployable Databricks Asset
Bundle (databricks.yml + SQL) and shows the deploy command; deploys via
databricks bundle deploy when a profile is set; optionally commits the
bundle to a linked GitHub / Azure DevOps repo as a PR.
Config is reachable anytime via ⚙ Config.
Tool | What it does |
| Inventory the tenant — datasets/dataflows/cards/pages/sources + an inferred governed/shadow split. |
| Typed, searchable asset inventory (connector / magic_etl / sql_dataflow / dataset / card / beast_mode / page); connectors carry a Databricks remap plan. |
| Classify each object by data domain + source, infer governance (with signals + confidence), score complexity and value. |
| List vendored industry models ( |
| Draft-map a Domo DataSet's columns → a canonical industry-model table (similarity + confidence + unmapped flags). |
| Score each source system GREEN/AMBER/RED for Lakeflow Connect ingestion + recommended pattern. |
| 6-agent transpiler → medallion Spark SQL + folded Beast Modes + repoint plan + reconcile gate. |
| Aggregate all of the above into a prioritized, value-driven wave plan. |
Python 3.11+. Runtime dependencies are declared in pyproject.toml and
mirrored in requirements.txt (the Databricks App runtime installs from the
latter):
Package | Why |
| the MCP server (stdio + streamable-HTTP) |
| the web console + file uploads |
| Lakebase credentials + App service-principal auth. Pinned — a loose range lets the App runtime resolve a version without the |
| the Lakebase (Postgres) store backend |
databricks-sdk + psycopg are only exercised when store_backend=lakebase
(or when running as an App); with the default local file store the tool needs
neither at runtime.
Databricks machines have no direct PyPI egress, so
pyproject.toml's[tool.uv]pins the internal mirror. Off-network, override it withuv pip install -e . --index-url https://pypi.org/simple/.
uv venv --python 3.11 .venv && source .venv/bin/activate
uv pip install -e . # uses the mirror pinned in pyproject [tool.uv]
# 1) Web console (browse → analyze → draft → create)
python -m pseudo_domo_mcp.webapp.app # http://127.0.0.1:8010
# 2) MCP server — stdio (for Claude Code / Cursor)
python -m pseudo_domo_mcp.server
# 3) MCP server — HTTP
PSEUDO_DOMO_TRANSPORT=http PORT=8000 python -m pseudo_domo_mcp.server
127.0.0.1:8000/mcpis the MCP protocol endpoint (it speakstext/event-stream), not a web page — open a browser at the web console port instead.
.mcp.json in this repo registers the stdio server. Then ask, e.g.:
"Discover the Domo tenant, give me the migration plan, then transpile the pilot."
Set in the web console's ⚙ Config panel or via env (persisted to
.pseudo_domo_config.json, git-ignored):
Setting | Purpose |
| Default Unity Catalog target for generated pipelines. Overridable per asset at Create (a domain/BU can target its own catalog/schema). |
|
|
| Which Databricks Industry Data Model(s) to draft-map onto (universal; references the open-source repo). Multi-select. |
| Databricks CLI profile ( |
|
|
| Domo OAuth2 client_credentials. The secret is read from the environment, never written to config. |
| State persistence: |
| Optional LLM enhancement via a Databricks model serving endpoint (e.g. |
| Optional: link a GitHub or Azure DevOps repo so Create commits the generated bundle as a PR. Token read from env, never stored. |
Precedence: persisted config (local file, or the store in an App) is overlaid by environment variables, so
app.yaml/ shell env always win.
The SDP/DAB patterns the tool generates against are not hardcoded — they track the ai-dev-kit repo. A pattern manifest is cached locally and refreshed on install; re-refresh anytime via ⚙ Config → Refresh patterns from ai-dev-kit. Fully offline-safe: with no network, built-in defaults apply.
The same codebase runs locally and as a fully managed Databricks App — no
fork. core/runtime.py detects the App runtime (the DATABRICKS_APP_NAME env
var the platform injects) and flips a few seams; local behaviour is untouched:
Seam | Local | Databricks App |
Web bind |
|
|
Config persistence |
| the store (Lakebase) — an App's filesystem is ephemeral + per-replica |
Store backend | from the config file | from injected env ( |
LLM auth |
| the App service principal's OAuth token (via the SDK) |
It ships as two apps over one engine:
Console — app.yaml (repo root): python -m pseudo_domo_mcp.webapp.app.
MCP server — deploy/mcp.app.yaml: python -m pseudo_domo_mcp.server
over streamable-HTTP. For Genie Code discovery the app name must start with
mcp-.
App env (set in app.yaml): PORT=8000, PSEUDO_DOMO_PROVIDER=fixture,
PSEUDO_DOMO_STORE_BACKEND (lakebase for the console / local for the MCP),
PSEUDO_DOMO_LAKEBASE_INSTANCE, PSEUDO_DOMO_LLM_ENDPOINT.
P=<your-cli-profile>
WS=/Workspace/Users/<you>/domo-migration-console
# 1) Create the app (provisions its service principal)
databricks apps create domo-migration-console -p $P
# 2) Sync source + deploy
databricks sync . $WS --full \
--exclude .venv --exclude .git --exclude __pycache__ \
--exclude generated --exclude .pytest_cache -p $P
databricks apps deploy domo-migration-console --source-code-path $WS -p $PThen attach two resources (CLI databricks apps update, or App UI → Edit):
Database → your Lakebase instance, permission Can connect and create
(auto-injects PGHOST/PGUSER/PGDATABASE/PGPORT).
Model serving → the LLM endpoint, permission Can query.
…and register the app's service principal as a Lakebase Postgres role so its OAuth token can log in (Lakebase identity federation):
databricks api post /api/2.0/database/instances/<instance>/roles -p $P --json '{
"name": "<app-service-principal-client-id>",
"identity_type": "SERVICE_PRINCIPAL",
"membership_role": "DATABRICKS_SUPERUSER"
}'Redeploy after attaching resources so the injected env is picked up. To
verify, set PSEUDO_DOMO_DEBUG=1 in app.yaml and hit GET /api/debug/store
(backend + connect error) and /api/debug/llm (a live model round-trip) — both
behind the App's SSO, and both off unless the flag is set. Remove the flag once
verified.
Apps only read app.yaml at the source root, so deploy the MCP manifest by
importing it over that folder's app.yaml:
WS=/Workspace/Users/<you>/mcp-domo-migration
databricks apps create mcp-domo-migration -p $P
databricks sync . $WS --full --exclude .venv --exclude .git \
--exclude __pycache__ --exclude generated --exclude .pytest_cache -p $P
databricks workspace import $WS/app.yaml --file deploy/mcp.app.yaml \
--format RAW --overwrite -p $P
databricks apps deploy mcp-domo-migration --source-code-path $WS -p $PThe MCP app uses store_backend=local (assessment tools are stateless), so its
service principal needs no Lakebase role.
Pin databricks-sdk (see Requirements) — a loose range silently drops
Lakebase to local storage.
App updates drop the SP's Lakebase grants — re-attach the Database resource after editing the app.
Two app.yamls, one repo — a databricks sync into the MCP app's folder
overwrites its app.yaml with the console's; re-import deploy/mcp.app.yaml
before deploying the MCP app.
Create in an App writes the bundle and (optionally) opens a git PR — it
does not shell out to databricks bundle deploy (no CLI on the App path);
use a configured CLI profile locally for in-place deploys.
python -m pytest -q # end-to-end: discover→assess→map→feasibility→transpile gate→planLiveProvider (pseudo_domo_mcp/providers/live_provider.py) documents the exact
Domo REST endpoint map (verified against developer.domo.com). Domo has two API
planes, and a full migration inventory needs both:
Public API (https://api.domo.com, OAuth2 client_credentials; scopes
data user dashboard audit …) — the census + schemas: GET /v1/datasets,
/v1/datasets/{id} (schema.columns), /v1/pages, /v1/cards (metadata
only), /v1/streams, /v1/users, /v1/groups.
Instance API (https://{instance}.domo.com, X-DOMO-Developer-Token) —
the transform internals: GET /api/dataprocessing/v1/dataflows[/{id}] (Magic
ETL DAG + SQL body) and /api/content/v1/cards (Beast Mode expressions).
So the migration triplet = instance dataflow internals + public dataset schema +
instance card export. The public API alone gives the census + schemas but not the
transform logic or Beast Modes. To go live: set domo_provider=live + OAuth
credentials (and DOMO_INSTANCE + DOMO_DEVELOPER_TOKEN for the transform
triplet), then implement the stubbed reads.
app.yaml Databricks App manifest — CONSOLE (repo root)
requirements.txt runtime deps for the App runtime (mirrors pyproject)
deploy/
mcp.app.yaml Databricks App manifest — MCP server
pseudo_domo_mcp/
server.py FastMCP server (stdio + streamable-http)
webapp/ FastAPI console + zero-build HTML/CSS/JS frontend
tools/ thin @mcp.tool wrappers (one per capability)
core/ engine: runtime (local vs App detection), provider
select, DDL parse, classify, governance inference, map,
feasibility, assets (typed inventory), graph (DAG),
config, store (local JSON | Lakebase), llm (optional
serving-endpoint enhancement), bundle (DAB writer), gitlink
providers/ FixtureProvider (offline) | LiveProvider (Domo REST stub)
transpiler/ 6-agent Domo→Databricks transpiler + importable pipeline.run()
fixtures/
tenant/ synthetic Domo census (datasets/dataflows/cards/pages)
lineages/ full triplets (Magic ETL + schema + Beast Modes) for transpile
models/ vendored industry-model DDL (automotive, transport_shipping)
tests/ end-to-end pytestdocs/GUIDE.md — install, the full Assess → Rationalize → Convert → Reconcile workflow, the MCP tool + REST reference, and going live.
docs/FAQ.md — what it is, how it relates to Lakebridge, scoring/usage, dispositions & surfaces, orchestration, estimation, and more.
See LICENSE. Vendored industry-model DDL retains its upstream license (see
models/README.md).
Assess the Domo estate: classify by data domain + source, score governance and migration complexity, and tag business value.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | "dataflows" (default) assesses each DataFlow + its card; "cards" assesses cards standalone; "summary" returns portfolio rollups. | dataflows |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions high-level activities (classify, score, tag) but does not specify whether the tool is read-only, has side effects, requires specific permissions, or what the output format is beyond input schema hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's purpose. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and an output schema (not shown but noted), the description sufficiently covers the main functionality. It could be slightly improved by hinting at the output structure, but overall it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'scope' is fully described in the input schema (100% coverage). The description does not add extra semantics beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool assesses the Domo estate by classifying, scoring, and tagging. It distinguishes from siblings like domo_discover and domo_inventory, which focus on discovery and inventory, respectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description: use when you need to assess the Domo estate. However, no explicit when-to-use or when-not-to-use guidance is provided, and no alternatives are mentioned in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inventory the Domo tenant for a migration assessment.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | What to return. One of: "summary" — counts + governance split + source systems (default) "datasets" — the DataSet census "dataflows" — the DataFlow (Magic ETL / SQL) census "cards" — the Card census "pages" — the Page (dashboard) census "sources" — distinct upstream source systems "all" — every census in one payload | summary |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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, but it only states the purpose without describing behavior such as read-only nature, side effects, rate limits, or authentication needs. The minimal description leaves the agent guessing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—one sentence covering purpose. It is front-loaded but could benefit from including usage guidelines without adding much length. Still, it is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (1 parameter, no required fields, output schema present), the description is adequate. However, it lacks context about what the output represents or how it supports migration assessment, which would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the parameter 'scope' has a detailed description in the schema. The tool description adds no extra meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Inventory'), the target ('the Domo tenant'), and the context ('for a migration assessment'). It is specific and distinct from sibling tools like 'domo_inventory' and 'domo_assess'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. There is no mention of when not to use it or which sibling tool might be more appropriate for specific tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Typed, searchable asset inventory of the Domo estate.
Domo work is organized by object type; this returns every asset with a common shape plus type-specific fields, optionally filtered.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | case-insensitive substring match on the asset name. | |
| asset_type | No | filter to one type — connector | magic_etl | sql_dataflow | dataset | card | beast_mode | page. Empty = all types. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions returning 'every asset' and 'optionally filtered', but does not disclose behavioral traits like pagination, performance, rate limits, or error handling, which are important for a read-based inventory tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief with two sentences, front-loading the core purpose. It is efficient but could incorporate usage guidance without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (asset inventory with type-specific fields) and the presence of an output schema, the description is adequate but lacks details about return values, filtering behavior, or limitations. It does not fully compensate for the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with parameter descriptions, so the baseline is 3. The tool description adds little beyond the schema: it restates 'optionally filtered' but does not provide additional context or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Typed, searchable asset inventory of the Domo estate' and specifies it returns assets with common shape and type-specific fields. However, it does not differentiate from sibling tools like domo_discover or domo_assess.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching and filtering assets via parameters, but it provides no explicit guidance on when to use this tool versus the listed siblings, nor does it mention prerequisites or exclusion cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draft-map a Domo DataSet's columns onto a canonical industry-model table.
Conforms a Domo output DataSet to the Databricks Industry Data Model ("silver") so the transpiled pipeline lands governed, standard entities rather than a like-for-like copy.
| Name | Required | Description | Default |
|---|---|---|---|
| industry | No | target model key (e.g. "automotive", "transport_shipping"). | automotive |
| overrides | No | {domo_column: target_column | ""} human column choices. | |
| dataset_id | No | the Domo DataSet id to map; OR | |
| lineage_id | No | a Build lineage id — its output DataSet is mapped. | |
| prefer_domain | No | bias table selection; inferred from name if omitted. | |
| force_table_fqn | No | pin the target table (user re-selected it in the UI). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes a 'Draft-map' action, suggesting a planning step rather than a direct transformation, but does not disclose specifics like error handling, irreversibility, or side effects. Some transparency but gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—two sentences with no wasted words. The first sentence clearly states the action, and the second provides context. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no annotations), the description could be more complete. It lacks guidance on how to use parameters like 'overrides' or behavior when data is missing. However, the output schema exists and provides return value info, so the description is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 6 parameters have descriptions in the input schema (100% coverage). The overall description adds context about conforming to a canonical model, but does not provide additional per-parameter semantics beyond what the schema already offers. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Draft-map a Domo DataSet's columns onto a canonical industry-model table.' It uses a specific verb ('draft-map') and resource ('DataSet columns to industry model'), and distinguishes from sibling tools like 'list_industry_models' (listing) and 'transpile_lineage' (transpilation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage during mapping before transpilation ('so the transpiled pipeline lands governed...'), but does not explicitly state when to use vs. when not to. No exclusions or alternatives are provided, though siblings hint at different steps. Guidance is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score Domo source systems for Lakeflow Connect ingestion feasibility.
For each upstream source feeding the Domo estate, returns GREEN/AMBER/RED plus the recommended Databricks ingestion pattern (managed connector vs Auto Loader vs Lakebase re-platform) and a rationale — the input to sequencing the 28-source migration.
| Name | Required | Description | Default |
|---|---|---|---|
| source_system | No | optional — score just one source (e.g. "SQL Server"); omit to score every source discovered in the tenant, ranked GREEN-first. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It clearly explains that omitting source_system scores all discovered sources ranked GREEN-first, and specifies the return types (GREEN/AMBER/RED plus pattern and rationale). It does not mention side effects or permissions, but as a scoring tool it is likely read-only and non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a two-paragraph structure with a clear purpose verb in the first sentence, followed by specific output details and context. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single optional parameter and rich output, the description fully covers what the tool does, how to use it, and what to expect. It references the broader migration context (28-source sequencing) and ties to sibling tools implicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds significant meaning beyond the schema: it explains the behavior when source_system is omitted (score all, ranked GREEN-first) and provides an example value ('SQL Server'). This effectively clarifies optionality and default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'score' and resource 'Domo source systems for Lakeflow Connect ingestion feasibility', specifying the output (GREEN/AMBER/RED, pattern, rationale) and context (28-source migration). It distinguishes from siblings like domo_discover and domo_assess by focusing on feasibility scoring rather than discovery or assessment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for scoring source systems to plan migration sequencing, but it does not explicitly state when not to use this tool or provide alternatives. The reference to 'input to sequencing the 28-source migration' gives context, but exclusions or sibling comparisons are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available Databricks Industry Data Models (and their domains).
| Name | Required | Description | Default |
|---|---|---|---|
| industry | No | optional — if given (e.g. "automotive"), returns that model's domains and table count; otherwise lists all vendored industries. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full responsibility. It does not disclose any behavioral traits beyond the basic listing action (e.g., whether it requires authentication, any side effects, or performance implications). The read-only nature is implied but not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's purpose. No wasted words; every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter) and the presence of an output schema, the description is mostly complete. It could benefit from a brief note on what 'domains' refers to, but not critical for understanding the basic function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'industry', with a clear description of its optional use. The tool description adds no further meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('Databricks Industry Data Models'). It also mentions the optional inclusion of domains, providing specific scope. However, it does not explicitly differentiate from sibling tools like 'industry_model_map', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There is no mention of use cases, prerequisites, or exclusions. The sibling tools are listed but the description offers no comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Produce the prioritized Domo->Databricks migration plan.
Combines the tenant census, per-dataflow assessment, and per-source Lakeflow Connect feasibility into a wave-sequenced plan ranked by business value then migration complexity. This is the structured "assessment deliverable" a customer engagement produces.
Returns waves, the governance split, source feasibility rollup, and the recommended pilot. All figures are draft-grade until live tenant data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the output structure (waves, governance split, source feasibility rollup, recommended pilot) and that figures are 'draft-grade'. This adds useful behavioral context beyond a simple 'produce plan'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and then elaborates on inputs and outputs. It is reasonably concise but could be slightly tighter by merging the second and third sentences without loss of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema that likely details return fields, the description fully covers what the tool does and what it returns. No missing information is evident for an agent to decide whether to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description need not add param details. It compensates by explaining what the tool produces and how it combines inputs, which is valuable semantics for an agent with no configurable inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Produce the prioritized Domo->Databricks migration plan') and clearly states the resource (migration plan). It distinguishes from sibling tools like domo_assess and domo_discover by positioning this as the final 'assessment deliverable' that combines multiple inputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used after census, assessment, and feasibility steps, but does not explicitly state when NOT to use it or provide alternative tools for different scenarios. The context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transpile one Domo lineage triplet into a Databricks SDP medallion.
Runs the 6-agent transpiler (Ingest -> Parse -> Emit -> BeastMode -> Repoint -> Reconcile) over a lineage's triplet (Magic ETL + DataSet schema
card Beast Modes) and returns the emitted bronze/silver/gold Spark SQL, the folded semantic-metrics view, the Domo->Databricks connector-swap plan, and the PASS/FAIL reconciliation gate.
| Name | Required | Description | Default |
|---|---|---|---|
| out_dir | No | optional directory for the emitted .sql/.json artifacts; defaults to a temp dir. | |
| industry | No | industry model to tag the value driver against. | automotive |
| lineage_id | Yes | the triplet lineage id (e.g. "customer360"). Get valid ids from domo_assess (assessments with has_triplet=true). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and reveals the internal 6-agent transpiler process (Ingest, Parse, Emit, BeastMode, Repoint, Reconcile) and the specific outputs (bronze/silver/gold SQL, semantic-metrics view, connector-swap plan, reconciliation gate). It also explains the input composition (Magic ETL, DataSet schema, card Beast Modes). However, it does not disclose side effects, authentication needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences that front-load the purpose in the first sentence and elaborate on the process and outputs in the second. Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6-agent transpiler with multiple outputs), the description adequately covers the process, inputs, and outputs. An output schema exists to document return values, so the description focuses on what the tool does. It also mentions a prerequisite (lineage_id from domo_assess), making it complete for an agent to understand usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema: for lineage_id, it notes that valid IDs come from domo_assess; for out_dir, it clarifies the default behavior; for industry, it explains the purpose of tagging. This extra information improves parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to transpile a Domo lineage triplet into a Databricks SDP medallion. It specifies the verb 'Transpile,' the resource 'Domo lineage triplet,' and the outcome 'Databricks SDP medallion.' It also lists the 6-agent transpiler steps and outputs, distinguishing it clearly from sibling tools like domo_assess or migration_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It only hints at a prerequisite by mentioning that valid lineage_ids come from domo_assess, but provides no guidance on when to choose transpile_lineage over other tools such as domo_discover or lakeflow_feasibility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0domo_assessdomo_discoverdomo_inventoryindustry_model_maplakeflow_feasibilitylist_industry_modelsmigration_plantranspile_lineageScored across 8 tools
Most tools have clearly distinct purposes, such as 'domo_inventory' for detailed typed inventory vs 'domo_discover' for initial assessment. The only potential overlap is between 'domo_discover' and 'domo_inventory', but descriptions clarify they serve different stages.
Names use a mix of verb-first (domo_discover, domo_assess, transpile_lineage) and noun-first (domo_inventory, industry_model_map, migration_plan) patterns. While all snake_case, the inconsistent verb/noun ordering and varying prefixes reduce predictability.
With 8 tools covering discovery, inventory, assessment, mapping, feasibility, transpilation, and planning, the count is well-scoped for a migration accelerator. Each tool serves a distinct, necessary function without redundancy.
The tool set covers the core migration workflow from discovery to planning, including industry model mapping and lineage transpilation. Minor gaps exist, such as no tool for post-migration execution or validation, but agents can work around these.
Your Databricks Lakehouse in natural language: run SQL on your SQL warehouses, track long-running qu
List datasets, schemas, run APL queries, and use prompts for exploration, anomalies, and monitoring.
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
The grounded data layer for any LLM: governed SQL, metrics, lineage and catalog over your data.
