Loading ToolBench
通用 Redshift MCP Server（Streamable HTTP）+ 插件框架：三件套通用查询工具 + entry_points / 声明式 SQL 扩展
Three core tools with complete input schemas and detailed descriptions in Chinese. All tools follow verb_noun naming (list_, describe_, run_). Descriptions are comprehensive (200-400 chars) and explain WHAT, WHEN, and constraints. Parameters have types and descriptions. Output schemas are documented in description text. However, descriptions are in Chinese (non-standard for LLM optimization), and error handling guidance is minimal. No tool annotations (readOnlyHint, etc.) despite all being read-only. Schemas are present but not formally structured in JSON Schema format visible in code.
查指定表的列、类型与可选补充说明。 入参 ``table`` 必须是 schema-qualified 全名（``schema.table`` 或 ``database.schema.table``，如 ``analytics.events``）；未写库前缀时按配置默认 database 归一。必须先在 ``list_tables`` 返回的白名单中出现，否则拒绝。 列信息从 Redshift ``SVV_COLUMNS`` 实时拉取，并叠加 config 里同名列 的 ``description`` / ``example_values`` 提示（如有配置）。 Returns: ``{name, description, columns: [{name, type, ordinal_position, description?, example_values?}], row_count_estimate?}``
列出本 server 配置中允许查询的全部 Redshift 表。 返回每张表的 schema-qualified 名字与可选中文描述。在调用 ``describe_table`` 或 ``run_sql`` 之前应先调本工具发现可用表 —— 白名单不在结果里的表无法访问。 Returns: ``[{"name": "schema.table", "description": str | None}, ...]``； 若白名单为空则返回 ``[]``，此时 ``describe_table`` / ``run_sql`` 全部会拒绝。
执行一条参数化 SELECT 查询（仅限只读、单条语句）。 ``sql`` 必须是单条 SELECT（无 DML/DDL/多语句）；用 ``%(name)s`` 命名占位符 传参（psycopg 风格）。``params`` 是 JSON 对象，键与占位符名对应。 表白名单校验：SQL 引用的表必须全部在 ``list_tables`` 返回的白名单中， 否则拒绝（挡住跨库越权读取）。 行截断：结果超过 ``config.query.max_rows`` 时自动截断，返回 ``truncated=true`` 标记（客户端据此判断是否需要加 LIMIT / 调整查询）。 审计：完整 SQL 模板 + bind 参数经独立的 SQL 审计 logger 输出（默认 ``sql_audit_level=WARNING`` 时被过滤，切 INFO 才落盘）。 Returns: ``{count, truncated, columns, rows}``
Descriptions in Chinese reduce LLM comprehension. Standard practice is English descriptions for maximum compatibility with multilingual LLM models.
No tool annotations despite all three tools being read-only. Missing readOnlyHint would help agents understand safety profile and enable optimizations.
Error handling descriptions lack recovery guidance. E.g., run_sql mentions 'truncated=true' but does not guide LLM on what to do next (add LIMIT, adjust query, etc.).
Output schemas documented only in description text, not as formal JSON Schema. Clients cannot programmatically parse expected response structure.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | <=2025-11-25 | v2 |
run_sql accepts 'params' as nullable object but does not document format constraints (e.g., must match %(name)s placeholders). Undocumented dependency between sql and params.