Who is burning the CPU, which tables are joined together in practice, what breaks if this view changes, which columns are full of nulls — each of those is a tool rather than a query someone has to write, and the lineage family runs in Python so it needs no stored procedures installed. Two settings shape a deployment: the profile decides which families a client even sees, keeping an analyst's tool list away from DBA and security tooling, and the row limits are what stop a careless select from filling the context window.
Teradata's own server for its database, grouped into families: base exploration, data quality, DBA and capacity, security, dependency graph analysis, charting, SQL workload clustering and RAG. Which families load is set by a profile.
- Exploration without SQL: base_databaseList, base_tableList, base_tablePreview, base_columnDescription, base_columnMetadata with exact Teradata type codes and character sets, and base_tableDDL
- base_readQuery runs SQL you supply, bounded by DEFAULT_ROW_LIMIT and a hard MAX_ROW_LIMIT so a result set cannot flood the context; base_saveDDL writes an object's DDL to a .sql file
- Data profiling as its own family: qlty_columnSummary across every column at once, qlty_univariateStatistics for one, plus missing values, rows with missing values, negative values, distinct categories and standard deviation
- base_tableAffinity shows which tables co-occur in the same queries — the JOIN relationships nobody documented — and base_tableUsage reports which objects are actually queried and by whom
- DBA coverage: dba_databaseSpace, dba_tableSpace and dba_systemSpace, dba_resusageSummary by time, application and workload, dba_flowControl for throttling events, dba_userDelay for queue waits, dba_sessionInfo, dba_featureUsage, dba_databaseVersion, and the SQL run against a table or by a user
- Security answers: sec_userDbPermissions, sec_rolePermissions and sec_userRoles
- Dependency graph analysis in pure Python, no stored procedures: graph_traceLineage with wildcards, graph_findRootObjects, graph_connectedComponents, graph_detectCycles, graph_bfsLevels, and graph_analyseDatabase running all of them on one shared edge set
- Charts drawn straight from a table — plot_line_chart, plot_pie_chart, plot_polar_chart and plot_radar_chart read the table themselves rather than taking pre-fetched rows
- SQL workload optimisation: sql_Execute_Full_Pipeline clusters high-usage queries, with sql_Analyze_Cluster_Stats and sql_Retrieve_Cluster_Queries for reading the results
- rag_Execute_Workflow answers a question against document context as a single call
- Custom tools, prompts and semantic-layer cubes defined in YAML in a config directory, and hooks that intercept tool calls for monitoring, audit or rate limiting
A Teradata system and uv. It runs as uvx teradata-mcp-server, with the connection in DATABASE_URI in teradata://username:password@host:1025/database form; LOGMECH selects TD2, LDAP, KRB5 or JWT, and TD_POOL_SIZE, TD_MAX_OVERFLOW and TD_POOL_TIMEOUT tune the pool. PROFILE decides which tool families load — all by default — and CONFIG_DIR points at a directory of YAML for custom tools and profiles. MCP_TRANSPORT switches between stdio and streamable-http, with MCP_HOST and MCP_PORT; AUTH_MODE is none or basic, with its own cache TTL and rate limits. Whatever the database account is allowed to do bounds everything above.
One command plus a key — uvx teradata-mcp-server, then supply credentials