A Spring Boot MCP server that exposes ecommerce catalog operations including product and commercial component (CC) details retrieval from both standard and Snowflake data sources
Server exposes 4 tools with basic schemas and descriptions, but significant quality gaps limit production readiness. All tools have descriptions (positive), but they are verbose and contain redundant alias information that clutters LLM reasoning. Parameter descriptions include validation rules (numeric format, enum constraints for storeId), which is good. However, no output schemas are documented, LLMs cannot predict response structure or plan downstream calls. Tool naming lacks clarity: getProductDetails vs getProductDetailsInSnowflake and getCCDetails vs getCCDetailsInSnowflake create confusion about which to use and what distinguishes them. No error handling guidance, no idempotency markers, no security annotations. Spring-AI framework used but tool registration appears to rely on method introspection (MethodToolCallbackProvider), making actual schema visibility limited in source.
Get the details of a Commercial Component (CC) using its unique identifier (ccId) and the store identifier (storeId). Common aliases: This method may also be referred to as grid, grids, or gridCore.
Retrieves the details of a Commercial Component (CC) in snowflake using its unique identifier (ccId) and the store identifier (storeId). Common aliases: This method may also be referred to as grid, grids, or gridCore.
Get the details of a product in snowflake using its unique product identifier (productId) and the store identifier (storeId). Also known as: This method may be referred to as product, product service, product core, product reader or reader.
Get the details of a product in snowflake using its unique product identifier (productId) and the store identifier (storeId). Common aliases: This method may be referred to as product, product service, product core, product reader or reader.
Duplicate tools with unclear distinction: getProductDetails vs getProductDetailsInSnowflake, getCCDetails vs getCCDetailsInSnowflake. LLMs cannot determine which to call without explicit guidance on when each applies.
No output schemas documented. LLMs cannot predict response structure, field names, or types. Impossible to plan multi-step workflows or extract required IDs for downstream calls.
Descriptions contain verbose alias lists ('Also known as', 'Common aliases') that waste tokens and clutter LLM reasoning. Replace with concise action statements (50-150 chars) and move aliases to parameter-level documentation if needed.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 29 | 2026-07-28+ | v2 |
No error handling guidance. If productId is invalid or storeId is unsupported, LLMs receive no recovery hints. Descriptions should state: 'Returns error if productId is non-numeric or storeId not in [10701, 10702].'
Tool registration via Spring-AI MethodToolCallbackProvider infers schemas from method signatures. Actual JSON Schema definitions not visible in source; cannot verify parameter types, required fields, or constraints are properly declared.