This MCP server has critical definition quality gaps. The single tool 'benchmark_cohort' lacks a proper input schema with typed parameters and descriptions. The source code shows only a Python class method with inline type hints, not an explicit MCP tool registration with JSON Schema. The tool description is present but generic. There is no documentation of the output schema structure. No error handling, validation, or recovery guidance is evident. The implementation appears to be a stub returning hardcoded values, not a real benchmarking engine. This server would not function as a proper MCP tool without schema formalization.
Tools (1)
benchmark_cohortread onlysource verified25/100
Benchmarks mobile app cohort data against industry standards, calculating day 1 retention, day 30 ROAS, and industry benchmark percentile
Output schema not documented. Tool returns a dict with fields 'day_1_retention_pct', 'day_30_roas_pct', 'industry_benchmark_percentile' but no formal schema is provided to the LLM. LLM cannot verify output structure or plan downstream tool calls.
Parameter descriptions are incomplete. 'cohort_data' description lacks detail on expected record structure (what fields, formats, constraints). No guidance on valid ranges for CAC or D30_LTV. 'target_payback_days' description is minimal.
No error handling or recovery guidance. If cohort_data is malformed, empty, or contains invalid values, no error response or actionable message is defined. LLM has no guidance on what to do if the call fails.
Recommendations
Add explicit JSON Schema definition for the input. Define cohort_data as an array of objects with required fields: cohort (string, ISO 8601 date), cac (number, > 0), d30_ltv (number, >= 0). Example: {"type": "array", "items": {"type": "object", "properties": {"cohort": {"type": "string", "pattern": "^\d{4}-(0[1-9]|1[0-2])$", "description": "Cohort date in YYYY-MM format"}, "cac": {"type": "number", "minimum": 0.01, "description": "Customer Acquisition Cost in USD"}, "d30_ltv": {"type": "number", "minimum": 0, "description": "30-day Lifetime Value in USD"}}, "required": ["cohort", "cac", "d30_ltv"]}}
Define target_payback_days with constraints: {"type": "integer", "minimum": 1, "maximum": 730, "default": 180, "description": "Target payback period in days (1-730, commonly 90-365)"}}
Document output schema explicitly: {"day_1_retention_pct": {"type": "number", "minimum": 0, "maximum": 100, "description": "Day 1 retention rate as percentage"}, "day_30_roas_pct": {"type": "number", "minimum": 0, "maximum": 1000, "description": "Return on Ad Spend at day 30 as percentage (LTV/CAC * 100)"}, "industry_benchmark_percentile": {"type": "number", "minimum": 0, "maximum": 100, "description": "Percentile ranking vs. industry cohorts (0=worst, 100=best)"}}
Expand tool description to 100-200 characters explaining purpose, when to use, and what results mean. Example: 'Compares mobile app cohort ROAS and retention metrics against industry benchmarks. Use this after analyzing cohort performance to understand competitive positioning. Returns percentile ranking (0-100) and benchmark metrics for day 1 retention and day 30 ROAS.'
Tool implementation is a stub returning hardcoded values. The benchmark_cohort method does not process cohort_data or apply any logic, it always returns fixed percentiles. This is not a functional tool, just a mock.
Tool name 'benchmark_cohort' is acceptable but lacks clarity on what benchmarking means in this context. Description does not explain when to call this tool vs. alternatives, or what 'industry standards' or 'benchmark percentile' represent.
benchmark_cohort
Add error handling responses: (1) Missing required cohort fields → 'cohort_data must include: cohort (YYYY-MM), cac (>0), d30_ltv (>=0). Example: [{"cohort": "2026-07", "cac": 4.5, "d30_ltv": 3.1}]' (2) Empty cohort_data → 'At least one cohort record required' (3) Invalid target_payback_days → 'target_payback_days must be 1-730, got X'
Implement actual benchmarking logic: calculate day_1_retention from cohort progression, derive day_30_roas as (d30_ltv / cac * 100), compare against a database or hardcoded industry percentiles keyed by vertical/region/app_type. Replace hardcoded return values with computed results.
Add parameter relationship documentation: 'target_payback_days controls the benchmark dataset used for percentile comparison. Shorter payback periods (e.g. 30 days) favor high-ROAS, high-CAC strategies; longer periods (e.g. 365 days) favor sustainable retention-driven growth.'
Consider splitting into two tools if benchmarking and retention analysis are separate concerns: (1) benchmark_cohort_roas (ROAS metrics only) and (2) analyze_cohort_retention (retention curves over time) to match single-responsibility principle.
Add idempotentHint annotation to indicate the tool is read-only and can be called multiple times safely without side effects.