mcp-wireshark demonstrates strong definition quality with well-structured tool schemas, comprehensive parameter descriptions, and clear naming conventions. All 16 tools have explicit input schemas with typed parameters and descriptions. Most tool descriptions are actionable and context-aware (100-350 chars). However, output schemas are not formally documented, the server returns text summaries of tshark output without a declared response structure. Tool names follow verb_noun patterns effectively (read_pcap, follow_tcp, analyze_iec61850). Security annotations (readOnlyHint=True) are correctly applied to 14 read-only tools. Parameter validation is present but sparse, no enum constraints for choice parameters (e.g., severity in expert_info accepts 'error|warn|note|chat' but is not declared as an enum). Error handling is minimal, no recovery guidance documented. Overall, this is a solid definition foundation that could reach A-grade with output schema documentation and richer validation constraints.

• Document output schemas for all tools. Example: 'read_pcap returns {packets: Array<{frame_number: number, protocol: string, src: string, dst: string, info: string}>, total_matches: number}'. This enables LLMs to extract fields and chain calls.
• Add enum constraints to choice parameters. Change 'severity' in expert_info from a string to an enum with values ["error", "warn", "note", "chat"]. Similarly, constrain 'protocol' in analyze_iec61850, decode_protocol, and protocol_stats.
• Add error handling guidance to tool descriptions. Example: 'If the file is not found, returns error 'File not found: {path}'. If tshark is not installed, suggests running check_installation first.'
• Document parameter dependencies explicitly. In decode_protocol, add: 'If fields is omitted, defaults depend on protocol parameter: http uses [frame.number, ip.src, ip.dst, http.request.method, ...], dns uses [frame.number, ip.src, ip.dst, dns.qry.name, ...], etc.'
• Add explicit guidance on pagination and result limits. Example: 'For captures larger than 1000 packets, call summarize_pcap first to understand the structure, then use display_filter to narrow the scope before calling read_pcap.'
• Implement per-tool max result limits with clear documentation. E.g., read_pcap should cap at 100 packets and document: 'Returns up to 100 packets. For larger captures, use display_filter to reduce the result set.'
• Add destructiveHint=True annotation to live_capture and export_json. Currently only readOnlyHint is applied; these tools modify filesystem state and should be flagged for agent caution.