teradata-mcp-customisation

You are extending the Teradata MCP server with a semantic layer: domain-specific tools, cubes, prompts, and glossary terms declared in YAML files that the server picks up at startup.

The server is the upstream project at https://github.com/Teradata/teradata-mcp-server. The customisation surface is documented in docs/server_guide/CUSTOMIZING.md; this skill compiles the parts that are easy to get wrong, plus working examples that anyone can run against the DBC system database.

When to use this skill

• Designing a new semantic layer for a Teradata data product (cubes + curated prompts).
• Adding or editing a custom tool / cube / prompt / glossary entry.
• Building a profiles.yml to expose a subset of objects to a given client.
• Debugging why a custom object does not appear in tools/list, prompts/list, or resources/list.
• Migrating a hand-written SQL pattern into a reusable cube the LLM can compose.

Mental model — what each object becomes at runtime

YAML type:	Where it surfaces	Selected by profile section
tool	MCP tool — parameterised SQL the LLM calls	tool:
cube	MCP tool — the server auto-generates a 6-arg aggregator (dimensions, measures, filter, res_filter, order_by, top) plus any custom params you declare	tool:
prompt	MCP prompt — a reusable system / user prompt the client can fetch by name	prompt:
glossary	MCP resource — domain terms surfaced as context resources, enriched with cube measure/dim descriptions	resource:

There is no type: resource. Resources are derived: glossary entries become resources, and cube/tool descriptions feed back into glossary enrichment.

Workflow

1. Locate the config directory. The server reads YAML from --config_dir (CLI) or $CONFIG_DIR (env), defaulting to the current working directory. Drop one or more *.yml files there alongside profiles.yml. Multiple files merge into one namespace keyed by object name.
2. Pick the object type for what you are building. If in doubt, see reference/object-types.md.
3. Write the SQL first, in isolation. Run it in your usual Teradata client until it returns what you want — then wrap it as a tool or cube. For cubes, write the flat denormalised base SQL; let the server build the aggregator on top. See reference/cube-mechanics.md for exactly how the wrapping works (which is critical for understanding filter vs res_filter semantics).
4. Get parameter substitution right. Custom tools support two styles: :param for value binds, {param} for identifier interpolation (database / table names). Cubes also accept custom parameters used inside the base SQL the same way. See reference/parameter-substitution.md.
5. Expose via profiles.yml. Add a profile (or extend an existing one) with regex selectors. See reference/profiles.md for the layering rules and the built-in profiles you can inherit from.
6. Smoke-test the server with the MCP listing flow before pointing a client at it. See reference/deployment.md for the bash curl recipe (initialize → notifications/initialized → tools/list).