Executes SELECT queries on Tencent Cloud TDSQL-C and TDSQL MySQL databases via DMC web API, with tools for instance discovery, login, and schema browsing.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@dmc-mcp-server list databases on the TDSQL-C instance with IP 10.0.0.5"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
通过腾讯云 DMC (Data Management Console) 在 TDSQL-C / TDSQL 数据库实例上执行 SQL 查询的 MCP Server。
浏览器 (腾讯云控制台登录态)
│ Cookie (skey/uin) + mc_gtk (csrfCode)
▼
DMC MCP Server
│ ① 按实例类型搜索 API:
│ TDSQL-C → cynosdb.cloud.tencent.com DescribeClusters (本地过滤 Vip)
│ TDSQL → tdsql.cloud.tencent.com DescribeDCDBInstances (服务端 SearchKey)
│ ② RSA 加密 DB 密码 (PKCS#1 v1.5)
│ ③ POST dms.cloud.tencent.com/api/mysql/dbLogin → token
│ ④ POST dms.cloud.tencent.com/api/mysql/schemaAdmin/commonSql → 查询结果
▼
TDSQL-C / TDSQL MySQL (内网 IP)利用腾讯云 DMC 控制台的 Web API，通过浏览器 Cookie 复用登录态，实现从本地对生产内网数据库的 SQL 查询。
Related MCP server: SQL Server MCP Server
uvx dmc-mcp-servercd dmc-mcp-server
uv sync
uv run dmc-mcp-server在你的 MCP 客户端配置中添加 (如 opencode.jsonc, claude_desktop_config.json):
{
"mcpServers": {
"dmc-mcp-server": {
"command": "uvx",
"args": ["dmc-mcp-server"]
}
}
}Cookie 不写在配置中, 启动后通过
set_cookie工具动态设置.
启动 MCP 后, 通过 Chrome DevTools MCP 在腾讯云控制台页面自动获取:
// Cookie
document.cookie
// mc_gtk (csrfCode) - 从 performance API 提取
performance.getEntriesByType('resource')
.find(e => e.name.includes('csrfCode='))
?.name.match(/csrfCode=(\d+)/)?.[1]然后调用 set_cookie(cookie, mc_gtk) 工具设置.
也可手动从浏览器 DevTools 复制
document.cookie的值, 但 mc_gtk 必须从 performance API 提取.
工具 | 说明 |
| 设置/更新腾讯云控制台 Cookie + mc_gtk |
| 通过内网 IP 搜索数据库实例（同时搜 TDSQL-C 和 TDSQL） |
| 登录数据库实例（会话缓存，不重复登录） |
| 执行 SELECT 查询（仅允许 SELECT） |
| 列出实例上的所有数据库 |
| 列出指定库的表（支持模糊搜索） |
| 查看表结构（列信息 + DDL） |
| 查看已登录的实例列表 |
类型 | dbType | 实例ID前缀 | 搜索 API |
TDSQL-C (CynosDB) |
|
|
|
TDSQL (DCDB) |
|
|
|
find_instance_by_ip 会同时搜索两种类型，返回结果中包含 DbType 字段供 login_instance 使用。
login_instance 的 region_id 参数和 find_instance_by_ip 的 region 参数用于指定集群所在地域。
默认值: region_id=4 / region="ap-shanghai" (上海)
如果你的集群在其他地域，需要传入对应的值:
地域 | region_id | region (API 参数) |
北京 | 1 |
|
上海 | 4 |
|
广州 | 7 |
|
深圳 | 11 |
|
成都 | 16 |
|
重庆 | 23 |
|
南京 | 45 |
|
香港 | 21 |
|
新加坡 | 15 |
|
硅谷 | 13 |
|
法兰克福 | 17 |
|
完整列表见 腾讯云地域文档
双类型支持：同时支持 TDSQL-C (CynosDB) 和 TDSQL (DCDB) 实例
仅 SELECT：SQL 执行层强制限制只允许 SELECT 语句
会话复用：登录过的实例自动缓存 token，不重复登录
自动重连：token 过期时自动重新登录（使用缓存的凭据）
Cookie 动态更新：运行时通过工具更新，无需重启 Server
代理兼容：自动清除系统代理环境变量，避免 socks5 代理导致连接卡死
Cookie 有效期约 2 小时（腾讯云控制台标准），过期需重新获取
SQL 仅支持 SELECT（WITH...SELECT 也允许）
DB 权限取决于 DB 账号本身的 GRANT 权限
TDSQL 需要数据库账号已对 DMC 服务器 IP 段授权（否则登录报 ACCESS_DENIED）
MIT
Execute a SELECT query on a logged-in database instance. Only SELECT statements are allowed (enforced by SQL validation).
Args: instance_id: Instance ID (must be logged in via login_instance first) sql: SELECT SQL statement to execute db_name: Target database name within the instance page_size: Max rows to return, default 50
Returns: Query results as formatted text.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | ||
| db_name | Yes | ||
| page_size | No | ||
| instance_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It clearly states query execution, SELECT enforcement, and default page_size. Lacks details on errors or timeouts but is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded, and efficient: a purpose statement, args list, and return type. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key aspects for a 4-parameter tool with output schema: explains arguments, return type, and default. Could add pagination details but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description adds meaning by explaining each parameter: instance_id (must be logged in), sql (SELECT statement), db_name (target database), page_size (default 50).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it executes a SELECT query on a logged-in database instance and specifies that only SELECT is allowed, distinguishing it from sibling tools like login_instance, list_databases, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It mentions the prerequisite of logging in via login_instance and the restriction to SELECT only. While it doesn't explicitly list when not to use, the context is clear given sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a database instance by its internal Vip (proxy IP). Searches both TDSQL-C (CynosDB) and TDSQL (DCDB) instances.
Typical workflow:
Read the JDBC URL from your config file (e.g. 10.0.0.1:3306)
Call find_instance_by_ip("10.0.0.1", region="ap-guangzhou") to get the InstanceId
Call login_instance with the InstanceId (use the DbType from results, and match region_id)
Call execute_select
Args: ip: Internal Vip address, e.g. "10.0.0.1" region: Tencent Cloud region string, e.g. "ap-shanghai" (default), "ap-beijing", "ap-guangzhou". Must match the region where your cluster is deployed.
Returns: Matching instance info (InstanceId, Name, Vip, DbType) or "not found".
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | ||
| region | No | ap-shanghai |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that it searches both TDSQL-C and TDSQL instances, returns matching info or 'not found', and is part of a workflow implying it is read-only. However, it does not explicitly state it is a read operation or mention authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured, and front-loaded: first line defines purpose, then typical workflow, then parameter details, then return value. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter lookup tool with no annotations, the description covers purpose, usage, parameters, and return value (including fields returned). The typical workflow provides additional context for the expected use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage. The description adds meaning by providing examples for ip ('10.0.0.1') and region ('ap-shanghai', 'ap-beijing'), and clarifies that region defaults to 'ap-shanghai' and must match the deployment region.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds a database instance by its internal Vip (proxy IP), and distinguishes it from sibling tools like execute_select or login_instance by specifying it returns InstanceId for further use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a typical workflow: read JDBC URL, call this tool to get InstanceId, then login_instance. It also specifies that region must match the cluster region, guiding correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed schema of a table: columns and DDL (CREATE TABLE statement).
Args: instance_id: Instance ID (must be logged in) db_name: Database name table_name: Table name
Returns: Column details and CREATE TABLE DDL.
| Name | Required | Description | Default |
|---|---|---|---|
| db_name | Yes | ||
| table_name | Yes | ||
| instance_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral transparency. It discloses the output (columns and DDL) and implies a read operation. It does not mention side effects, permissions, or performance, but for a read-only schema tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three sentences for purpose, three lines for arguments, one line for returns. It is front-loaded with the core purpose and contains no superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (so return values are defined there), the description adequately covers the tool's purpose and parameter requirements. It could benefit from noting common prerequisites (e.g., prior login) but overall is sufficiently complete for a straightforward schema retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds minimal value: for instance_id, it adds '(must be logged in)'; for db_name and table_name, it merely restates the schema titles ('Database name', 'Table name'). Only one parameter gains useful semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 detailed schema of a table: columns and DDL (CREATE TABLE statement).' It uses a specific verb and resource, and distinguishes from sibling tools like list_tables (which lists table names only) and list_databases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by noting 'instance_id (must be logged in)', which hints at a prerequisite. However, it does not explicitly state when to use this tool over siblings or provide exclusion criteria. The purpose is clear enough for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all currently active (logged-in) database instance sessions. Useful to check which instances are ready for querying.
Returns: List of active instance IDs and their session status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It confirms the tool is read-only (listing sessions) and describes the return format, but does not disclose authentication requirements, side effects, or idempotency. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is three sentences with zero waste. Action verb 'List' is front-loaded, and return format is briefly noted. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, a clear purpose, and an output schema (implied), the description is complete for a simple listing tool. It aligns well with sibling tools in a database management context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% (vacuously). Per guidelines, baseline is 4. Description does not need to add parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'List all currently active (logged-in) database instance sessions' with a specific verb and resource. It distinguishes from siblings like 'login_instance' and 'execute_select' by clarifying its role in checking session readiness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description states 'Useful to check which instances are ready for querying,' giving clear context for when to use the tool. However, it does not explicitly exclude alternatives or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all databases accessible by the current logged-in account on the specified instance.
Args: instance_id: Instance ID (must be logged in)
Returns: List of database names.
| Name | Required | Description | Default |
|---|---|---|---|
| instance_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains that the tool lists databases accessible by the current user, requires login, and returns a list of database names. This sufficiently discloses the behavior as a safe read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a clear first sentence stating the purpose, followed by structured Args/Returns sections. Every part adds value with no superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one required parameter and an output schema present. The description covers the action, scope, and required login. It might lack details on error handling (e.g., invalid instance_id), but overall it is adequate for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, but the description adds meaning by explaining that instance_id is an 'Instance ID (must be logged in).' This provides context beyond the schema's title and type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all databases' and specifies the scope 'accessible by the current logged-in account on the specified instance.' It uses a specific verb and resource, and distinguishes from siblings like list_tables which lists tables, not databases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by requiring a logged-in account and providing the instance_id parameter. While it doesn't explicitly state when not to use or list alternatives, the sibling tools are sufficiently different that no confusion arises.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tables in a database, optionally filtered by name pattern.
Args: instance_id: Instance ID (must be logged in) db_name: Database name search: Optional table name filter (fuzzy match)
Returns: Table list with row counts and sizes.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | ||
| db_name | Yes | ||
| instance_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must supply behavioral traits. It mentions 'fuzzy match' for search and returns row counts/sizes, but lacks details on auth requirements, rate limits, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with purpose, and uses a structured Args/Returns format. No unnecessary sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with output schema, the description covers main functionality and return structure. Missing details on pagination, error handling, and usage scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description compensates with brief explanations for each parameter (e.g., 'Instance ID (must be logged in)', 'Optional table name filter (fuzzy match)'). Adds meaning but lacks type/format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists tables in a database with optional name filtering. It distinguishes from sibling tools like list_databases and get_table_detail, but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like list_databases. The Args section mentions 'must be logged in' but that is a prerequisite, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Login to a database instance via Tencent Cloud DMC. Supports both TDSQL-C (CynosDB) and TDSQL (DCDB) instances. The session is cached - subsequent calls reuse the same token without re-login, unless the token expires.
Use find_instance_by_ip to discover the instance_id and db_type, then pass the db_type value from the search results here.
Args: instance_id: Instance ID, e.g. "cynosdbmysql-xxx" or "tdsqlshard-xxx" user: Database account name, e.g. "db_user" password: Database account password (plain text) db_type: Database type - "cynosdbmysql" (TDSQL-C) or "tdsql" (TDSQL) region_id: Region ID, default 4 (Shanghai)
Returns: Login status message.
| Name | Required | Description | Default |
|---|---|---|---|
| user | Yes | ||
| db_type | No | cynosdbmysql | |
| password | Yes | ||
| region_id | No | ||
| instance_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses session caching and token expiration. However, lacks details on error handling, permissions, or any destructive potential. The behavior is straightforward for a login tool, but more transparency could improve safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections and bullet-style arg list. Every sentence adds value: prerequisite, caching, param descriptions, return. Slightly verbose but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all essential aspects: prerequisite, caching, all parameters, return value. Output schema exists so return detail is sufficient. For a login tool, it is complete and actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description fully compensates. Each parameter is explained with examples, defaults, and context (e.g., instance_id format, db_type values, region default). Adds meaning beyond schema significantly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Login to a database instance via Tencent Cloud DMC' with specific verb and resource. Distinguishes from sibling tools by mentioning find_instance_by_ip as a prerequisite and specifying supported database types (TDSQL-C and TDSQL).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context: use after find_instance_by_ip to get instance_id and db_type. Mentions session caching and token reuse. Does not explicitly state when not to use, but the guidance is clear enough for correct tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set or update the Tencent Cloud console cookie. AI can obtain this from the browser via Chrome DevTools MCP: document.cookie Then pass the full cookie string here.
The mc_gtk (csrfCode) value is required for cluster search (DescribeClusters API). AI can extract it from the browser's performance API: performance.getEntriesByType('resource') .find(e => e.name.includes('csrfCode=')) ?.name.match(/csrfCode=(\d+)/)?.[1] If not provided, DMC login/SQL tools will still work (they don't require mc_gtk to be valid), but find_instance_by_ip will fail.
Args: cookie: Full cookie string from the Tencent Cloud console browser tab. mc_gtk: Optional csrfCode value from the browser. Required for cluster search.
| Name | Required | Description | Default |
|---|---|---|---|
| cookie | Yes | ||
| mc_gtk | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: the effect of missing/invalid mc_gtk on cluster search and the unaffected tools. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, but slightly verbose in extraction instructions. Could be more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, inputs, and behavioral context comprehensively. Lacks explicit info on return values or error handling, but output schema likely provides that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates fully: explains cookie as full cookie string and mc_gtk as optional csrfCode with extraction method, adding essential meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: setting or updating the Tencent Cloud console cookie. It distinguishes from sibling tools (database query/management tools) by being a setup tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit instructions on when to use and how to obtain cookie and mc_gtk from browser DevTools and performance API. Also clarifies that DMC/SQL tools work without mc_gtk but find_instance_by_ip fails.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: login, query, list databases, list tables, get table details, find instance by IP, list active sessions, and set cookie. There is no overlap or confusion between tools.
All tool names follow a consistent snake_case verb_noun pattern (e.g., execute_select, login_instance, list_databases). No mixing of conventions or ambiguous verbs.
8 tools is well-scoped for a database management server, covering authentication, instance discovery, schema exploration, querying, and session monitoring without being too few or too many.
The tool set covers the core read-only workflow (login, query, schema browsing, instance discovery) well. A minor gap is the absence of a logout or session close tool, but overall the surface is appropriate for the intended use.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
Remote MCP server for China brand visibility, destination demand, and KOL discovery workflows.
A paid remote MCP for AI SDK data query MCP, built to return verdicts, receipts, usage logs, and aud
Paid remote MCP for governed database query review, SQL simulation, approvals, and audits.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/yangfeng20/dmc-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
