Loading ToolBench
Predict subscription churn risk and generate targeted retention offers.
This MCP server has fundamental definition quality issues that prevent production use. The two tools (`predict` and `batch_predict`) are presented as Python SDK methods in client.py, not as registered MCP tools with proper schemas. While the source code shows well-structured Python implementations with clear logic, there is NO EVIDENCE of MCP tool registration, schemas, or any framework integrating these into an MCP server. The repo appears to be an SDK/library rather than a functioning MCP server. Descriptions exist but are minimal (9-14 words). Input parameters are documented in docstrings but NOT exposed via JSON Schema. No output schema documentation. No error handling patterns. No evidence of security controls. This falls far below production-grade MCP server standards.
Predict subscription churn risk for multiple subscribers in batch.
Predict subscription churn risk.
No MCP tool registration detected. Tools exist only as Python SDK methods in client.py with no evidence of MCP protocol integration, server initialization, or tool descriptor registration.
Input schemas are completely absent. Parameters documented only in Python docstrings, not in JSON Schema format required by MCP spec. No type information exposed to clients.
Output schema undocumented. While the Python code returns dicts with clear fields (churn_risk_score, churn_probability, risk_tier, churn_drivers, retention_offers), there is no JSON Schema definition of the response structure for MCP clients.
Descriptions are too short and lack actionable detail. 'Predict subscription churn risk.' (9 words) and 'Predict subscription churn risk for multiple subscribers in batch.' (10 words) do not explain WHEN to use, WHAT it returns, or how it differs from similar tools. Baseline: 194 chars average for A+ tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 26 | 2026-07-28+ | v2 |
Parameter descriptions in docstrings use prose format incompatible with structured MCP schema. No enum constraints exposed (e.g., plan_tier must be basic|standard|premium, not validated by schema). No numeric bounds (email_open_rate 0-1 is documented but not schema-constrained).
No error handling patterns visible. The Python code does not validate inputs (e.g., email_open_rate < 0 or > 1, failed_payments < 0). Invalid inputs will silently produce nonsense scores. No recovery guidance for LLMs.
batch_predict parameter 'subscribers' expects list[dict] but the structure of each dict is not formally defined in a schema. Documentation says 'each containing subscriber_id, subscriber, engagement, and billing data' but does not enforce or validate this structure.
No pagination support for batch_predict. The tool accepts a list but there is no limit enforcement, no cursor/offset mechanism, and no guidance on maximum list size. An agent passing 10,000 subscribers could exceed context/timeout limits.
Tool naming uses compound names. 'predict' and 'batch_predict' are acceptable, but batch_predict bundles iteration logic inside the tool. Better pattern: single 'predict' tool that accepts both single subscriber dict and array, with the tool choosing the path internally, OR expose a single 'analyze_churn_risk' verb that the LLM can understand independently.