Loading ToolBench
MCP server for Dango data platform. Exposes Dango operations as typed tools for LLM agents to read catalog information, inspect schemas and lineage, query data, and trigger Dango operations.
The Dango MCP server exposes 4 read-only data warehouse tools via fastmcp/STDIO. Tool naming follows verb_noun conventions (list_, get_) and descriptions are present with reasonable length (100-200 chars). However, parameter schemas show significant gaps: nullable types are declared but lack enums for constrained inputs, descriptions for parameters are embedded in tool descriptions rather than per-parameter, and output schemas are absent. Error handling guidance is missing, no recovery hints, categorization, or actionable error responses. The server is early-stage (v1.0.8) and focused on data discovery rather than complex operations, which partially mitigates some gaps. STDIO transport is a hard ceiling on protocol readiness.
Get the data catalog: all tables grouped by schema with row counts. Args: source_filter: Optional source name to filter tables (e.g. "my_stripe_source") Returns dict with tables_by_schema (schema -> list of table names) and total count.
Get dbt lineage from the manifest. Shows source -> staging -> intermediate -> mart flow. Args: model_name: Optional model to get lineage for. If omitted returns full DAG summary. Returns dict with nodes and edges representing the data lineage graph.
Get the schema (columns, types, descriptions) for a table in the warehouse. Args: table_name: Table name (e.g. "stg_stripe__customers") schema: Schema name (e.g. "staging", "raw_stripe"). Auto-detected if omitted. Returns dict with: table_name, schema, columns (list of {name, type}).
List all configured data sources with their sync status and row counts. Returns a list of dicts with: name, type, enabled, last_sync, rows, status.
Output schemas not documented. Tool descriptions mention return structure in prose (e.g., 'Returns dict with tables_by_schema') but no JSON Schema is provided. LLMs cannot reliably parse unstructured prose and may hallucinate field names.
Parameter descriptions embedded in tool descriptions, not in input schema. For example, get_table_schema lists 'table_name' and 'schema' parameters with descriptions in the tool docstring, not as individual parameter descriptions. Schema property has 'description' field but it repeats the tool-level description.
No enum constraints for parameters that accept a fixed set of values. For example, 'source_filter' in get_catalog accepts 'Optional source name' but has no list of valid source names. get_lineage's 'model_name' is unconstrained. Enums would help LLMs avoid invalid values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
No error handling guidance. Tools have risk=READ_ONLY but provide no recovery instructions. What happens if a table_name does not exist? If the dbt manifest is missing? If the warehouse is offline? LLMs need actionable error messages to proceed.
No pagination support. list_sources and get_catalog return potentially large lists (all tables, all sources) with no limit, offset, or cursor. Large result sets will blow the context window and degrade LLM reasoning.
Parameter descriptions lack format guidance. For example, 'schema' in get_table_schema says '(e.g., "staging", "raw_stripe")' but no pattern, length limit, or validation rule is stated. If 'schema' is auto-detected, the description should explain when detection works and when manual specification is required.