|
6 | 6 |
|
7 | 7 | The Teradata MCP server enables rapid creation of domain-focused semantic layers by allowing you to declaratively define custom tools, prompts, cubes, and glossary terms. No code change needed, you can customize the server by placing YAML files in your current working directory. This approach empowers admins and data teams to tailor the MCP experience to specific business domains—without writing Python code or modifying the server itself. |
8 | 8 |
|
| 9 | +You may use the [MCP Customization Agent Skill](https://github.com/Teradata/teradata-mcp-server/blob/main/agentic/skills/teradata-mcp-customisation/SKILL.md) to create semantic layer configuration based on your existing documentation. |
| 10 | + |
9 | 11 | ## Key principles |
10 | 12 |
|
11 | 13 | - **Domain Focus:** Build MCP servers that speak your users' language and provide business-relevant tools and explanations. |
12 | | -- **Controlled Access:** Predefine queries, aggregations, and resources to ensure correctness, security, and optimal resource utilization. |
| 14 | +- **Controlled Access:** Predefine queries, semantic layers, and resources to ensure correctness, security, and optimal resource utilization. |
13 | 15 | - **Declarative Workflow:** All customization is done via YAML—no code changes required. Admins can add, update, or remove domain logic by editing a single file. |
14 | 16 | - **Trustworthy Outcomes:** By specifying queries and logic up front, you avoid the risks of LLMs repeatedly "guessing" at database structure, ensuring reliable, consistent and auditable results. |
15 | 17 |
|
16 | 18 | ### Semantic Layer |
17 | 19 | A semantic layer in this context is a collection of custom tools, prompts, cubes, and glossary terms focused on a specific business domain (e.g., sales, finance, HR). It provides: |
18 | 20 | - **Custom Tools:** Parameterized SQL queries exposed as callable MCP tools. |
| 21 | +- **Cubes:** Semantic container defining business metrics and associated dimensions. Compiles and execute SQL at runtime. |
19 | 22 | - **Prompts:** Predefined user prompts for natural language interactions. |
20 | | -- **Cubes:** Aggregation templates for business metrics, with dimensions and measures. |
21 | 23 | - **Glossary:** Domain-specific terms, definitions, and synonyms, automatically enriched from cubes and tools. |
22 | 24 | - **Profiles:** Named sets of tools, prompts, and resources that enable domain-specific server instantiations. |
23 | 25 |
|
@@ -200,13 +202,13 @@ Each entry in the YAML file is keyed by its name and must specify a `type`. Supp |
200 | 202 | #### Cube |
201 | 203 | - **Required:** |
202 | 204 | - `type`: Must be `cube` |
203 | | - - `sql`: SQL base query |
| 205 | + - `sql`: SQL base query or table |
204 | 206 | - `dimensions`: Dictionary of dimension definitions (each with `expression`) |
205 | 207 | - `measures`: Dictionary of measure definitions (each with `expression`) |
206 | 208 | - **Optional:** |
207 | 209 | - `description`: Text description of the cube |
| 210 | + - `joins`: List of relations definitions add related tables/views to the model. Joins are materialized by the compiler only when needed for a selected dimension/metric requested otherwise. |
208 | 211 | - `parameters`: Dictionary of parameter name (key) and properties (dictionary with `description`, `default`, `optional`, `required`, `type_hint`) - if used in the sql or join conditions |
209 | | - - `joins`: List of join definitions used to add related tables/views only when needed |
210 | 212 |
|
211 | 213 | Cube definitions are exposed as MCP tools. The server generates the tool signature from the cube definition: |
212 | 214 |
|
|
0 commit comments