Loading ToolBench
MCP server for SUZURI e-commerce platform integration, providing tools to access products, materials, users, and favorites with OAuth 2.0 authentication
suzuri-mcp demonstrates solid naming conventions and consistent schema usage across 20 tools. All tools follow verb_noun pattern (get_*, create_*, update_*, delete_, add_*). Parameter schemas are well-typed using Zod and include descriptions. However, descriptions are uniformly terse (under 50 chars), descriptions lack actionable context, and output schemas are not explicitly documented. Error handling exists but lacks recovery guidance. The server implements a clean architecture with helper functions for compact responses, reducing token bloat, but relies on infrastructure assumptions (authInfo propagation via context) that may not be guaranteed.
商品をお気に入り（ズッキュン）に追加します（要認証）
画像から素材を作成します（要認証）
テキストから素材を作成します（要認証）
素材を削除します（要認証）
SUZURIで取り扱っているアイテム（商品カテゴリ）一覧を取得します（要認証）
素材の詳細情報を取得します（imageUrl, description含む）（要認証）
SUZURIの素材一覧を取得します（軽量版: id, titleのみ）（要認証）
Terse, non-actionable descriptions (< 50 chars each) lack context for LLM tool selection. E.g. 'SUZURIで取り扱っているアイテム（商品カテゴリ）一覧を取得します（要認証）' states WHAT but not WHEN to use or dependencies on other tools. Baseline expectation: 50 - 200 chars with clear disambiguation.
Output schemas are not explicitly documented in code. Tools return JSON via createJsonResponse but LLMs cannot see what fields to expect in results. E.g., get_products returns { items: [...] } but no schema documentation shows the structure of each product object (is price a number? string? currency unit?). This forces LLMs to guess field types and risks malformed chaining calls.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 73 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
認証ユーザーの情報を取得します（要認証）
認証ユーザーの素材一覧を取得します（軽量版: id, titleのみ）（要認証）
認証ユーザーの商品一覧を取得します（軽量版: id, title, priceのみ）（要認証）
SUZURIのセール商品一覧を取得します（軽量版: id, title, priceのみ）（要認証）
SUZURIの商品詳細を取得します（要認証）
商品のお気に入り（ズッキュン）一覧を取得します（軽量版）（要認証）
商品の画像URL一覧を取得します（要認証）
SUZURIの商品一覧を取得します（軽量版: id, title, priceのみ）（要認証）
SUZURIのユーザー詳細を取得します（要認証）
ユーザーのお気に入り（ズッキュン）一覧を取得します（軽量版）（要認証）
SUZURIのユーザー一覧を取得します（軽量版: id, name, displayNameのみ）（要認証）
SUZURIの商品を検索します（軽量版: id, title, priceのみ）（要認証）
素材を更新します（要認証）
Error handling is minimal. AUTH_ERROR_RESPONSE is a static string; API or network failures in SuzuriClient calls have no recovery guidance. When an LLM encounters 'error: Network timeout', it has no guidance on whether to retry, call a different tool, or ask the user. Baseline: errors should categorize as retryable, user-fixable, or fatal.
No deletion confirmation or dry-run for destructive delete_material. Agents may hallucinate and call delete without understanding consequences. Pattern expectation: irreversible operations should require explicit confirmation or support a dry-run step.
Parameter descriptions lack format constraints. E.g., 'texture' is documented as 'Base64エンコードされた画像データ' but no note on size limits, mime types, or dimensions. 'count' in add_favorite has no range (1-100?). 'title' in create_material has no length limit. Baseline: constrained inputs should declare format, range, and examples in the description.
get_me has minimal description ('認証ユーザーの情報を取得します（要認証）') and empty input schema {}. While this is technically valid, LLMs need context on what 'my information' includes (profile, settings, permissions?) and whether it's a prerequisite for get_my_products. Baseline: even zero-parameter tools should have 50 - 100 char descriptions explaining the return structure.