Loading ToolBench
MCP server for Strava running activity analysis with semantic search, metrics computation, and visualization
Stride MCP exhibits significant quality gaps across naming, descriptions, and schema completeness. While tool names follow verb_noun conventions (e.g., 'lookup_specific_run_by_date', 'authenticate_with_strava'), descriptions are inconsistent in depth and parameter documentation is sparse. Most critically, parameter descriptions often contain directive language ('inferred from query') rather than explaining what the parameter controls, violating the principle that LLMs cannot infer meaning from names alone. Input schemas are present for all tools but lack proper typing on several parameters (some are loosely typed or rely on string coercion). Output schemas are not documented anywhere in the provided source code, leaving LLMs unable to predict what fields to expect or plan downstream operations. Error handling is minimal, no recovery guidance, no actionable error messages, and no distinction between retryable and fatal errors. The semantic search tool (lookup_by_retrieval_query) appears incomplete in the provided snippet (code ends mid-function), suggesting incomplete implementation.
Generates Strava OAuth authorization URL for user authentication with activity:read_all scope
Calculate average value of a running metric for activities within a date range
Calculate historical average for a specific running metric across all activities
Retrieve individual data points for a metric within a date range and generate a time-series visualization chart
Retrieve the last N running activities ordered by most recent first
Perform semantic search across running activities using natural language query with vector embeddings, returns best matching run with visualization
Parameter descriptions are directive ('inferred from query') rather than explanatory. LLMs cannot infer parameter meaning from names alone; descriptions must explain what each parameter controls and its expected format/constraints.
Output schemas are not documented in the source code. Tools return dicts (e.g., run_payload, chart_url) but LLMs have no way to know what fields exist, their types, or whether they can chain results to other tools.
No error handling or recovery guidance. Functions catch exceptions but return generic error strings ('The API call failed: {e}'). LLMs cannot determine if errors are retryable, user-fixable, or fatal.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 45 | - | v1 |
Search for running activities on a specific date (YYYY-MM-DD format) and return activity payload with chart visualization URL
Parameter 'metric_name' is documented with an inline enum list but not declared as a constrained enum in the schema. LLMs are told to 'map the user input' rather than being presented with formal enum constraints that are machine-parseable.
lookup_by_retrieval_query function is incomplete in the provided source (code ends at 'higest_score_point = s'). Cannot verify full schema, error handling, or output structure.
Parameter 'N' in look_up_last_N_runs lacks bounds documentation. No indication of minimum/maximum valid values. Unbounded integers allow LLMs to pass absurd values (N=1000000) that may break pagination or timeout.
Date parameters (start_date, end_date) are documented as 'inferred from query' but lack explicit format constraints (YYYY-MM-DD is mentioned in one tool but not all). Inconsistent documentation invites parsing errors.
lookup_specific_run_by_date can return either a structured response (run_payload + chart_url) or a generic 'runs' object depending on whether a payload exists. This conditional branching in output structure is not documented and forces LLMs to handle unpredictable response shapes.