Loading ToolBench
MCPHawk is a Logging & Monitoring solution for MCP traffic, providing deep visibility into MCP client-server interactions
MCPHawk provides 5 read-only tools with reasonable naming and basic schemas. All tools start with action verbs (query_, get_, search_, list_) which is good (90% baseline met). However, descriptions vary in quality: some are adequate (query_traffic, search_traffic) but others are sparse (get_stats, list_methods have empty input schemas and minimal descriptions). Input parameter descriptions are present but inconsistent in detail. No output schemas are documented anywhere in the source code provided. The tool descriptions lack depth about when/why to use them and error guidance. All tools are READ_ONLY which is good for safety, but there's no explicit error handling strategy or recovery guidance documented. Average description length appears ~100-150 chars (baseline 194), which is on the low end. Tool compositions are single-responsibility which follows pattern:tool, but no pagination guidance for query_traffic despite accepting limit/offset.
Get a specific log entry by ID.
Get statistics about captured traffic.
List all unique JSON-RPC methods seen in traffic.
Query captured MCP traffic with optional limit and offset.
Search traffic by message content or type. Args: search_term: Term to search for in message content message_type: Filter by message type (request, response, notification) transport_type: Filter by transport type (streamable_http/http_sse/stdio/unknown) limit: Maximum number of results
Missing output schema documentation. No tool provides structured schema for return values. LLMs cannot plan downstream calls or extract specific fields without documented output structure.
Insufficient descriptions for get_stats and list_methods. get_stats has empty description; list_methods description is minimal (22 chars). Descriptions below 20-50 chars cannot adequately guide LLM tool selection.
No error handling guidance. Tools return strings (JSON-serialized) but no documentation of what error cases produce or how LLMs should interpret failures. 'No log found with ID' is a start but incomplete.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 54 | - | v1 |
Empty input schemas for get_stats and list_methods. These tools have {} input with no parameters, but this is not explicitly documented as intentional. Could be ambiguous to LLMs.
Missing pagination documentation. query_traffic accepts limit/offset but returns no indication of total count, next_cursor, or whether more results exist. Per pattern:paginated-result, paginated tools should signal whether more data is available.