Loading ToolBench
MCP Server (Service C): The Toolbox - Hosts the FastMCP server with Streamable HTTP transport and exposes tools for task management, internet search, Discord moderation, file operations, and server reporting.
Project Aether's MCP server has 11 tools with basic structure but significant quality gaps. Most tools have parameter schemas and descriptions, but many descriptions are generic and lack clarity on when to use each tool vs. alternatives. Parameter descriptions are often one-liner statements without validation guidance, constraints, or recovery hints. No tool explicitly declares which are destructive or idempotent. Output schemas are not documented. Error handling is absent, no guidance on failures or recovery paths. Tool naming follows verb_noun convention (good), but composition issues exist: discord_mod, discord_roles, lock_channel, unlock_channel, set_slowmode, and purge_messages perform overlapping Discord moderation without clear disambiguation. file_ops combines read/write/delete/list in a single tool rather than separate verbs. The server uses HTTP transport (fastmcp framework), supports logging via structlog, and includes task cancellation, but lacks tool annotations that would help LLMs understand operation safety.
Moderate Discord messages and users
Manage Discord user roles
Perform file operations (read, write, delete, list)
Search the internet using DuckDuckGo
Lock a Discord channel (prevent messages)
Purge messages from a Discord channel
Create a daily server activity report in the database. Upserts the report for today's date — calling this multiple times on the same day updates the existing entry rather than creating duplicates.
Multiple tools combine multiple verbs into single CRUD or action tools (task_crud, file_ops, discord_mod, discord_roles) instead of separate verb_noun tools. This violates single-responsibility principle and forces LLMs to disambiguate internally.
Descriptions lack LLM-optimized guidance on WHEN to use a tool, what distinguishes it from similar tools, and what happens. Generic one-liners like 'Moderate Discord messages and users' or 'Perform file operations' do not help tool selection in multi-tool scenarios.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract context without knowing what fields to expect. E.g., does task_crud.read return {id, content, status, assignee_id, created_at}?
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 38 | - | v1 |
Set slowmode (rate limiting) on a Discord channel
Create, read, update, and delete tasks in the database
Unban a user from Discord
Unlock a Discord channel (allow messages)
Destructive or irreversible operations (purge_messages, delete via file_ops, ban via discord_mod) lack confirmation mechanisms, dry-run options, or explicit warnings. Agents should be prompted before executing destructive actions.
No error handling or recovery guidance. Tools do not document what errors can occur (user not found, permission denied, etc.), how to classify them (retryable? user-fixable? fatal?), or what the LLM should do next.
file_ops lacks security documentation: no mention of path traversal protections, symlink restrictions, allowed directories, or permission checks. LLMs could be tricked into reading /etc/passwd or writing arbitrary files.
Parameters with ambiguous or overloaded semantics: discord_roles has both role_id and role_name (unclear if mutually exclusive); discord_mod mixes mute/kick/ban/timeout/warn under a single action enum without grouping or dependencies.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) to help LLMs understand operation safety and retry semantics. Agents cannot determine which calls are safe to retry without explicit metadata.