A collection of multiple MCP servers: FileMCP (file management), GoogleMCP (Gmail/Drive/Calendar), TimeMCP (timezone/time utilities), VoiceMCP (text-to-speech), and WebMCP (web search and scraping)
This collection of 15 tools shows inconsistent quality. While all tools have basic descriptions and input parameters visible in code, several critical issues reduce quality significantly: (1) Schema completeness varies, most tools show parameter type hints in Python signatures but lack formal JSON Schema documentation; (2) Descriptions are often generic and under-specified (e.g., 'List files in the given path up to specified depth' lacks context on when to use this vs alternatives, typical return size, or use cases); (3) No evidence of error handling guidance, tools like load_url, load_sitemap, and search offer no guidance on what errors are retryable or how to recover; (4) Parameters lack important constraints, voice tool accepts enum values but time/file tools have unvalidated string parameters; (5) STDIO transport is a hard ceiling of 50. The codebase appears functional and tools are reasonably named (verb-first: list_files, read_file, search, etc.), but production readiness is limited by transport choice and schema formality.
Configure the web client settings.
Get the current time.
Get file information.
Get file MIME type.
List files in the given path up to specified depth.
Load content from a sitemap.
Load content from URLs.
Read file content.
No formal JSON Schema documentation in source. Tool definitions visible in Python code use type hints, but no explicit JSON Schema registration artifacts (with 'type', 'properties', 'required', 'description' fields per parameter) are shown. This means tools exist but their schemas are not formally validated.
Descriptions lack actionable context. Examples: 'Get the current time' does not explain when an LLM should choose this over time_word_clock or time_convert. 'List files in the given path' omits typical depth limits, max result size, or common use cases. LLMs cannot distinguish similar tools without clearer differentiation.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Search using the configured search engine.
Search files by name pattern.
Convert time between different timezones.
List all available timezones.
Validate if a given timezone is valid.
Get the word clock representation of time.
Generate speech from the provided text and play it.
No error handling or recovery guidance in any tool description. Tools like load_url, load_sitemap, and search lack statements about what errors can occur, whether they're retryable, or what the LLM should do next. A network timeout, 404, or malformed URL produces no guidance.
String parameters lack constraints and validation. Examples: timezone (time_convert, get_current_time) accepts any string with no format validation or list of valid timezones documented in the description. path (file_server tools) has no documented bounds or allowed patterns. This invites hallucinated values from LLMs.
Output schemas not documented. Tool descriptions do not specify what fields or structure the response contains. For example, list_files returns 'List of file paths' but does not say whether it includes file sizes, timestamps, or permissions. LLMs cannot plan downstream calls without knowing response structure.
STDIO transport only. This is a hard blocker for remote/hosted clients. Clients cannot connect to a STDIO server remotely, only local processes via stdin/stdout. This severely limits integration scenarios.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible in source. This prevents clients from understanding tool safety and idempotency, critical for agents deciding whether to retry or parallelize calls. All tools are marked READ_ONLY in the assessment, but no annotations in code.
Multiple time tools with overlapping names and unclear distinction. get_current_time, time_word_clock, and time_convert all take timezone parameters; LLMs may conflate them. Descriptions do not explain: 'Choose get_current_time for ISO timestamps, time_word_clock for natural-language descriptions, time_convert for multi-timezone scenarios.'