MCP server exposing PredictionService tools for promise-miss risk prediction, model status, metrics, and feature explanations. Supports stdio and Streamable HTTP transports.
Server exposes 8 tools with complete JSON schemas and descriptions, but quality is uneven. Tools 1, 4, 5, 8 share a massive 32-parameter schema (predict_promise_miss, explain_promise_miss, get_order_risk, recommend_policy_action) with many optional fields lacking clear constraints or enums. Descriptions are present but generic (50-100 chars), offering minimal guidance on WHEN to use each tool or HOW they differ. Tool 2 (get_model_status) and 3 (get_model_metrics) are minimal stubs with empty schemas. Tool 6 (list_available_actions) and 7 (calculate_action_value) are better-scoped but still lack output schema documentation. No error handling guidance, no recovery hints, no parameter validation rules stated in descriptions. Naming is verb-first (good), but parameter names like 'seller_late_rate_7d' lack units/format hints in descriptions.
Score one approved action under simulation assumptions (not causal).
Feature explanation via PredictionService.explain_one (same as REST /v1/explain).
Return model metadata and training metrics via PredictionService.model_info.
Return readiness / model_version via PredictionService.readiness.
Return promise-miss risk via PredictionService.
List approved actions and their simulation economics from versioned config.
Score promise-miss risk at carrier handoff via PredictionService.predict_one.
Massive shared parameter schema (32 params) across 4 prediction tools with no clear differentiation. LLM cannot easily distinguish when to call predict_promise_miss vs explain_promise_miss vs get_order_risk vs recommend_policy_action.
Optional parameters lack validation rules, enums, or format hints in descriptions. E.g., 'seller_late_rate_7d' has no stated range (0-1? 0-100?), 'payment_type_primary' has no enum, 'customer_state' accepts 'unknown' by default but no valid state list provided.
Tools 2 and 3 (get_model_status, get_model_metrics) have empty input schemas and minimal descriptions (40 chars). No output schema documented. LLM cannot plan downstream use of returned data.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
Predict then run deterministic NOC policy (same services as REST /v1/decision).
No error handling guidance. Descriptions do not explain what happens on invalid input, missing data, or service failures. No recovery hints (e.g., 'If prediction fails, try with fewer optional parameters').
Output schemas not documented for any tool. LLM cannot know what fields to expect from responses, forcing it to guess or make unsafe assumptions about downstream tool chaining.