Loading ToolBench
AI-powered fraud detection using Lithic honeypot cards for real-time scammer verification
The server defines 17 tools with schemas, but quality is inconsistent. Most tools have descriptions and input schemas, but many descriptions are generic or lack actionable guidance for LLM decision-making. Several tools combine multiple operations or have underdocumented parameter relationships. The naming is verb-driven and generally clear (get_, list_, create_, update_, toggle_, search_, subscribe_, poll_), which is strong. However, parameter descriptions lack constraint details (ranges, formats, dependencies), and output schemas are not explicitly documented. Error handling exists but is minimal in the code samples provided. The server attempts to follow the tool pattern but falls short on description depth and parameter clarity needed for LLM-safe operation.
Create a new honeypot card for fraud detection
Retrieve detailed information about a specific honeypot card
Establish a live transaction feed for real-time transaction monitoring
Get performance and usage metrics for polling operations
Get recent transactions from honeypot cards
Get subscription metadata and health status
Parameter descriptions lack constraint details (min/max ranges, regex patterns, format specifications). E.g., 'limit' appears in multiple tools with no bounds specified; 'spendLimitDuration', 'timeframe', 'feedDuration' lack format guidance (is it '30d', '30 days', 'P30D', or seconds?). LLMs cannot infer valid formats and will hallucinate values.
Output schemas are not documented. The tool definitions specify inputs but provide no guidance on what fields the response will contain, what type they are, or what downstream tools expect. This forces LLMs to guess structure and risks chaining failures.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 55 | - | v1 |
Retrieve details for a specific transaction
Get comprehensive details and analysis for a transaction
Retrieve all transactions for a specific merchant
Comprehensive system health monitoring for MCP server and dependencies
List all available honeypot cards with optional filtering and details
Poll a live transaction feed for new transactions (planned for future release)
Poll an active subscription for new fraud alerts
Search transactions using filters such as merchant name, amount range, and date
Create a subscription for real-time fraud alerts on specific cards
Enable or disable a honeypot card
Update spending limits for an existing honeypot card
Parameter relationships and dependencies are undocumented. E.g., 'subscribe_to_alerts' has both 'cardTokens' (array) and 'alertTypes' (array), but it's unclear if all combinations are valid, if both are required, or if they can be omitted. Dependencies force LLMs to guess or fail mid-plan.
Descriptions are too generic and lack 'WHEN to use' context. Many descriptions (e.g., 'Get recent transactions from honeypot cards') state WHAT but not WHEN to call vs alternatives (search_transactions, get_transaction_details). LLMs cannot disambiguate.
State-modifying operations (create_honeypot_card, update_card_limits, toggle_card_state, subscribe_to_alerts) lack confirmation or dry-run patterns. An agent could accidentally create dozens of cards or toggle wrong cards. No error recovery guidance.
'poll_live_feed' description states 'planned for future release', indicating it is not yet implemented. This tool should not be exposed until functional. Non-functional tools mislead agents into wasted calls.
No pagination or result limit guidance in descriptions. search_transactions, list_available_cards, get_recent_transactions accept 'limit' but don't specify default, max, or behavior when not provided. Large result sets can blow context windows.
Parameter naming inconsistencies across tools. Some use 'cardToken', others 'card_token' style may vary. 'merchantDescriptor' vs 'merchantName' suggests ambiguous field semantics. Inconsistency forces LLMs to reason about synonyms.
Error handling and recovery guidance missing from tool descriptions. No mention of what happens on invalid cardToken, failed authentication, rate limits, or network timeouts. LLMs have no guidance on retry logic or fallback.
Tool composition risk: 'get_card_details' accepts optional 'includePan' and 'reason' params, suggesting a permission gate, but descriptions don't clarify when/why the gate triggers or what permission is required. If the reason is logged for audit, that's a security concern. If it's decorative, it's confusing.