Databricks Domo Migration Accelerator MCP Server

by pete-welch-db

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
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.
Naming Consistency3/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.7/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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 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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/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 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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
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 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.
Usage Guidelines3/5
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.
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 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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
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 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.
Usage Guidelines2/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

databricks-domo-migration-accelerator MCP server

Copy to your README.md:

[![databricks-domo-migration-accelerator MCP server](https://glama.ai/mcp/servers/pete-welch-db/databricks-domo-migration-accelerator/badges/card.svg)](https://glama.ai/mcp/servers/pete-welch-db/databricks-domo-migration-accelerator)

Score Badge

Copy to your README.md:

[![databricks-domo-migration-accelerator MCP server](https://glama.ai/mcp/servers/pete-welch-db/databricks-domo-migration-accelerator/badges/score.svg)](https://glama.ai/mcp/servers/pete-welch-db/databricks-domo-migration-accelerator)

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/pete-welch-db/databricks-domo-migration-accelerator'

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