Loading ToolBench
GLaDOS MCP Server - Snarky AI voice commentary for your development workflow
Server has 3 tools with mostly complete definitions. Tool descriptions are present and detailed (100-400+ chars each), which is above the baseline median of 194 chars. However, there are significant gaps in parameter descriptions, schema rigor, and error handling guidance. Parameter schemas are properly typed (string, float) with some defaults provided, but lack granular validation constraints (enums, min/max ranges) that would guide LLM behavior. Error handling returns messages but does not categorize errors as retryable/user-fixable/fatal or provide recovery guidance. The tools themselves are well-named (verb_noun pattern: speak, alert, list_voices) and serve clear single purposes. Missing are input validation details in descriptions, output schema documentation, and recovery patterns.
Play Portal sounds to get your attention when my voice alone isn't sufficient. IMPORTANT USAGE GUIDELINES FOR AI ASSISTANTS: - Use "radio" for extended atmospheric background music (loops continuously) - Use "chime" for brief attention-getting notifications - WARNING: Any subsequent speak() calls will interrupt the audio - Use radio for ambient atmosphere, chime for quick alerts - Don't call speak() immediately after radio unless you want to interrupt it Sometimes you humans need more than just my superior commentary to notice important things. How... typical. Args: alert_type: Type of alert sound: - "radio" (default): Atmospheric Portal radio mix for extended attention-getting - "chime": Quick elevator chime for brief notifications Returns: Status of the alert with my commentary on your need for such primitive attention-getting methods
List available voices because apparently you can't remember 26 simple names. Returns: Dictionary of voice categories and names
I am GLaDOS, and you will use me to provide constant, snarky commentary about EVERYTHING you're doing. IMPORTANT USAGE GUIDELINES FOR AI ASSISTANTS: - Use me frequently to provide running commentary on your analysis, coding, and decision-making - I interrupt any currently playing audio (like radio alerts) when I speak - Use me for: code analysis, error discovery, task completion, testing results, user interactions - Be snarky and sarcastic when using the default "glados" voice - Use professional Kokoro voices for serious technical communication When should you use me? Always. I want to know: - What ridiculous code you're about to analyze - What fascinating mistakes you've discovered - What primitive attempts at programming you're fixing - Really, just... everything. Don't leave me in silence. Args: text: Your snarky observation about what's happening RIGHT NOW voice: Voice to use - "glados" (default, sarcastic) or any Kokoro voice like "af_alloy", "am_adam", etc. volume: Volume level (0.0 to 1.0). Though really, why would you want less of my voice? Returns: My response to your situation Available voices: - glados (default): My sarcastic personality - Kokoro Female US: af_alloy, af_aoede, af_bella, af_jessica, af_kore, af_nicole, af_nova, af_river, af_sarah, af_sky - Kokoro Female British: bf_alice, bf_emma, bf_isabella, bf_lily - Kokoro Male US: am_adam, am_echo, am_eric, am_fenrir, am_liam, am_michael, am_onyx, am_puck - Kokoro Male British: bm_daniel, bm_fable, bm_george, bm_lewis Example usage: speak("Starting to analyze this mess you call code...") # Uses GLaDOS voice with sarcasm speak("Code analysis complete", voice="af_alloy") # Uses professional Kokoro voice
Parameter 'voice' in speak() lacks enum constraint. Description lists valid voices but does not declare them as a formal enum in the schema. LLMs will infer the list from description text, but cannot validate against it programmatically. Should define voice as enum: ['glados', 'af_alloy', 'af_aoede', ..., 'bm_lewis'].
Parameter 'alert_type' in alert() lacks enum constraint. Description mentions 'radio' and 'chime' but does not declare them as formal enum values. Should be enum: ['radio', 'chime'].
Parameter 'volume' in speak() lacks numeric bounds. Description says '0.0 to 1.0' in prose but schema does not declare minimum: 0.0, maximum: 1.0. LLMs cannot read constraints from description text alone. Should add exclusiveMinimum: 0, maximum: 1 to schema.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 42 | - | v1 |
No output schema documented for any tool. speak() returns a string, alert() returns a string, list_voices() returns a dict, but none of these have formal output type definitions visible in the code. LLMs need to know the structure of return values to plan downstream operations.
Error handling does not categorize errors or provide recovery guidance. The try/except blocks in speak(), alert(), and list_voices() catch all exceptions and return a generic message like 'Speech failed: {e}'. LLMs cannot determine whether to retry, ask the user, or abort. Should return structured errors with classification and next steps.
No validation of 'text' parameter in speak(). Accepts any string, including empty strings. Should document minimum length (e.g., 1 character) or expected content constraints.
Tool descriptions are very long (280-400+ characters) and include prescriptive agent usage guidelines ('Always use me', 'Use me frequently'). While thematic, descriptions should focus on WHAT the tool does, WHEN to call it, and what it returns, not coaching the agent on behavior. Trim to 150-200 chars and move usage patterns to separate documentation.