teradata-gcfr-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOGMECH | No | Auth mechanism: TD2, LDAP, TDNEGO, KRB5 | TD2 |
| PROFILE | No | Active tool profile | all |
| MCP_HOST | No | Bind host for HTTP/SSE (read-only) | 127.0.0.1 |
| MCP_PATH | No | URL path prefix for HTTP transports | /mcp/ |
| MCP_PORT | No | Bind port for HTTP/SSE (read-only) | 8001 |
| CONFIG_DIR | No | Directory scanned for *_tools.yml custom tools | . |
| GCFR_OPR_DB | No | Operational reporting views (GCFR_RV_*) | GDEV1V_OPR |
| DATABASE_URI | Yes | teradata://user:pass@host:1025/db | |
| GCFR_VIEW_DB | No | Base view layer — registration/metadata tools | GDEV1V_GCFR |
| TD_POOL_SIZE | No | Persistent connections in the pool | 5 |
| GCFR_MAX_ROWS | No | Maximum rows any single tool may return | 500 |
| GCFR_TABLE_DB | No | Physical tables — health-check only | GDEV1T_GCFR |
| GCFR_UTLFW_DB | No | BKEY/BMAP surrogate-key views | GDEV1V_UTLFW |
| LOGGING_LEVEL | No | Python logging level | WARNING |
| MCP_TRANSPORT | No | stdio | streamable-http | sse | stdio |
| TD_MAX_OVERFLOW | No | Extra connections allowed under burst load | 10 |
| TD_POOL_TIMEOUT | No | Seconds to wait for a free connection | 30 |
| GCFR_QUERY_TIMEOUT | No | Per-query timeout in seconds | 120 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| gcfr_stream_statusA | Show stream execution history and completion state for a date range. Use this to find out whether a stream ran successfully, is still running, or failed for a given business date. date_from and date_to default to yesterday and today respectively when not supplied. |
| gcfr_current_stream_statusA | Show streams that are actively running RIGHT NOW. Use this first when investigating a running or stuck batch. Optionally filter to a specific stream by providing stream_key. |
| gcfr_stream_business_dateA | Show the current, previous, and next business date for a stream. Use this to understand where a stream's processing date is set and whether it is in sync with the expected calendar date. |
| gcfr_current_process_statusA | Show active processes and their current execution step. Process_State values: 0=started, 1–98=in progress (restart point), 99=complete. Use this to find stuck or long-running processes. Filter by stream_key and/or process_name to narrow results. |
| gcfr_process_historyB | Show process execution history with timing and outcomes for a date range. Use this to understand how long processes took and whether they succeeded. date_from and date_to default to yesterday and today respectively when not supplied. |
| gcfr_process_status_summaryA | Show all processes for a business date — completed vs not completed. If a process did not complete, the error message is included. Use this for a quick end-of-day sign-off check. Defaults to today when business_date is not supplied. |
| gcfr_load_statsA | Show staging load statistics — row counts, rejections, ET errors, UV violations. Key columns: Ctl_Id, File_Id, Business_Date, Process_Name, Rows_Input, Rows_Considered, Rows_Not_Considered, Rows_Rejected, Rows_Inserted, Rows_ET, Rows_UV, Start_Ts, End_Ts, Load_Status. date_from and date_to default to yesterday and today respectively. Optionally filter by ctl_id. |
| gcfr_load_statusA | Show which staging tables loaded successfully for a business date, with row counts. Use this to verify all expected feeds have arrived. Defaults to today when business_date is not supplied. Optionally filter by ctl_id. |
| gcfr_dataset_registeredA | Show source data sets registered for processing and their file extract status. Count_Source vs Count_Target reconciliation is here. date_from and date_to default to yesterday and today respectively. Optionally filter by ctl_id. |
| gcfr_transform_statsA | Show transformation statistics — rows inserted, updated, and deleted per process. Use this to verify data movement through the warehouse. date_from and date_to default to yesterday and today respectively. Optionally filter by ctl_id. |
| gcfr_top_slowest_processesA | Show the N slowest processes by elapsed duration for a business date. Use this to identify performance bottlenecks. top_n must be between 1 and 50 (default 10). Defaults to today when business_date is not supplied. |
| gcfr_top_slowest_streamsB | Show the N slowest streams by elapsed duration. top_n must be between 1 and 50 (default 10). Defaults to today when business_date is not supplied. |
| gcfr_data_trend_loadsA | Show daily load volume trends — total rows loaded per business date. Use this to spot unusual volume changes. date_from and date_to default to yesterday and today respectively. |
| gcfr_data_trend_transformsA | Show daily transform volume trends by business date. date_from and date_to default to yesterday and today respectively. |
| gcfr_failed_processesA | Show failed process instances with full error details. This is the first tool to use when investigating a batch failure. date_from and date_to default to yesterday and today respectively. Optionally filter by stream_key and/or process_name. |
| gcfr_error_logA | Show raw error log entries for root cause investigation. Includes the calling API and step where the error occurred. Sql_Text (CLOB) is excluded from output — ask separately if needed. date_from and date_to default to yesterday and today respectively. Optionally filter by process_name. |
| gcfr_execution_logA | Show step-level execution trace for detailed process debugging. Only populated when GCFR is running at debug level 2 or higher. Sql_Text (CLOB) is excluded from output — ask separately if needed. date_from and date_to default to yesterday and today respectively. Optionally filter by process_name and/or stream_key. |
| gcfr_sla_process_reportB | Compare expected vs actual process start time, end time, and duration. Shows whether SLAs were met. SLA_Run_Duration is returned as a formatted string (INTERVAL DAY TO SECOND). date_from and date_to default to yesterday and today respectively. |
| gcfr_sla_stream_reportB | Compare expected vs actual stream duration SLAs. SLA duration fields are returned as formatted strings. date_from and date_to default to yesterday and today respectively. |
| gcfr_data_lineageA | Trace a target table back to its source objects. Shows the full lineage chain with edge relationships. Returns: Src_Object_Name_FQ, Src_Kind, Edge_Relationship, Tgt_Object_Name_FQ, Tgt_Kind, Crt_Process_Name. Defaults to today when business_date is not supplied. |
| gcfr_health_checkA | Verify the MCP server can reach both GCFR view databases. Run this first if tools are returning errors. Returns status, database names, stream_count, and response_time_ms. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 21 tools
Most tools target a distinct monitoring concern—streams vs processes, current vs historical, load vs transform. A few pairs like load_stats/load_status and process_history/process_status_summary have overlapping row/status information, but descriptions provide enough differentiation.
All tools share the gcfr_ prefix and use snake_case with descriptive subject+report type names (e.g., stream_status, process_history, sla_process_report). Minor structural deviations such as dataset_registered and health_check break the pattern slightly but remain predictable.
21 tools is in the heavy range and each one covers a specific report or query, which is justified by the broad monitoring domain. Still, the count is large enough that an agent may need to scan many similar names.
The tool surface covers the full operational monitoring lifecycle: stream/process status and history, load and transform statistics, failure/error investigation, SLA reporting, performance trends, data lineage, and connectivity health. No obvious dead ends or missing monitoring scenarios are apparent for the stated purpose.