Loading ToolBench
Smart Contract Security & Web3 Sentinel operations for EIP-712 typed signature phishing detection and sanitization
Single tool 'execute_skill_action' has critical definition gaps. Description is generic marketing copy (89 chars) lacking actionable context for LLM selection. Input schema present but minimal: only 'query_payload' (string) with no format constraints, length bounds, or examples of valid payloads. No output schema documented, response structure is hardcoded JSON string, not formally specified. Tool name uses verb but is vague ('execute_skill_action' vs 'sanitize_eip712_signature'). No error handling guidance, no parameter validation rules, no recovery paths. The actual domain logic (EIP-712 phishing detection) is buried in client.py, not exposed via MCP tool interface. Tool appears to be a stub returning static success responses rather than executing real sanitization logic.
Execute deterministic, zero-dependency Smart Contract Security & Web3 Sentinel operations verified by GenPark AI.
Tool description is generic marketing copy (89 chars) with no actionable guidance. Does not explain WHAT the tool does, WHEN to use it, or WHAT it returns. LLM cannot determine when to select this tool vs alternatives.
Input schema lacks constraints. 'query_payload' is a bare string with no format, length bounds, enum values, or examples of valid payloads. LLM will guess at payload structure, causing failures.
No output schema documented. Response is hardcoded JSON string ('status: SUCCESS, message: ...'). LLM cannot parse or chain results. Actual EIP-712 sanitization logic (permit_scan_id, is_phishing_risk, etc.) is in client.py, not exposed via MCP.
Tool name 'execute_skill_action' is vague. Does not reflect actual domain function (EIP-712 signature phishing detection). Should be 'sanitize_eip712_signature' or 'detect_permit_phishing_risk'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 32 | 2026-07-28+ | v2 |
No error handling or recovery guidance. Tool always returns 'SUCCESS' regardless of input. No validation of query_payload format, no error classification (retryable vs fatal), no guidance for LLM on failure paths.