Skip to main content
Glama
bpamiri

CockroachDB MCP Server

by bpamiri

get_foreign_keys

Retrieve foreign key constraints for a specified table in CockroachDB to understand table relationships and enforce data integrity.

Instructions

Get foreign key constraints for a table.

Args:
    table: Table name (schema.table or just table).

Returns:
    Foreign key information.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tableYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • Core handler function that queries information_schema for foreign key constraints on the given table and returns structured FK information.
    async def get_foreign_keys(table: str) -> dict[str, Any]:
        """Get foreign key constraints for a table.
    
        Args:
            table: Table name (schema.table or just table).
    
        Returns:
            Foreign key information.
        """
        conn = await connection_manager.ensure_connected()
    
        # Parse schema and table name
        if "." in table:
            schema, table_name = table.rsplit(".", 1)
        else:
            schema = "public"
            table_name = table
    
        try:
            async with conn.cursor() as cur:
                await cur.execute(
                    """
                    SELECT
                        tc.constraint_name,
                        kcu.column_name,
                        ccu.table_schema AS foreign_table_schema,
                        ccu.table_name AS foreign_table_name,
                        ccu.column_name AS foreign_column_name
                    FROM information_schema.table_constraints AS tc
                    JOIN information_schema.key_column_usage AS kcu
                        ON tc.constraint_name = kcu.constraint_name
                        AND tc.table_schema = kcu.table_schema
                    JOIN information_schema.constraint_column_usage AS ccu
                        ON ccu.constraint_name = tc.constraint_name
                        AND ccu.table_schema = tc.table_schema
                    WHERE tc.constraint_type = 'FOREIGN KEY'
                    AND tc.table_schema = %s
                    AND tc.table_name = %s
                """,
                    (schema, table_name),
                )
                rows = await cur.fetchall()
    
            foreign_keys = []
            for row in rows:
                foreign_keys.append(
                    {
                        "constraint_name": row.get("constraint_name"),
                        "column": row.get("column_name"),
                        "references_schema": row.get("foreign_table_schema"),
                        "references_table": row.get("foreign_table_name"),
                        "references_column": row.get("foreign_column_name"),
                    }
                )
    
            return {
                "schema": schema,
                "table": table_name,
                "foreign_keys": foreign_keys,
                "count": len(foreign_keys),
            }
        except Exception as e:
            return {"status": "error", "error": str(e)}
  • MCP tool registration using @mcp.tool() decorator, which delegates to the core handler in tools.tables.
    @mcp.tool()
    async def get_foreign_keys(table: str) -> dict[str, Any]:
        """Get foreign key constraints for a table.
    
        Args:
            table: Table name (schema.table or just table).
    
        Returns:
            Foreign key information.
        """
        try:
            return await tables.get_foreign_keys(table)
        except Exception as e:
            return {"status": "error", "error": str(e)}
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves information (implied read-only), but doesn't cover critical aspects like whether it requires an active connection, potential permissions needed, error handling (e.g., for invalid table names), or performance considerations. For a database tool with no annotation coverage, this leaves significant gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately concise and well-structured. It starts with the core purpose, followed by 'Args' and 'Returns' sections in a clear format. Every sentence adds value, with no redundant information, though it could be more front-loaded with key behavioral details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (single parameter, read operation) and the presence of an output schema (which handles return values), the description is minimally adequate. However, it lacks context about dependencies (e.g., connection state), error cases, and comparison to siblings, making it incomplete for safe and effective use without additional inference.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds minimal semantic value beyond the input schema. It specifies that the 'table' parameter is the 'Table name (schema.table or just table)', which clarifies format options not in the schema (0% coverage). However, it doesn't explain constraints (e.g., case sensitivity, existence requirements) or provide examples, leaving the agent to guess implementation details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get foreign key constraints for a table.' It specifies the verb ('Get') and resource ('foreign key constraints for a table'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from siblings like 'describe_table' or 'get_table_stats', which might also provide structural metadata.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a connection or specific database context) or compare it to sibling tools like 'describe_table' that might offer overlapping functionality. The agent must infer usage from the purpose alone.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bpamiri/cockroachdb-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server