An MCP server that provides JDBC-based database access to Adobe Commerce and other data sources, exposing tools to query tables, retrieve columns, and execute SQL queries.
This server provides three READ_ONLY data-access tools with adequate naming and descriptions, but has significant gaps in schema completeness, parameter documentation, and error handling guidance. The tool definitions follow basic patterns but lack production-grade rigor. All three tools are explicitly registered with schemas and descriptions visible in source, avoiding the 'inferred only' penalty. However, input parameters lack depth in documentation (e.g., no constraints, ranges, or format guidance), output schemas are not formally documented in the code, and error responses throw generic RuntimeExceptions without LLM-actionable recovery guidance. The CSV output format is mentioned in descriptions but not specified as a formal output schema. Tools operate at an acceptable level for a READ_ONLY data catalog but fall short of the 70+ bar for confident production recommendation.
Retrieves a list of fields, dimensions, or measures (as columns) for an object, entity or collection (table). Use the `adobe_commerce_get_tables` tool to get a list of available tables. The output of the tool will be returned in CSV format, with the first line containing column headers.
Retrieves a list of objects, entities, collections, etc. (as tables) available in the data source. Use the `adobe_commerce_get_columns` tool to list available columns on a table. Both `catalog` and `schema` are optional parameters. The output of the tool will be returned in CSV format, with the first line containing column headers.
Execute a SQL SELECT statement.
Output schema not formally documented. Tools describe CSV output in text but do not return structured McpSchema with typed fields. LLMs cannot infer result structure for downstream processing without formal schema. No mention of field names, data types, or pagination for large result sets.
Input parameters lack constraints and format guidance. The 'sql' parameter in adobe_commerce_run_query has a description mentioning SQL-92 dialect and valid clauses, but no regex pattern, length limits, or injection-prevention guidance. Parameters 'catalog', 'schema', 'table' lack examples of expected format (e.g., 'catalog name must be 1-100 alphanumeric characters').
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 35 | - | v1 |
Error handling is non-recoverable for LLMs. Tools throw RuntimeException with 'ERROR: ' prefix but provide no guidance on cause or next steps. Examples: invalid table name, connection failure, SQL syntax error, all return the same generic RuntimeException. No categorization (retryable vs user-fixable), no suggestions for recovery.
adobe_commerce_run_query description lacks WHEN/WHY guidance. Current text: 'Execute a SQL SELECT statement.' This is minimal and does not explain when to use this tool vs. get_tables or get_columns, what results to expect, or any limitations. A 50-char description fails the 10 - 1024 guideline spirit (too low on the useful spectrum). Missing: dependency hints, common use cases, result cardinality warnings.
No pagination parameters or result limits documented. Tools return CSV; descriptions state 'first line containing column headers' but do not specify: max rows returned, offset/limit support, total count field, or next_cursor for continuation. Large queries could return thousands of rows, exhausting LLM context. Baseline pattern requires pagination for list operations.
Parameter descriptions are minimal and lack actionable constraints. Examples: 'The catalog name' (9 chars, no enum/format guidance), 'The schema name' (14 chars), 'The table name' (13 chars). Baseline for param descriptions: 72 chars average. These descriptions do not help LLMs understand valid values, mutually exclusive params, or format constraints.