FreeOnePlus commented on issue #175: URL: https://github.com/apache/doris-mcp-server/issues/175#issuecomment-5165041280
Thanks for clarifying the product position of `new-mcp-server`. I agree that an analytics-oriented server and a general-purpose Apache Doris capability gateway are different products. However, several statements about the “current old MCP server” do not describe the current 1.0.0 implementation on `master`. To keep the discussion technically accurate, I would like to clarify the product boundary and the implementation evidence. ## 1. The MCP Server should not become a semantic modeling platform The core responsibility of an MCP Server is to expose existing software capabilities to MCP Hosts through stable, discoverable, authorized, auditable, and executable contracts. For Apache Doris MCP Server, this means exposing Doris capabilities such as: - catalog and metadata inspection; - governed query execution; - cluster and workload state; - ingestion and materialized-view status; - search; - governance and lineage; - lakehouse metadata; - optional consumption of external semantic systems. It should not own the complete lifecycle of a semantic product, including: - semantic-model authoring; - model editing; - staging and publishing workflows; - review and approval; - Git synchronization; - Web-based model management; - metric-governance workflows. Those are responsibilities of a semantic control plane, analytics server, or Doris-oriented Data Agent. The current 1.0 architecture already follows this boundary: - Ossie owns semantic definitions; - MetricFlow owns metric semantics and compilation; - Doris MCP Server consumes those systems through `doris_semantic`; - every model-specific request requires an explicit `model_ref`; - the Server does not guess or author a model; - compiled SQL returns to the governed Doris Query runtime. This is documented in the current [[tool-domain contract](https://github.com/apache/doris-mcp-server/blob/master/docs/capabilities/tool-domains.md)](https://github.com/apache/doris-mcp-server/blob/master/docs/capabilities/tool-domains.md) and [[MetricFlow integration contract](https://github.com/apache/doris-mcp-server/blob/master/docs/integrations/metricflow.md)](https://github.com/apache/doris-mcp-server/blob/master/docs/integrations/metricflow.md). Therefore, improving the MetricFlow integration is valuable, but turning the MCP runtime into the model-authoring and publishing platform would cross the intended product boundary. ## 2. The Host does not receive fifty-five tools by default The current default exposure mode is hierarchical. The Host initially registers exactly eight stable top-level domains, not fifty-five flat tools: - `doris_catalog` - `doris_query` - `doris_cluster` - `doris_pipeline` - `doris_search` - `doris_governance` - `doris_lakehouse` - `doris_semantic` A child manifest is disclosed only after the Host selects one domain and calls it with `{}`. The exact child name and compact schema are then used for execution. The regression contract explicitly verifies that: - exactly eight top-level tools are registered; - child names are not repeated in top-level descriptions; - the top-level `tools/list` stays below a hard 24 KiB budget; - a domain manifest is bounded; - the registered list remains stable when the conversation switches domains. See [[test_domain_manifest.py](https://github.com/apache/doris-mcp-server/blob/b7b66f5f80becdab7080d8b92a3bce17032752ca/test/tools/test_domain_manifest.py#L134-L159)](https://github.com/apache/doris-mcp-server/blob/b7b66f5f80becdab7080d8b92a3bce17032752ca/test/tools/test_[domain_manifest.py](https://github.com/apache/doris-mcp-server/blob/b7b66f5f80becdab7080d8b92a3bce17032752ca/doris_mcp_server/tools/domain_manifest.py#L52-L93)#L134-L159) and [domain_manifest.py](https://github.com/apache/doris-mcp-server/blob/b7b66f5f80becdab7080d8b92a3bce17032752ca/doris_mcp_server/tools/domain_manifest.py#L52-L93). This is progressive disclosure, not a fifty-five-tool flat registration. We have also validated the design through a real Dify 1.16.1 Host. Before [[PR #199](https://github.com/apache/doris-mcp-server/pull/199)](https://github.com/apache/doris-mcp-server/pull/199), Dify speculatively expanded five unrelated domain manifests for one cluster-history question. After the fix, it expanded only `doris_cluster`: - before: 100,093 cumulative tokens; - after: 33,510 cumulative tokens; - reduction: approximately 66.5%. This does not mean that every child tool must exist forever. Redundant children should still be consolidated when evidence shows that they have no independent contract. However, the decision should be based on capability semantics, authorization boundaries, version compatibility, output normalization, and real Host behavior—not the raw number of internal child operations. ## 3. One `execute_query` tool is sufficient only for a limited local ChatBI scenario For a local `stdio` deployment with one developer, one trusted Doris account, and a basic ChatBI workflow, a single SQL tool may be sufficient. That is not sufficient for a general enterprise Doris gateway. Many Doris capabilities are not equivalent to arbitrary SQL execution: - FE query-profile APIs; - FE/BE monitoring endpoints; - runtime capability probes; - ADBC/Arrow Flight SQL; - native or companion lineage providers; - semantic compilation providers; - version-dependent system metadata; - sanitized external-catalog properties; - route-aware availability; - stable partial/degraded results. Even where the raw evidence can be queried through SQL, a dedicated structured capability can provide: - version-independent input and output contracts; - identifier validation; - parameter binding; - sensitive-field sanitization; - result bounds; - explicit availability; - stable error semantics; - exact authorization scopes. Reducing everything to `execute_query` does not remove complexity. It moves the complexity into the model and requires the model to guess Doris system tables, patch differences, permissions, output fields, and failure behavior. The purpose of an Agent harness is to make execution deterministic and governed, rather than requiring the model to reconstruct product-specific behavior from raw SQL on every call. For example, the three Lakehouse children operate at different object levels: - external catalog; - lakehouse table; - Variant column. They also have different schemas, permission evidence, version gates, sanitization rules, and result contracts. A generic SQL function could retrieve some raw information, but it would not provide the same stable MCP capability. ## 4. A CLI is complementary to MCP, not a replacement for it A CLI is appropriate for: - shell automation; - developer diagnostics; - bulk export; - file redirection; - offline processing; - human-operated workflows. MCP is appropriate for: - standard Host integration; - tool and schema discovery; - structured arguments; - authenticated identities; - exact operation authorization; - capability availability; - bounded structured results; - consistent error contracts; - audit and trace metadata. These interfaces can share the same Doris runtime, but they solve different interaction problems. Large results should not be pushed unbounded into a model context. The current MCP Query runtime therefore enforces row, byte, text, collection, depth, and timeout limits. Bulk export or file-oriented result processing can be implemented by a companion CLI or an explicit artifact service without redefining the MCP Server as a CLI. Multi-cluster support also does not require abandoning MCP. The current Server supports: - static tokens bound to different Doris database configurations; - isolated per-token connection pools; - Doris OAuth users with dedicated Doris connection pools; - request-specific route identities; - fail-closed routing with no fallback from a restricted token or user pool to a more privileged global account. See the [[connection-manager implementation](https://github.com/apache/doris-mcp-server/blob/b7b66f5f80becdab7080d8b92a3bce17032752ca/doris_mcp_server/utils/db.py#L534-L568)](https://github.com/apache/doris-mcp-server/blob/b7b66f5f80becdab7080d8b92a3bce17032752ca/doris_mcp_server/utils/db.py#L534-L568) and [[route-selection implementation](https://github.com/apache/doris-mcp-server/blob/b7b66f5f80becdab7080d8b92a3bce17032752ca/doris_mcp_server/utils/db.py#L2402-L2495)](https://github.com/apache/doris-mcp-server/blob/b7b66f5f80becdab7080d8b92a3bce17032752ca/doris_mcp_server/utils/db.py#L2402-L2495). In an enterprise environment, cluster selection should be bound to an authorized identity or route. It should not be an unrestricted string argument chosen by the model. ## 5. The current implementation does use Doris database identities The statement that the Server “does not use database accounts” is not accurate for the current 1.0 implementation. The effective Doris route is selected in this order: 1. the Doris OAuth user and that user’s dedicated pool; 2. the database configuration bound to a static token; 3. the global service account where that route is permitted. The MCP authorization layer does not replace Doris authorization. It determines whether an identity may discover or invoke an MCP capability. Doris RBAC remains the final authority for catalogs, databases, tables, columns, rows, system views, and query execution. The project includes a complete [[fine-grained Doris access-control guide](https://github.com/apache/doris-mcp-server/blob/master/docs/doris-fine-grained-access-control.md)](https://github.com/apache/doris-mcp-server/blob/master/docs/doris-fine-grained-access-control.md), including table privileges, column privileges, Row Policies, token-bound routes, and Doris OAuth identities. Child discovery and child execution are also independently checked with exact policies such as: ```text child:discover:doris_query:execute_query child:call:doris_query:execute_query ``` Unauthorized children are omitted from discovery and rejected again during execution. See [[domain_manifest.py](https://github.com/apache/doris-mcp-server/blob/b7b66f5f80becdab7080d8b92a3bce17032752ca/doris_mcp_server/tools/domain_manifest.py#L253-L398)](https://github.com/apache/doris-mcp-server/blob/b7b66f5f80becdab7080d8b92a3bce17032752ca/doris_mcp_server/tools/domain_manifest.py#L253-L398) and [[domain_dispatcher.py](https://github.com/apache/doris-mcp-server/blob/b7b66f5f80becdab7080d8b92a3bce17032752ca/doris_mcp_server/tools/domain_dispatcher.py#L438-L505)](https://github.com/apache/doris-mcp-server/blob/b7b66f5f80becdab7080d8b92a3bce17032752ca/doris_mcp_server/tools/domain_dispatcher.py#L438-L505). ## 6. The current query boundary is not a naive keyword check The formal 1.0 Query runtime uses `ReadOnlySQLGuard`. It: - parses the request into executable statements; - requires exactly one statement; - permits only reviewed read-only operation types; - recursively validates the target of `EXPLAIN`; - rejects DDL, DML, stacked statements, executable comments, export clauses, locking reads, variable assignment, and side-effecting functions; - validates named parameters; - binds caller values through the driver; - applies result and timeout limits; - still relies on Doris RBAC as the final data-access authority. See [[query_runtime.py](https://github.com/apache/doris-mcp-server/blob/b7b66f5f80becdab7080d8b92a3bce17032752ca/doris_mcp_server/utils/query_runtime.py#L77-L180)](https://github.com/apache/doris-mcp-server/blob/b7b66f5f80becdab7080d8b92a3bce17032752ca/doris_mcp_server/utils/query_runtime.py#L77-L180). The regression suite explicitly distinguishes harmless text from executable operations. For example, these are accepted: ```sql SELECT 'DROP TABLE t' AS harmless /* DELETE FROM t */ SELECT 1 ``` while mutation, stacked SQL, locking reads, output export, and executable comments are rejected. See [[test_query_runtime.py](https://github.com/apache/doris-mcp-server/blob/b7b66f5f80becdab7080d8b92a3bce17032752ca/test/utils/test_query_runtime.py#L135-L171)](https://github.com/apache/doris-mcp-server/blob/b7b66f5f80becdab7080d8b92a3bce17032752ca/test/utils/test_query_runtime.py#L135-L171). Compatibility keyword policies may still exist as defense-in-depth, but they are not the authorization model and are not the formal Query runtime’s sole SQL-safety mechanism. ## 7. “Password-free mode” needs a precise definition Unauthenticated HTTP is allowed only on an explicit loopback bind for local development. An unauthenticated bind to `0.0.0.0`, a LAN address, or a public hostname fails before startup unless the operator deliberately enables the dangerous test-only override. See [[validate_http_bind_auth_policy](https://github.com/apache/doris-mcp-server/blob/b7b66f5f80becdab7080d8b92a3bce17032752ca/doris_mcp_server/utils/config.py#L342-L366)](https://github.com/apache/doris-mcp-server/blob/b7b66f5f80becdab7080d8b92a3bce17032752ca/doris_mcp_server/utils/config.py#L342-L366) and its [[regression tests](https://github.com/apache/doris-mcp-server/blob/b7b66f5f80becdab7080d8b92a3bce17032752ca/test/security/test_http_bind_auth_policy.py#L73-L105)](https://github.com/apache/doris-mcp-server/blob/b7b66f5f80becdab7080d8b92a3bce17032752ca/test/security/test_http_bind_auth_policy.py#L73-L105). Local `stdio` relies on the local process and environment boundary by design. If “password-free” instead means a Doris account configured without a database password, the Server currently does not universally forbid that configuration because local Doris development installations may permit it. Production deployments are expected to use least-privileged Doris identities and protected credentials. A stricter production-mode validation can be discussed separately, but it is different from claiming that the enterprise MCP HTTP endpoint is exposed without authentication. ## 8. Semantic model refresh is a valid integration concern, but not a reason to move model management into MCP Core The local Ossie provider currently loads a reviewed, revisioned model snapshot during Server initialization. It does not currently provide online hot reload. That limitation is real and should be documented accurately. However, the appropriate solution is a provider or semantic control-plane lifecycle: - model repository owns authoring and publishing; - each published model has an immutable revision; - the MCP consumer observes an approved revision; - refresh invalidates affected manifests and resources; - the MCP Server remains read-only. Similarly, the current MetricFlow contract deliberately defines a compile-only Sidecar boundary. The repository does not yet bundle a stock Doris MetricFlow/dbt adapter, so a reference provider and end-to-end example would improve usability. Those are valid integration improvements. They do not require the general Doris MCP runtime to become a Web-based semantic model editor or publishing system. ## Conclusion I believe the useful parts of both directions can coexist if the product boundaries remain explicit: - Apache Doris MCP Server remains the general, version-aware, provider-neutral capability gateway; - `doris_semantic` integrates approved semantic systems without owning model authoring; - a Doris analytics/Data Agent product may own semantic workflows and higher-level analysis orchestration; - a Doris CLI may provide shell, export, and file-oriented workflows; - all of them can reuse common Doris execution and security components. We are open to consolidating child capabilities when a concrete contract review shows that they are redundant. However, replacing the current governed surface with one unrestricted SQL tool or replacing MCP with a CLI would remove important enterprise properties rather than merely simplify the implementation. For further discussion, it would be more productive to evaluate specific child capabilities against measurable criteria—Host accuracy, context cost, authorization boundary, non-SQL evidence, version compatibility, and output normalization—instead of treating the number fifty-five as proof of unnecessary complexity. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
