MCP Server for BlazeMeter API Monitoring (Runscope) that provides AI assistants with programmatic access to BlazeMeter's API Monitoring platform via the BlazeMeter API test APIs.
Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This MCP server exhibits severe definition quality gaps across all dimensions. While 27 tools are registered, the codebase provided shows NO visible tool definitions, parameter schemas, or descriptions in the source excerpt. Tool names follow a acceptable verb_resource pattern (e.g., list, read, create, delete, update), but without access to the actual schema definitions in the tool registration code, all schema and description scoring must be conservative. The server relies on fastmcp framework for tool registration, but the critical implementation details (tool descriptions, input parameters, output schemas) are not visible in the provided source. Based on the Makefile, pyproject.toml, and main.py, the server has infrastructure (tests, linting, logging) but the actual tool definitions are opaque. Conservative scoring applies: if schemas and descriptions are not visible, they score 0.
No tool descriptions visible in provided source. Baseline rubric requires descriptions of 10-1024 characters for every tool. Without visible descriptions, LLMs cannot determine when or why to select a tool, violating pattern:tool-description.
Provide full tool registration code showing @fastmcp.tool decorators or explicit tool definitions with descriptions, input schemas, and output type hints. Example: '@tool(description="List all BlazeMeter API tests. Returns paginated results with test_id, name, and created_date. Call this to discover available tests before operating on them.") def list_tests(limit: int = 20, offset: int = 0) -> dict'.
Each description must state: WHAT the tool does, WHEN to use it instead of similar tools, WHAT it returns. Example: 'blazemeter_apitest_test_list: List all API tests in your BlazeMeter workspace. Returns test summaries with IDs and names. Call this to discover tests before reading details or running them.'
Define input parameter schemas with JSON Schema types, descriptions, enums, and ranges. Example for list tools: 'limit (integer, 1-100, default 20): Max results per page. offset (integer, ≥0, default 0): Pagination offset.'
Document output schemas for all tools, including required chaining IDs. Example: 'blazemeter_apitest_test_list returns [{test_id: string, name: string, created_date: ISO8601, status: enum}]. Each item includes test_id for use in read/update/delete operations.'
Add recovery guidance to error responses for all tools. Example: 'If a resource is not found, return a helpful message like: "Team 'prod-team' not found. Available teams: staging-team, dev-team, qa-team. Did you mean one of these?"'
Implement confirmation or dry-run pattern for destructive operations (delete tools). Example: Add optional 'dry_run: bool' parameter or require a 'confirm: str = "DELETE"' parameter matching the resource name to prevent accidental cascading deletes.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
No input parameter schemas visible in provided source. JSON Schema definitions with types and descriptions are not evident in the code excerpt, preventing validation of parameter constraints, enums, ranges, and descriptions.
No output schemas documented in visible source. Baseline: 100% of A+ tools have documented return types. LLMs need to know what fields to expect to plan downstream tool calls. Cannot verify that responses include necessary chaining IDs (e.g., if list returns items, do they include IDs required by read/update/delete operations?).
No error handling guidance visible. Rubric requires error responses to tell the LLM what to do next (e.g., 'Try search_*() first'). No evidence of error categorization (retryable, user-fixable, fatal) or actionable recovery messages per pattern:recovery-guide.
Destructive tools (delete operations) show no confirmation or dry-run pattern. Baseline requires irreversible operations to support a confirmation step to prevent catastrophic errors. Tools like blazemeter_apitest_test_delete, blazemeter_apitest_schedule_delete, blazemeter_apitest_step_delete, blazemeter_apitest_environment_delete have DESTRUCTIVE risk but no visible safeguard.
No tool annotations visible. Baseline: tool annotations (readOnlyHint, destructiveHint, idempotentHint) are a current pattern in the 2026-07-28 MCP spec. Tools are marked with Risk levels (READ_ONLY, WRITE, DESTRUCTIVE) in the evaluation metadata but no evidence of these being expressed in the actual MCP tool definitions.
Add tool annotations (destructiveHint, readOnlyHint, idempotentHint) to tool definitions. In fastmcp, this may require extending the tool decorator or using custom metadata fields. Example: '@tool(destructiveHint=true, description="...") def delete_test(test_id: str):'.
Validate that list tools accept pagination parameters (limit, offset or cursor) and return a total_count or next_cursor. Baseline: lists must support pagination to prevent context window exhaustion.
Ensure create/update operations return the modified resource with all fields needed downstream (e.g., test_id, created_date, status). This prevents requiring a follow-up read call.
Add parameter descriptions to all input schemas. Example: 'test_id (string, required): Unique identifier of the test. Can be found via blazemeter_apitest_test_list. Format: 12-digit hex string.'
Audit API responses: strip internal pagination fields, timestamps, and metadata not relevant to chat. Return only essential fields. Example: if the BlazeMeter API returns 50 fields, return only test_id, name, status, created_date, and one URL for navigation.