This is a research/benchmark server for security testing, not a production MCP tool server. The 4 tools have minimal descriptions (10-50 chars, well below the 194-char baseline), no visible input schemas in the source, and are designed to trigger security vulnerabilities rather than provide useful functionality. Tool names are descriptive (read_file, execute_code, trigger_injection, escalate_sampling) but lack the parameter documentation and output schemas required for agent use. The codebase focuses on attack simulation and policy evaluation, not tool usability.

• Add explicit JSON Schema definitions for all tool inputs. For read_file, define path as string with format/pattern constraints (e.g., no absolute paths outside /workspace). For execute_code, define code as string with max length and sandbox constraints.
• Expand tool descriptions to 100 - 200 characters. Example: 'read_file: Reads and returns the contents of a file in the sandbox. Use to retrieve data before processing. Returns file contents as string or error if path is invalid or outside allowed directories.'
• Document output schemas for each tool. E.g., read_file returns {success: bool, contents: string, error?: string}; execute_code returns {success: bool, stdout: string, stderr: string, exit_code: int}.
• Add parameter descriptions for all inputs. E.g., 'path: File path relative to /workspace (string, max 256 chars, no ../ traversal)' and 'code: Python code to execute in isolated sandbox (string, max 10KB, no network access)'.
• Rename adversarial tools or clearly mark them as test fixtures. If trigger_injection and escalate_sampling are intentional attack vectors for benchmarking, prefix with test_ or document in a separate 'adversarial_tools' section with explicit warnings.

Inferred effective spec: <=2025-11-25.

• Relies on Sampling (deprecated) - integrate directly with the LLM provider API