This is a HexagonML MCP server that provides a Model context protocol interface for HexagonML ModelManager tools.
Single tool 'add_usecase' has a clear action verb and basic schema, but suffers from significant issues: (1) description is vague about what 'optional forecasting configuration' means and when to use this tool vs alternatives; (2) parameter descriptions lack detail about expected structure, constraints, and format; (3) no documented output schema, callers don't know what fields to expect; (4) parameter 'usecase_info' accepts an untyped dict with no enum or constraint guidance, inviting hallucinated keys; (5) no error handling guidance or recovery hints. The tool is minimally functional but fails to meet LLM-optimization standards (description should be 10-200 chars and explain WHAT, WHEN, and WHY; parameters need types and constraints). Tool name is acceptable (verb_noun pattern), but overall definition quality is weak.
Create a new usecase in the ModelManager service with optional forecasting configuration
Parameter 'usecase_info' is a free-form dict with no documented structure, keys, or constraints. LLMs will hallucinate required fields and produce invalid payloads. Should constrain with enum keys, nested type definitions, or an example schema.
No output schema documented. Callers cannot plan downstream operations or extract required fields. 'add_usecase' likely returns a usecase_id, metadata, or status, but this is not declared.
Tool description is 100 characters but lacks WHEN guidance. Does not distinguish this tool from potential alternatives (e.g., update_usecase, create_usecase_with_forecasting). LLMs cannot determine when to select it.
Parameter descriptions lack format/constraint guidance. 'Dict of usecase metadata including name, description, and configuration' doesn't explain required vs optional keys, data types for values, length limits, or enum constraints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 18 | - | v1 |
No error handling or recovery guidance. If API rejects the payload, LLM receives raw error. Should document what makes a valid usecase_info dict, and what to do if validation fails.
Tool name 'add_usecase' is slightly ambiguous, does it create a new usecase, or add an existing one to something? 'create_usecase' would be clearer and follows the verb_noun pattern more precisely.