Loading ToolBench
A FastMCP server that proxies the Poe.com API with Claude compatibility, supporting multiple AI models (Claude, GPT, Gemini, Perplexity) with session management, file attachments, and Warp terminal integration
This server has fundamental issues in tool definition quality. While it declares 15 tools with names and descriptions, the definitions are inconsistent in rigor. Many tools lack proper parameter type documentation, descriptions are present but generic, and error handling patterns are absent. The server mixes multiple operational concerns (file operations, command execution, API proxying, Warp integration) without clear separation. Key baseline violations: 11 of 15 tools have descriptions under 100 chars (below the 194-char baseline); parameter descriptions are often minimal or missing type context; no documented output schemas for most tools; no error recovery guidance. The codebase shows effort (Pydantic models, loguru logging) but definitions do not meet production-tool standards.
Ask a question to a Poe bot.
Query POE with OpenAI-compatible parameters. This enhanced version supports both legacy and OpenAI clients, with advanced parameters like temperature, max_tokens, and stop sequences.
Ask a POE bot and automatically execute any detected actions in the response. This tool extends the basic ask_poe functionality by: 1. Getting the response from the POE model 2. Parsing the response for action directives (file creation, commands, etc.) 3. Executing those actions in the Warp terminal 4. Returning both the response and action results
Query POE with function calling support. This tool enables function calling with POE models that support it, allowing for tool use, parallel execution, and automatic result handling.
Query POE with full Warp context integration. This tool: 1. Extracts context from Warp (terminal, git, files, etc.) 2. Queries POE with rate limiting 3. Formats response for Warp display 4. Executes any detected actions
Multiple tools lack documented output schemas. Tools like ask_poe, ask_poe_v2, ask_poe_with_tools, list_available_models, stream_poe_to_warp, and health_check do not specify what fields LLM should expect in responses, blocking downstream tool composition and field extraction.
Tool names combine multiple concerns using 'and' pattern (ask_with_attachment, ask_with_attachment_and_actions, ask_poe_with_actions). Each should be split into separate single-responsibility tools. Composition is the agent's job, not the tool's.
Parameter descriptions are generic and lack operational context. Examples: 'The bot to ask' doesn't list valid bot names; 'Optional session ID' doesn't explain session lifecycle or when sessions are valid; 'Path to the file to attach' doesn't specify size limits or supported formats. This forces LLM to guess.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Ask a question to a Poe bot with a file attachment.
Ask a POE bot with file attachment and execute detected actions. This combines file sharing with automatic action execution, perfect for code analysis and modification, configuration file updates, and documentation generation and filing.
Clear a session's conversation history.
Create a file with specified content.
Execute a terminal command directly. This tool allows manual command execution without going through POE models. Useful for quick terminal operations or testing.
Execute a specific action in Warp terminal.
Get information about the server configuration.
Health check endpoint with metrics. Returns comprehensive health status and metrics.
List available Poe models and their capabilities.
Stream POE response directly to Warp with SSE.
Command execution tool (execute_command_tool) lacks input validation documentation. No mention of command injection prevention, allowlisting, or dangerous command blocking. Code shows basic blacklist (rm -rf, mkfs, dd) but it's not documented in the tool definition, and blacklist is insufficient for production use.
No error recovery guidance in any tool definition. Tools like clear_session, create_file_tool, execute_command_tool do not document what happens on failure (session not found, file exists, command timeout, permission denied) or what the LLM should do next. Agents cannot self-correct.
Destructive operations (clear_session, create_file_tool with overwrite=true, execute_command_tool, execute_warp_action) lack confirmation or dry-run patterns. Agents can permanently delete data or execute unintended commands without approval.
Warp integration tools (ask_poe_with_warp_context, stream_poe_to_warp, execute_warp_action) reference 'context' as an underspecified object. No schema for Warp context structure (what fields? required vs optional?). This blocks LLM understanding of what context can provide.
Enum constraints missing for parameterized choices. Examples: 'bot' parameter accepts 'o3, claude, gemini, perplexity, or gpt' but is declared as free-form string (not enum). 'action_type' in execute_warp_action has no constraint. This invites LLM hallucination of invalid values.
Session management semantics not documented. Multiple tools accept 'session_id' but descriptions don't explain: how are sessions created? What is their lifecycle? Can sessions span multiple bots? Do they persist across server restarts? This ambiguity prevents correct agent behavior.
Streaming tool (stream_poe_to_warp) doesn't document streaming protocol. No mention of chunking format, chunk boundary markers, or how LLM should consume streamed output. Streaming without protocol documentation is unusable.