TriageMCP is a malware analysis tool suite with 10 well-defined tools for PE binary inspection. However, it has significant definition quality gaps that prevent it from reaching production readiness. All 10 tools are explicitly registered via @mcp.tool() decorator with names, descriptions, and input schemas visible in triage.py. Descriptions range from 20-80 characters, meeting minimum bars but lacking LLM-optimization depth. Input schemas are consistently minimal, every tool accepts only file_path (string) with a description, and most lack constraint documentation (ranges, formats, validation rules). Output schemas are completely undocumented: tools return dicts (hashes, metadata, IAT/EAT, sections, etc.) but no schema definitions are provided, forcing LLMs to infer structure. Error handling is absent, tools will raise unhandled exceptions (FileNotFoundError, ValueError, pefile exceptions) with no recovery guidance or user-fixable hints. Tool naming follows a weak verb_noun pattern (get_*, run_*) which is acceptable but not optimized, names like 'run_detect-it-easy' and 'run_yara-scan' are domain-specific and clear enough. Composition is strong: each tool does one thing, chaining is possible (list_directory → analyze individual files), and operations are read-only with no irreversible side effects. Parameter descriptions exist but are sparse, list_directory mentions '~ for home directory' (good) but tools like get_hashes only say 'Full or relative path to the file to analyze' with no guidance on what happens if the file is not a PE, is corrupted, or does not exist. No parameters are typed as enums or constrained beyond the generic 'string' type, and no defaults are offered for optional parameters (all require file_path). This is a competent domain-specific tool set, but it lacks the polish and defensive detail required for robust agent integration.

• Document output schemas for all tools. For example, document get_hashes returns {md5: string, sha256: string, sha512: string}; get_pe_metadata returns {machine: string, number_of_sections: int, timestamp: string, ...}. This enables LLMs to plan subsequent tool calls and validate completeness.
• Add structured error handling with recovery hints. Wrap pefile.PE() and subprocess calls in try-except blocks. Return errors like: 'Invalid PE file: corrupted or non-PE binary. Verify with list_directory or try another file.' This guides LLM recovery.
• Expand parameter descriptions to 100+ characters explaining constraints, accepted formats, and failure modes. For file_path: 'Full or relative path to a PE binary file. Supports ~ for home directory. Must be a valid Windows PE (x86/x64 EXE or DLL). Returns error if file is corrupted, missing, or not a PE.'
• Rename tools with hyphens to use underscores: run_detect-it-easy → run_detect_it_easy, run_yara-scan → run_yara_scan. Improves consistency with Python/MCP naming conventions.
• Enhance descriptions with WHEN-to-use guidance and domain context. Example for get_IAT: 'Extract imported functions from a PE binary to identify suspicious library dependencies (e.g., WinINet for C2 communication). Call this early in triage to assess binary intent and potential behavior.'
• Document external tool prerequisites and paths. Add parameter documentation: 'This tool requires floss.exe installed at C:\Tools\FLOSS\floss.exe. Returns error if tool not found or binary cannot be processed.' Consider accepting FLOSS_EXE_PATH as an optional environment variable for portability.

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

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry