Official Coach Simple Public API MCP server — exposes every Coach Simple Public API endpoint as a typed MCP tool. The tool manifest is generated live from the API registry; identity and visibility resolve server-side from your API key.
Single tool 'dynamic_tools_from_registry' has critical definition gaps. Tool name lacks action verb (should be 'call_api' or 'invoke_endpoint'). Description is generic and does not explain WHEN to use this tool or what it returns. Input schema has only two top-level properties (pathParams, queryOrBodyParams) with minimal descriptions; no per-endpoint schemas are visible. The tool is a catch-all proxy that dynamically generates endpoints at runtime, tool definitions are inferred from API registry, not explicitly registered in code. Per HARD SCORING RULE: 'If you cannot see the actual tool definition in the source (only inferred): cap that tool's overall at 50.' Since all endpoint tools are generated dynamically and not statically defined, this server cannot demonstrate concrete tool quality. The single visible tool definition is underdescribed and lacks actionable guidance for LLM selection.
All tools are dynamically generated from the Coach Simple Public API registry at runtime. Tool names are derived from API endpoint paths and HTTP methods. Examples include: registry_list, system_whoami, get_portals, post_portals, get_portals_pid_users_uid_opportunities, etc.
Tool name 'dynamic_tools_from_registry' lacks action verb. Should start with verb (e.g., 'call_api', 'invoke_endpoint', 'execute_api_call') to signal intent to LLM. Current name is a noun phrase describing implementation, not user action.
Tool description is generic and does not explain WHEN to use this tool, what it returns, or how to structure requests. Description reads as implementation detail ('All tools are dynamically generated...') rather than user-facing guidance. LLM cannot determine when to select this tool vs. alternatives.
Input schema properties 'pathParams' and 'queryOrBodyParams' lack per-parameter type constraints and descriptions. Schema declares additionalProperties: true globally, which invites hallucinated parameters. No enum constraints, no format specifications, no validation rules visible.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 32 | 2026-07-28+ | v2 |
All endpoint tools are dynamically generated from API registry at runtime. Tool definitions are not statically visible in source code, they are inferred. Per HARD SCORING RULE, this caps tool quality at 50. Cannot verify concrete schemas, descriptions, or error handling for individual endpoints.
No output schema documented. LLM does not know what fields to expect from API responses, making downstream tool chaining and data extraction error-prone. Responses are raw API payloads without field documentation.