Loading ToolBench
Model Context Provider (MCP) server for data science services
This MCP server exhibits significant definition quality gaps across all five tools. While tool names follow verb_noun conventions, descriptions are generic or missing critical context. Input schemas are present but lack parameter descriptions entirely, a critical violation of pattern:tool-description. The server exposes an API access token as a bare parameter (fetch_strava_activities), violating pattern:secret-injection. No output schemas are documented. Error handling is minimal and non-actionable. The tools appear to be REST API wrappers rather than properly designed MCP tools. Most tools score in the 20-40 range.
Strava Activities Integration Endpoint - Fetches Strava athlete activities using provided access token and optional pagination parameters.
JSON-LD Context Endpoint - Serves the JSON-LD context document defining terms used in the MCP metadata, mapping them to schema.org and other vocabularies.
MCP Discovery Endpoint - Returns metadata about the MCP server including name, description, version, tags, contact, and content endpoint.
Model Metadata Endpoint - Returns metadata for a specific model identified by modelId.
Available Models Content Endpoint - Returns a list of available model contents with titles, descriptions, and tags.
No parameter descriptions in any tool. Every input parameter lacks a description explaining what it controls or what values are valid. This violates the critical rule that 100% of A+ tool params have descriptions. LLMs cannot infer meaning from parameter names alone, a 'modelId' or 'endpoint' parameter needs context.
Strava API access token exposed as a required parameter (accessToken in fetch_strava_activities). This is a critical security violation, credentials must never appear as tool parameters and will leak into agent logs and traces. Use server-side secret injection via environment variables instead.
No output schemas documented for any tool. LLMs need to know what fields to expect in responses so they can plan downstream tool calls and extract data. The source shows tools return JSON (e.g., list_available_models returns title/content/tags objects), but the MCP tool definition includes no outputSchema.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | <=2025-11-25 | v2 |
Tool descriptions are either missing or too generic. 'MCP Discovery Endpoint' and 'Available Models Content Endpoint' are technical names, not descriptions explaining when/why an LLM should call the tool. Descriptions should answer: What does it do? When should I call it instead of a similar tool? What does it return?
Error handling is non-actionable. In contextRoutes.ts, get_model_metadata returns {error: 'Model not found'} with no guidance on what to do next. Per pattern:recovery-guide, errors must tell the LLM what to try: 'Model not found. Try list_available_models() to see available models.'
The Strava tool uses HTTP POST but accepts pagination parameters (page, per_page). POST is unusual for read-only endpoints. More critically, no pagination limits are enforced, per_page defaults to 30 but has no maximum, allowing an LLM to request thousands of items and exhaust context.
No enum constraints on parameters that accept one of a known set of values. The Strava tool hardcodes endpoint URL with a default; if other endpoints are valid, they should be declared as an enum to prevent hallucinated values.
Tools lack idempotency or confirmation steps. fetch_strava_activities is read-only so safe, but get_model_metadata could be modified to write. No tools declare their mutability (readOnlyHint or destructiveHint annotations), and none ask for confirmation before executing.