Skip to main content
Glama
Abeautifulsnow

TDengine Query MCP Server

test_table_exists

Check if a specified stable exists in the current TDengine database configuration. Verify table presence before performing database operations.

Instructions

Important: Check if the stable exists in the current Taos database(涛思数据库) configuration.

    Args:
        stable_name (str): The name of the stable.

    Returns:
        Dict: The `stable_name` exists or not in the current Taos configuration. If the `stable_name` does not exist, an empty dictionary is returned.

        The key of the dictionary is the `stable_name` name, and the value is a boolean indicating whether the `stable_name` exists.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stable_nameYesThe name of the stable

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • Implementation of the "test_table_exists" tool, which checks for the existence of a stable in the TDengine database by executing a SHOW STABLES LIKE query.
    @mcp.tool(name="test_table_exists")
    def test_table_exists(
        ctx: Context,
        stable_name: str = Field(description="The name of the stable"),
    ) -> Dict[str, bool]:
        """**Important**: Check if the `stable` exists in the current `Taos database(涛思数据库)` configuration.
    
        Args:
            stable_name (str): The name of the stable.
    
        Returns:
            Dict: The `stable_name` exists or not in the current Taos configuration. If the `stable_name` does not exist, an empty dictionary is returned.
    
            The key of the dictionary is the `stable_name` name, and the value is a boolean indicating whether the `stable_name` exists.
        """
    
        taos = ctx.request_context.lifespan_context.client
        query = f"SHOW STABLES LIKE '{stable_name}'"
        result = taos.execute_sql(query)
        return {stable_name: bool(result)}
Behavior3/5

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

With no annotations, the description adequately explains return behavior (empty dict if not exists, boolean-valued dict if exists) and implies context-sensitivity ('current' configuration). However, it omits error handling details (e.g., behavior if no database is selected).

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?

Uses Python docstring format (Args/Returns) which is readable but not optimized for MCP conventions. The '**Important**' prefix is unnecessary dramatic flair, and the return value explanation is verbose relative to the simple operation.

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

Completeness4/5

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

For a single-parameter existence check with an output schema present, the description provides sufficient detail about the return data structure and boolean semantics, adequately preparing an agent to interpret results.

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?

Input schema has 100% coverage with 'stable_name' fully documented. The Args section in the description essentially repeats the schema information without adding additional semantic context or usage examples, meeting the baseline expectation.

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?

Clearly states it checks existence of a 'stable' in the current Taos database with specific action verb and resource identification. However, note the terminology mismatch: the tool name uses 'table' while the description consistently uses 'stable' (super table), which could cause confusion.

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?

Fails to provide when-to-use guidance relative to sibling 'get_all_stables' (which lists all stables vs. checking one). While it mentions 'current' database configuration, it doesn't explicitly state prerequisites like requiring 'switch_db' to be called first.

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/Abeautifulsnow/tdengine-mcp'

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