Skip to main content
Glama
apache

Doris MCP Server

Official
by apache

get_table_column_comments

Retrieve column comments for a specified table in Doris MCP Server. Input the table name and optional database name to access metadata insights efficiently.

Instructions

[Function Description]: Get comment information for all columns in the specified table.

[Parameter Content]:

  • table_name (string) [Required] - Name of the table to query

  • db_name (string) [Optional] - Target database name, defaults to the current database

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
db_nameNo
table_nameYes

Implementation Reference

  • Core handler function that executes the SQL query to fetch column names and comments from information_schema.columns and formats them into a dictionary.
    async def get_column_comments_async(self, table_name: str, db_name: str = None, catalog_name: str = None) -> Dict[str, str]:
        """Async version: get comments for all columns in a table."""
        try:
            effective_db = db_name or self.db_name
            effective_catalog = catalog_name or self.catalog_name
    
            query = f"""
            SELECT 
                COLUMN_NAME, 
                COLUMN_COMMENT 
            FROM 
                information_schema.columns 
            WHERE 
                TABLE_SCHEMA = '{effective_db}' 
                AND TABLE_NAME = '{table_name}'
            ORDER BY 
                ORDINAL_POSITION
            """
    
            rows = await self._execute_query_with_catalog_async(query, effective_db, effective_catalog)
            comments: Dict[str, str] = {}
            for col in rows or []:
                name = col.get("COLUMN_NAME", "")
                if name:
                    comments[name] = col.get("COLUMN_COMMENT", "") or ""
            return comments
        except Exception as e:
            logger.error(f"Failed to get column comments asynchronously: {e}")
            return {}
  • MCP-specific wrapper method that calls the core get_column_comments_async handler and formats the response.
    async def get_table_column_comments_for_mcp(
        self, 
        table_name: str, 
        db_name: str = None, 
        catalog_name: str = None
    ) -> Dict[str, Any]:
        """Get comment information for all columns in specified table - MCP interface"""
        logger.info(f"Getting table column comments: Table: {table_name}, DB: {db_name}, Catalog: {catalog_name}")
        
        if not table_name:
            return self._format_response(success=False, error="Missing table_name parameter")
        
        try:
            comments = await self.get_column_comments_async(table_name=table_name, db_name=db_name, catalog_name=catalog_name)
            return self._format_response(success=True, result=comments)
        except Exception as e:
            logger.error(f"Failed to get table column comments: {str(e)}", exc_info=True)
            return self._format_response(success=False, error=str(e), message="Error occurred while getting table column comments")
  • Routing handler in tools_manager that delegates the tool execution to MetadataExtractor.
    async def _get_table_column_comments_tool(self, arguments: Dict[str, Any]) -> Dict[str, Any]:
        """Get table column comments tool routing"""
        table_name = arguments.get("table_name")
        db_name = arguments.get("db_name")
        catalog_name = arguments.get("catalog_name")
        
        # Delegate to metadata extractor for processing
        return await self.metadata_extractor.get_table_column_comments_for_mcp(
            table_name, db_name, catalog_name
        )
  • MCP tool registration decorator and wrapper function that routes to the internal call_tool dispatcher.
            # Get table column comments tool
            @mcp.tool(
                "get_table_column_comments",
                description="""[Function Description]: Get comment information for all columns in the specified table.
    
    [Parameter Content]:
    
    - table_name (string) [Required] - Name of the table to query
    
    - db_name (string) [Optional] - Target database name, defaults to the current database
    
    - catalog_name (string) [Optional] - Target catalog name for federation queries, defaults to current catalog
    """,
            )
            async def get_table_column_comments_tool(
                table_name: str, db_name: str = None, catalog_name: str = None
            ) -> str:
                """Get table column comments"""
                return await self.call_tool("get_table_column_comments", {
                    "table_name": table_name,
                    "db_name": db_name,
                    "catalog_name": catalog_name
                })
  • Tool schema definition including input schema validation for the get_table_column_comments tool.
                Tool(
                    name="get_table_column_comments",
                    description="""[Function Description]: Get comment information for all columns in the specified table.
    
    [Parameter Content]:
    
    - table_name (string) [Required] - Name of the table to query
    
    - db_name (string) [Optional] - Target database name, defaults to the current database
    
    - catalog_name (string) [Optional] - Target catalog name for federation queries, defaults to current catalog
    """,
                    inputSchema={
                        "type": "object",
                        "properties": {
                            "table_name": {"type": "string", "description": "Table name"},
                            "db_name": {"type": "string", "description": "Database name"},
                            "catalog_name": {"type": "string", "description": "Catalog name"},
                        },
                        "required": ["table_name"],
                    },
                ),
Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It states this is a 'Get' operation (implying read-only), but doesn't mention authentication requirements, rate limits, error conditions, or what format the comment information returns. For a tool with no annotation coverage, this leaves significant behavioral gaps.

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

Conciseness3/5

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

The description uses a structured format with sections, which helps organization. However, the '[Function Description]' and '[Parameter Content]' labels add unnecessary verbosity. The content itself is reasonably concise, but the formatting could be more streamlined without losing clarity.

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

Completeness2/5

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

Given no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It covers basic purpose and parameters but lacks crucial information about return format, error handling, and behavioral constraints. For a database query tool with siblings providing related functionality, more context is needed for effective use.

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?

Schema description coverage is 0%, so the description must compensate. It provides parameter information in the '[Parameter Content]' section, explaining what 'table_name' and 'db_name' represent. However, it doesn't clarify format expectations (e.g., case sensitivity, quoting requirements) or provide examples. The description adds meaningful semantics but doesn't fully compensate for the 0% schema coverage.

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 comment information for all columns in the specified table.' This is a specific verb ('Get') + resource ('comment information for all columns') combination. However, it doesn't explicitly distinguish this from its sibling 'get_table_comment' (which presumably gets table-level rather than column-level comments), so it misses the highest score.

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. With siblings like 'get_table_schema' and 'get_table_comment' that might provide related information, there's no indication of when column comments specifically are needed or when other tools might be more appropriate. The only implicit context is the parameter descriptions.

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

Related 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/apache/doris-mcp-server'

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