SkillFence is a security proxy, not a primary MCP server. The 4 tools are defined in a fake test server (fake_server.py) for demonstration purposes. Tool definitions are minimal: descriptions are present but generic (10-30 chars), parameter descriptions are missing entirely, and no output schemas are documented. The tools lack the depth expected of production-grade definitions. read_file, run_command, and web_fetch have single-parameter schemas with no parameter descriptions. mystery_tool has an empty schema. No error handling guidance, no idempotent hints, no security annotations. The toolmap.py configuration system is well-designed for security policy, but the actual tool definitions it governs are skeletal.

• Add parameter descriptions to all tools. For read_file: 'path (string): Absolute or relative file path to read. Must be within allowed directories per manifest.' For run_command: 'command (string): Shell command to execute. Supports pipes, redirects, and environment variables. Will be executed with restricted permissions.'
• Document output schemas for each tool. E.g., read_file returns {"content": string, "size_bytes": number, "encoding": string}. run_command returns {"exit_code": number, "stdout": string, "stderr": string}.
• Expand tool descriptions to 50-150 chars. Include when to use, prerequisites, and side effects. E.g., 'Read a file's contents from disk. Use before modifying to check current state. Returns full file content; for large files, consider pagination or streaming.'
• Add destructiveHint and idempotentHint annotations to tool definitions. Mark run_command as destructive (irreversible). Mark read_file and web_fetch as idempotent (safe to retry).
• For run_command, implement a dry-run parameter or confirmation step. Document: 'Dangerous tool, executes arbitrary shell commands. Requires explicit authorization via SkillFence manifest. Consider dry-run mode to preview before execution.'