Wireshark MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose, covering different aspects of packet analysis: capture, read, filter, decode, export objects, extract credentials, follow streams, list interfaces, and statistics. No overlap in functionality.
Naming Consistency5/5
All tools follow a consistent 'tshark_' prefix with lowercase and underscores. Verbs are well-chosen and predictable (e.g., capture, decode, filter, follow_stream), making the surface easy to navigate.
Tool Count5/5
With 10 tools, the server is well-scoped for the domain of network packet analysis. It provides a focused set without being overwhelming or too sparse.
Completeness4/5
The tool set covers key workflows: capture, read, filter, decode, extract objects/credentials, and statistics. Minor gaps exist (e.g., no tool to stop capture or merge pcaps), but the core functionality is well-represented.
Average 3.2/5 across 10 of 10 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavioral traits. It does not mention that the tool is read-only, nor does it describe potential performance impacts with large files or error conditions. The description lacks transparency for a safe and effective invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) and to the point, but could be more structured (e.g., listing all supported types). It is concise but not optimally informative; adding the full enum list would improve clarity without much verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters (2 required) and no output schema. The description does not explain the output format or return structure, nor does it address error handling or file size considerations. Given the complexity and lack of annotations, the description is incomplete for an agent to fully understand invocation consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (100%), so baseline is 3, but the description's list of types ('hierarchy, conversations, and endpoints') contradicts the schema's full enum which also includes 'io', 'http', 'dns'. This omission could mislead the agent into thinking only those three types are available, reducing parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves protocol statistics from pcap files and lists three output types (hierarchy, conversations, endpoints). This distinguishes it from siblings like tshark_filter (filtering) and tshark_decode (decoding). However, the description omits 'io', 'http', and 'dns' types that exist in the schema, making it slightly incomplete but still clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like tshark_read_pcap or tshark_filter. No prerequisites or context for selecting the 'type' parameter are provided. The description simply states what it does without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not disclose behavioral traits such as permissions needed, side effects, error handling (e.g., if packet not found), or output format. The description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two short sentences. It avoids redundancy, though it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not explain what the tool returns (e.g., decoded packet details in what format). For a decoding tool with 5 parameters, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool decodes specific packets with detailed protocol information, using a specific verb and resource. However, it does not explicitly differentiate from sibling tools like tshark_read_pcap, which may also decode packets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only says 'useful for deep packet inspection,' which implies usage but provides no explicit guidance on when to use this tool versus alternatives. No when-not or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden. It does not disclose that extraction likely writes files to disk, whether the pcap is modified, or any authorization/rate limit concerns. The behavioral details are minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the verb and key resources, making it efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of file extraction across multiple protocols, the description leaves out important context such as the default protocol (http), default output directory (/tmp/mcp-extracted), and behavior when files already exist. No output schema is provided, increasing the need for description completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description adds the list of protocols (which matches the enum) but no additional meaning beyond the schema for 'file' or 'outputDir'. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'extract' and resources 'files from HTTP, DICOM, IMF, SMB, or TFTP traffic' and the pcap file context. It clearly states what the tool does but does not differentiate from sibling tools like tshark_export_objects or tshark_extract_credentials, though the name and purpose are distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only states what the tool does, with no guidance on when to use it versus alternatives like tshark_export_objects or tshark_follow_stream. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full transparency responsibility but only states basic operation. It does not disclose performance implications, file requirements (beyond parameter descriptions), or error behavior, leaving significant gaps for an agent to assess side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct with two sentences, no redundant phrases, and the primary action is front-loaded. Every sentence contributes to understanding the core function without excess.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits context about output format options, field extraction behavior, and handling of large files. Given the absence of an output schema and the presence of multiple parameters, this is insufficient for an agent to fully understand what the tool returns or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema coverage is 100% and each parameter has a description, the tool description adds no additional meaning beyond what the schema provides. The baseline of 3 is appropriate as the description does not compensate for any missing parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool applies a display filter to a pcap file and returns matching packets, specifying its purpose and utility. It distinguishes from siblings like tshark_stats (statistics) and tshark_capture (capturing), but could more explicitly differentiate from tshark_read_pcap or tshark_follow_stream.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides only a vague phrase 'Useful for extracting specific traffic' without clear guidance on when to use this tool versus alternatives like tshark_follow_stream or tshark_stats. No prerequisites, exclusions, or when-not-to-use conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the core behavior of listing and exporting HTTP objects, implying file creation via outputDir parameter. However, it lacks details on side effects, permissions, or whether the pcap is modified. With no annotations, more behavioral context would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, and contains no extraneous information. Every word is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not explain what the output looks like (e.g., list format, returned object paths) or how extraction results are returned. With no output schema, this information is missing, leaving the agent guessing about the tool's return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all parameters. The description adds no extra semantic meaning beyond stating the overall purpose. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists and exports HTTP objects from pcap files. While specific to HTTP objects, it does not differentiate from sibling tool 'tshark_extract_files', which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like tshark_extract_files or other tshark tools. The agent receives no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the responsibility for disclosing behavioral traits. It only states 'read and analyze' without clarifying if the tool is read-only, what happens on error, or any side effects (e.g., resource usage). The phrase 'analyze' is vague and does not specify any transformations or processing beyond extraction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences that immediately convey the core action and output. There is no fluff or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and no output schema, the description is too brief. It does not explain what 'analyze' entails, how the JSON output is structured, or any limitations (e.g., file size). For a complex tool like pcap analysis, more detail is needed for adequate completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description does not add any parameter semantics beyond what the schema already provides. For example, it doesn't mention that 'file' is required or that 'count' has a default and maximum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (read and analyze a pcap file), the context (remote Kali machine), and the output format (JSON). It effectively distinguishes from sibling tools like tshark_capture (which captures live traffic) and tshark_filter (which filters already captured data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not mention when to use this tool versus alternatives, when not to use it, or any prerequisites. For instance, it doesn't note that the pcap file must exist or that tshark should be installed on the remote host.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially fills the gap by noting the result format (JSON) and the sudo requirement. However, it does not disclose default behaviors, error states, or potential side effects like network disruption.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, containing two sentences that front-load the core action and add the critical sudo requirement. Every word serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no output schema, the description covers the essential purpose and a key prerequisite (sudo), but it lacks details on output format specifics, error scenarios, and usage context compared to siblings. It is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with descriptions for all parameters. The description adds no extra parameter-level meaning beyond what the schema provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts a packet capture on a remote Kali machine and returns JSON. The name 'capture' distinguishes it from siblings like 'read_pcap' and 'filter', but no explicit differentiation is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only mentions a prerequisite (sudo) but provides no guidance on when to use this tool versus alternatives like `tshark_read_pcap` or `tshark_filter`. No when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It only says 'search' but does not disclose whether results are displayed, saved, or if any data is modified. No safety or permission hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise, front-loaded with purpose. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is adequate but lacks behavioral detail that would make it fully complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already describes the 'file' parameter. The description adds no extra meaning beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for potential credentials in network traffic' with specific examples of protocols (HTTP Basic Auth, FTP, Telnet). This is distinct from sibling tools like tshark_filter or tshark_follow_stream.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it or which sibling tools might be better suited for different credential extraction scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only says 'Shows the full conversation' without explaining output format, side effects, or limitations (e.g., only one stream at a time). It does not mention that the tool reconstructs the stream by reassembling packets, nor does it discuss permissions or resource usage. The minimal description leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and 15 words – highly concise. Every word is informative and there is no redundancy. It front-loads the main purpose immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is moderately complete. It tells the core function but omits details like what the output looks like (e.g., plaintext conversation) and how to handle multiple streams. There's a minor inconsistency: the description lists HTTP but the schema includes TLS as a protocol option. This gap reduces completeness for a tool with four parameters and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions. For example, it does not clarify the difference between format options ('ascii', 'hex', 'raw') or how streamIndex works. The schema already provides enum values and descriptions, so the description is not required to add more, but it does not compensate for any ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's core function: 'Follow and reconstruct a TCP, UDP, or HTTP stream from a pcap file. Shows the full conversation.' It uses specific verbs and resources, and distinguishes from sibling tools like tshark_filter (which filters packets) and tshark_read_pcap (which reads raw packets).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after capturing a pcap file but provides no explicit guidance on when to use this tool versus alternatives like tshark_filter or tshark_stats. It does not mention prerequisites, limitations, or when not to use it. The context is clear but lacks exclusions or directed advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states listing interfaces, which is non-destructive, but does not clarify permissions, limitations, or scope of 'available'. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence, front-loaded with key information, no extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool, the description fully captures what the tool does. No output schema is expected; the tool name and sibling context provide further clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline 4 applies. The description does not need to add parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists available network interfaces for packet capture, with a specific resource (network interfaces) and action (list), distinguishing it from sibling tools like tshark_capture or tshark_filter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied as a preliminary step before capture, but no explicit guidance on when to use or alternatives is provided. The context of sibling tools helps, but the description itself lacks this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![sec-wireshark-mcp MCP server](https://glama.ai/mcp/servers/schwarztim/sec-wireshark-mcp/badges/card.svg)](https://glama.ai/mcp/servers/schwarztim/sec-wireshark-mcp)

Score Badge

Copy to your README.md:

[![sec-wireshark-mcp MCP server](https://glama.ai/mcp/servers/schwarztim/sec-wireshark-mcp/badges/score.svg)](https://glama.ai/mcp/servers/schwarztim/sec-wireshark-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/schwarztim/sec-wireshark-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server