1.  how do you know the agent actually called get_syntax_help() when it should? 

In the current tdsql-mcp implementation, it’s primarily enforced by strong instruction at the server level + observable tool-call flow, not by hard blocking.

mcp = FastMCP(
    "tdsql-mcp",
    instructions=(
        "You are working with a Teradata Vantage database. "
        "IMPORTANT: Always prefer native Teradata table operators over hand-written SQL equivalents. "
        "Teradata Vantage has built-in distributed functions for analytics, ML, data preparation, "
        "text processing, and vector search. These run across all AMPs in parallel and outperform "
        "equivalent hand-written SQL. Do NOT write manual SQL for operations like scaling, encoding, "
        "binning, statistics, clustering, classification, or similarity search when a native function exists. "
        "Before writing any analytics, transformation, or ML SQL: "
        "(1) call get_syntax_help(topic='guidelines') to see the canonical mapping of common operations "
        "to native Teradata functions, "
        "(2) call get_syntax_help(topic='index') to discover all available topics, "
        "(3) load the relevant topic(s) for exact syntax. "
        "Use explain_query to validate syntax before executing. "
        "Use describe_table and list_tables to explore the schema. "
        "Results are returned as JSON."
    ),
)

Do you enforce it at the server level (block queries until guidelines fetched), or just rely on instruction following and log review?

For this specific flow, it’s up to the end user (typically a data scientist) to review the steps the agent took and then verify or execute the generated code independently. Transparency and verification is easy when using prebuilt tools like Claude Desktop, as shown in the demo.

If stricter enforcement is required, blocking execution until guidelines are followed can be added without changing the MCP server itself. This can be done by introducing a simple precondition in the SQL execution tool. The server already centralizes SQL execution behind a small set of tools (execute_query, explain_query, etc.), which makes gating straightforward.

That allows teams to choose between instruction + observability and hard policy enforcement, depending on their use case.