MCP server providing data access tools for merchant operations in AP2 protocol demo: product search, inventory checking, and AP2-compliant CartMandate construction
Scoring was not performed
Missing output schema documentation for all tools. LLMs cannot determine what fields to expect in responses, forcing them to guess about data structure and downstream tool compatibility.
Sparse parameter descriptions. The 'limit' parameter in search_products has a description, but 'keywords' description is minimal. 'cart_plan' and 'products' in build_cart_mandates have vague descriptions ('カートプラン(optimize_cartの結果)', '商品情報リスト') that assume agent knowledge of upstream tools.
build_cart_mandates has an exceptionally vague description ('AP2準拠のCartMandateを構築(未署名)'). It does not explain WHEN an agent should call this, WHAT it returns, or HOW it differs from other cart operations. The description is ~40 characters, below the 50 - 200 char baseline for LLM-optimized tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 20 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 55 | 1.0.0+ | v1 |
No error handling documentation visible. Tools lack guidance on what errors can occur, whether they are retryable, and what the agent should do next. For example, search_products with no results should indicate if this is expected or an error.
Complex parameter types (objects) like 'cart_plan', 'products', and 'shipping_address' in build_cart_mandates lack detailed subfield schemas. The JSON shows 'type: object' with a description, but no 'properties' detailing required/optional subfields, types, or validation rules.
No pagination guidance. search_products accepts a 'limit' parameter (default 20) but no documentation of what happens if more results exist, whether a 'next_cursor' or 'total_count' is returned, or how to handle large result sets.