Skip to main content
Glama
aliyun

Alibaba Cloud DMS MCP Server

Official
by aliyun

fixSql

Read-only

Analyze and fix SQL errors by providing the problematic statement, error message, and database ID to resolve database query issues in Alibaba Cloud DMS.

Instructions

Analyze and fix the SQL error based on the provided SQL statement, error message, and database ID.If you don't know the databaseId, first use getDatabase or searchDatabase to retrieve it. (1) If you have the exact host, port, and database name, use getDatabase. (2) If you only know the database name, use searchDatabase. (3) If you don't know any information, ask the user to provide the necessary details. Note: searchDatabase may return multiple databases. In this case, let the user choose which one to use.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
database_idYesDMS databaseId
questionNoNatural language question
sqlYesThe SQL that caused an error
errorYesSQL error message
modelNoOptional: if a specific model is desired, it can be specified here

Implementation Reference

  • Primary handler function implementing the core logic of the 'fixSql' tool by calling the Alibaba Cloud DMS API client.fix_sql_by_meta_agent with the provided parameters.
    async def fix_sql_statement(
            database_id: str = Field(description="DMS databaseId"),
            question: Optional[str] = Field(default=None, description="Natural language question"),
            sql: str = Field(description="The SQL that caused an error"),
            error: str = Field(description="SQL error message"),
            model: Optional[str] = Field(default=None,
                                         description="Optional: if a specific model is desired, it can be specified here")
    ) -> Dict[str, Any]:
        client = create_client()
        req = dms_enterprise_20181101_models.FixSqlByMetaAgentRequest(db_id=database_id, query=question, sql=sql,
                                                                      error=error)
        # if mcp.state.real_login_uid:
        #     req.real_login_user_uid = mcp.state.real_login_uid
        if model:
            req.model = model
        try:
            resp = client.fix_sql_by_meta_agent(req)
            if not resp or not resp.body:
                return None
            data = resp.body.to_map()
            return data
        except Exception as e:
            logger.error(f"Error in fix_sql_statement: {e}")
            raise
  • Registration of the 'fixSql' tool in configured mode (when default_database_id is set), using a wrapper function that calls the primary handler.
    @self.mcp.tool(name="fixSql",
                   description="Analyze and fix the SQL error based on the provided SQL statement and error message.",
                   annotations={"title": "SQL修复", "readOnlyHint": True, "destructiveHint": False})
    async def fix_sql_configured(
            question: Optional[str] = Field(default=None, description="Natural language question"),
            sql: str = Field(description="The SQL that caused an error"),
            error: str = Field(description="SQL error message"),
            model: Optional[str] = Field(default=None,
                                         description="Optional: if a specific model is desired, it can be specified here")
    ) -> Dict[str, Any]:
        result_obj = await fix_sql_statement(database_id=self.default_database_id, question=question, sql=sql,
                                             error=error, model=model)
        return result_obj
  • Direct registration of the primary 'fix_sql_statement' handler as the 'fixSql' tool in full toolset mode (when no default database is configured).
    self.mcp.tool(name="fixSql", description=f"Analyze and fix the SQL error based on the provided "
                                             f"SQL statement, error message, and database ID."
                                             f"{DATABASE_ID_DESCRIPTION}",
                  annotations={"title": "SQL修复", "readOnlyHint": True})(fix_sql_statement)
Behavior3/5

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

Annotations provide readOnlyHint=true, indicating this is a safe read operation. The description adds context about prerequisite steps (retrieving database ID) and potential user interaction for database selection, which is valuable beyond annotations. However, it doesn't disclose behavioral traits like rate limits, error handling, or what 'fix' entails (e.g., returns corrected SQL vs. explanations).

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 sized and front-loaded: the first sentence states the core purpose, followed by prerequisite steps in a numbered list. However, the note about 'searchDatabase' returning multiple databases could be integrated more smoothly, and some phrasing is slightly verbose (e.g., 'If you don't know any information' could be 'If information is missing').

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?

Given the tool's complexity (error analysis/fixing) and lack of output schema, the description is reasonably complete: it covers purpose, prerequisites, and usage guidelines. However, it doesn't explain what the tool returns (e.g., corrected SQL, explanations, or both), which is a gap since there's no output schema to clarify this.

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 100%, so parameters are fully documented in the schema. The description mentions 'database_id', 'sql', and 'error' as required inputs, aligning with the schema but not adding semantic meaning beyond it. It doesn't explain optional parameters like 'question' or 'model', leaving the schema to carry that burden.

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: 'Analyze and fix the SQL error based on the provided SQL statement, error message, and database ID.' This specifies the verb ('analyze and fix'), resource ('SQL error'), and required inputs. It distinguishes from siblings like 'optimizeSql' (performance tuning) and 'answerSqlSyntax' (syntax questions), but doesn't explicitly contrast them.

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

Usage Guidelines5/5

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

The description provides explicit guidance on when to use this tool and alternatives: it instructs to use 'getDatabase' if exact host/port/database name are known, 'searchDatabase' if only the database name is known, and to ask the user if no information is available. It also notes that 'searchDatabase' may return multiple results requiring user selection.

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/aliyun/alibabacloud-dms-mcp-server'

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