Goal-oriented recommendation engine. Scenarios: 'personalized_4_plans' (returns 4 diverse plans — safe / aspirational / seasonal / conversion-tested), 'preset_for_brand', 'color_palette_for_theme', 'touch_target_for_devices', 'motion_density_for_audience', 'seasonal_for_calendar', 'diagnostics_first_check'. Use for proactive suggestions when merchant intent is unclear.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | ||
| scenario | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It only details the output shape for one scenario (personalized_4_plans) and leaves the other six scenarios unexplained. It does not state whether the operation is read-only, what the response looks like, or what the 'context' parameter does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but the extensive list of scenario names largely duplicates the schema enum without adding meaningful detail for most items. The opening definition and usage sentence are useful, but the list adds redundant length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain per-scenario behavior, the role of context, and return values. It fully explains only one of seven scenarios, leaving the tool under-specified for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain the parameters. It gives partial meaning for 'scenario' by listing enum values and detailing one, but the 'context' parameter is completely omitted, and most scenario names are just labels without semantic content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a 'goal-oriented recommendation engine' and lists concrete scenario names, one with a detailed example (personalized_4_plans returns 4 diverse plans). It distinguishes itself from siblings by framing the tool as proactive suggestion-generating, though it does not explicitly contrast with browse/diagnose/explain/plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit usage trigger: 'Use for proactive suggestions when merchant intent is unclear.' This is clear context for when to invoke the tool, but it lacks exclusions or explicit alternative tool guidance, so it does not reach a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: browse catalogs, diagnose issues, explain plans/settings, generate plans from intent, and provide recommendations. While plan and recommend both generate plans, their inputs and use cases are explicitly separated (direct intent vs. proactive scenarios), eliminating ambiguity.
All tool names are single imperative verbs (browse, diagnose, explain, plan, recommend), following a uniform and predictable naming pattern. There is no mixing of conventions or stylistic inconsistencies.
With 5 tools, the server is well-scoped for its purpose as a planning and recommendation engine. Each tool earns its place, covering discovery, diagnostics, explanation, and planning without unnecessary bloat.
The tool set references critical preview/execute operations (preview() and execute()) that are not exposed as tools, leaving a dead end where plans cannot be applied. Additionally, there is no way to fetch full details for a specific catalog item beyond the paged browse results, making the workflow incomplete.