Skip to main content
Glama
Teradata

Teradata MCP Server

Official
by Teradata
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
Python
Remote

Graph Detectcycles

graph_detectCycles
Read-onlyIdempotent

Detect circular dependencies in a dependency graph to validate DAG integrity and identify objects forming circular references. Returns cycle details, summaries, and stats for pre-deployment checks.

Instructions

Detect circular dependencies (cycles) in the dependency graph.

Pure-Python implementation — no stored procedure required. Issues a single SQL SELECT to fetch the scoped edge set, then performs WCC partitioning followed by iterative DFS cycle detection entirely in the MCP server process.

Use this tool for:

  • Validating graph integrity (DAG property)

  • Finding objects that form circular references

  • Identifying stub-then-replace code patterns

  • Debugging topological sort hangs

  • Pre-deployment cycle checks

Arguments: container_pattern - str: CSV LIKE patterns for container scope. Supports wildcards (%) and CSV format. Examples: 'DFJ%' — single database family '%WBC%,%StGeo%' — multiple families 'DEV01_%,DEV02_%' — multiple prefixes

exclude_objects - str: CSV LIKE patterns to exclude from the scan. Matches against container name (or DB.Object if the pattern contains a dot). Default: '' (no exclusions)

edge_repository - str: Edge repository view/table conforming to the Graph Edge Contract (Src_Container_Name, Src_Object_Name, Src_Kind, Tgt_Container_Name, Tgt_Object_Name, Tgt_Kind columns). For AI-Native Data Products use: '{ProductName}_Semantic.lineage_graph' Call graph_edgeContractDDL to generate a new one. Required — no default.

Returns: ResponseType: formatted response with cycle detection results.

Response structure: { "cycle_details": [...], // One row per node per cycle "cycle_summaries": [...], // One row per cycle with path string "summary_stats": [...] // Single aggregate row }

cycle_details row fields: Cycle_Id, Cycle_Pos, Node_FQ, Cycle_Length, Component_Id

cycle_summaries row fields: Cycle_Id, Cycle_Length, Component_Id, Cycle_Path

summary_stats row fields: Cycle_Count, Total_Nodes_In_Cycles, Components_With_Cycles, Edge_Count, Components_Scanned, Summary_Message

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
edge_repositoryNo
exclude_objectsNo
container_patternYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.1

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the readOnlyHint/idempotentHint annotations by disclosing that it is a pure-Python implementation, issues a single SQL SELECT, runs WCC partitioning and iterative DFS entirely in the MCP server process, and returns a specific response structure. This gives an agent a clear model of execution cost and behavior.

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 long but tightly structured: summary, use cases, arguments, and return format. Each section carries necessary information, with examples and field lists that an agent needs for correct invocation. There is no filler or repetition.

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?

For a tool with no output schema, the description supplies a detailed response structure, field names, parameter examples, and the expected edge_repository format. It also references graph_edgeContractDDL for generating the contract, making it self-sufficient for correct use.

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?

Although the input schema has 0% description coverage, the description's Arguments section fully documents all three parameters with types, defaults, wildcard/CSV semantics, examples, requiredness, and the edge repository contract. This fully compensates for the sparse schema.

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 opens with a precise verb+resource: 'Detect circular dependencies (cycles) in the dependency graph.' It clearly distinguishes this from sibling graph tools like traceLineage or connectedComponents by naming the exact outcome (cycles) and the method (WCC partitioning + DFS cycle detection).

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?

Provides an explicit 'Use this tool for' list covering graph integrity validation, circular reference finding, stub-then-replace patterns, topo-sort debugging, and pre-deployment checks. It does not name alternative sibling tools or state when not to use it, so it stops short of full when/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools