Provides tools for loading and analyzing PCAP/PCAPNG files using Wireshark's sharkd, enabling AI agents to inspect network packets, conversations, protocol statistics, and more.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SharkMCP load capture.pcapng and show summary"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that exposes sharkd — Wireshark's programmatic interface — as a set of tools for LLMs. Load PCAP/PCAPNG files and analyse them with natural language.
Python 3.10+
Wireshark (provides sharkd)
Related MCP server: mcp-wireshark
git clone https://github.com/weirdmachine64/sharkmcp.git
cd sharkmcp
pip install -e .Or run directly from the repo without installing:
uvx --from git+https://github.com/weirdmachine64/sharkmcp sharkmcpAdd to your .mcp.json:
{
"mcpServers": {
"sharkmcp": {
"command": "uvx",
"args": ["--from", "git+https://github.com/weirdmachine64/sharkmcp", "sharkmcp"],
"env": {
"SHARKMCP_TIMEOUT": "300"
}
}
}
}Env var | Default | Description |
|
| Path to sharkd binary |
|
| Per-request timeout in seconds |
Each loaded PCAP gets a dedicated sharkd subprocess. Results from expensive scans (conversations, expert info, export objects) are cached in memory so paginated follow-up calls are served without re-scanning.
Tool | Description |
| Load a PCAP/PCAPNG file |
| List all loaded PCAPs |
| Terminate session and free memory |
Tool | Description |
| Frame count, duration, file size, protocols seen |
| All available tap types, follow protocols, field types |
Tool | Description |
| Paginated frame list with display filter |
| Full protocol tree for one frame |
| Extract arbitrary fields per packet as a table |
Tool | Description |
| Validate a display filter and/or field name |
| Autocomplete field or preference names by prefix |
| Read dissector preferences |
| Set a dissector preference for this session |
| Annotate a frame (session-scoped) |
Tool | Description |
| Nested protocol tree with frame/byte counts |
| Per-interval frame and byte counts |
| Multi-line traffic graph; supports |
| Reassemble a stream ( |
Tool | Description |
| Conversation table — bytes/frames per peer pair |
| Endpoint table — tx/rx per host |
Supported layer types for both: tcp, udp, ip, ipv6, eth, sctp, dccp, mptcp, wifi, bluetooth, zigbee, fc, fddi, usb, and more.
Tool | Description |
| Per-frame anomaly detection — errors, warnings, notes, chats |
| Aggregate stats for |
| Request/response latency for |
| Round-trip delay for |
| Flow diagram data for |
Tool | Description |
| SIP/H.323 call list with state and participants |
| RTP stream inventory; pass |
| UDP multicast stream statistics |
Tool | Description |
| List extractable objects ( |
| Download an object, TLS session keys ( |
Tool | Description |
| Run any sharkd tap directly — up to 16 specs in one PCAP scan. Use |
> load_pcap("/captures/traffic.pcap", alias="traffic")
> protocol_hierarchy("traffic")
> expert_info("traffic", limit=20)
> conversations("traffic", type="tcp", sort_by="bytes")
> extract_fields("traffic", ["dns.qry.name", "dns.a"], filter="dns")
> follow_stream("traffic", "http", "tcp.stream eq 0")
> export_objects("traffic", type="http")
> download_object("traffic", "eo:http_0") LLM
│ MCP (stdio)
▼
SharkMCP server
│ JSON-RPC 2.0 (stdin/stdout)
├─ sharkd [pcap-1]
├─ sharkd [pcap-2]
└─ sharkd [pcap-N]One sharkd subprocess per loaded PCAP. Sessions are isolated — concurrent queries on different aliases never block each other.
Autocomplete field names or preference names by prefix.
field — field prefix, e.g. "tcp." → all tcp.* dissector fields.
pref — preference prefix, e.g. "tcp." → all tcp.* preferences.
At least one of field or pref must be provided.
Dense protocols (e.g. "opcua.") can return thousands of entries;
limit caps the list (0 = no cap).
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | ||
| field | No | ||
| pref | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that dense protocols can return many entries and that limit can cap results (0=no cap). It also mentions the requirement of at least one prefix. This provides good insight into behavior, though return format is not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using bullet-style and backticks for clarity. It front-loads the main action and each sentence adds value. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a simple task, the description covers inputs, constraints, and potential scale. It lacks mention of return type or errors, but is reasonably complete for an autocomplete tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It explains field and pref with examples, and limit with its purpose. However, the required 'alias' parameter is not described at all. Overall, three of four parameters are well explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool autocompletes field or preference names by prefix, with specific examples for each. It distinguishes between field and pref, and there are no sibling autocomplete tools, so it is unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies that at least one of field or pref must be provided, and explains the limit parameter for handling dense protocols. While it does not explicitly contrast with alternatives, no sibling tool serves the same purpose, so the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Conversation table for a given layer. Sums frames/bytes per peer pair.
Results are sorted by sort_by (descending) and paged with skip/limit.
The PCAP is scanned only on the first call for a given filter; all
subsequent pages are served from an in-memory cache. Set limit=0 for all.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | ||
| type | No | tcp | |
| display_filter | No | ||
| sort_by | No | bytes | |
| skip | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses caching behavior (first call scans PCAP, subsequent pages from cache) and pagination. However, it does not state whether the tool is read-only or if it has side effects. With no annotations, this is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two short paragraphs that front-load the purpose. Every sentence adds meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should detail the return format beyond 'sums frames/bytes per peer pair'. It does not specify whether the output is a list of objects or details the columns. Acceptable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains `sort_by`, `skip`, `limit`, and implies `alias` (layer). It also notes `limit=0` for all results. But it omits `display_filter` and `type` parameters, which are not covered by the schema descriptions (0% coverage). Thus it partially compensates but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a conversation table for a given layer, summing frames/bytes per peer pair. It distinguishes itself from sibling tools like 'endpoints' or 'protocol_hierarchy' by focusing on peer pairs, but does not explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 describes sorting and paging but does not indicate when to choose 'conversations' over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download the raw content of an exportable object, TLS secrets, or RTP audio.
Tokens come from:
export_objects → "eo:http_0", "eo:imf_0", etc.
TLS session keys → "ssl-secrets" (NSS Key Log format, if embedded)
RTP audio stream → "rtp:<src_ip>_<src_port>_<dst_ip>_<dst_port>_<ssrc>"
Content is returned base64-encoded under the data key along with
the MIME type and original filename where available.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | ||
| token | Yes |
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 discloses that content is base64-encoded under 'data' key, includes MIME type and filename. This is good transparency for a read-like operation, though no explicit mention of side effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and well-structured: a clear first sentence followed by bullet points for token formats. Every sentence adds value, with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description covers return format and token sources but omits the meaning of 'alias' and any usage examples. It is adequate but not fully complete for a standalone tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only explains the 'token' parameter with detailed format examples. The 'alias' parameter is not described at all, leaving half the parameters undocumented. The description partially compensates but not sufficiently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb and resource: 'Download the raw content of an exportable object, TLS secrets, or RTP audio.' It distinguishes from siblings by listing exact token formats and sources, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly defines when to use the tool by listing token sources, but it does not explicitly state when not to use it or mention alternatives. Sibling tools like 'export_objects' or 'extract_fields' are not compared, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Endpoint table for a given layer. Sums tx/rx frames and bytes per host.
Results are sorted by sort_by (descending) and paged with skip/limit.
The PCAP is scanned only on the first call for a given filter; all
subsequent pages are served from an in-memory cache. Set limit=0 for all.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | ||
| type | No | tcp | |
| display_filter | No | ||
| sort_by | No | bytes | |
| skip | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses caching behavior ('first call scans, subsequent from cache'), sorting, and paging. However, it does not explicitly state that the tool is read-only or mention any side effects, which would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences), front-loaded with the tool's purpose, and each sentence adds meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 covers key aspects: what the tool does, sorting, paging, and caching. It could mention the return format or error handling, but overall it is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains that 'sort_by' controls ordering and 'skip'/'limit' page results, including that 'limit=0' returns all. However, it does not describe the 'alias', 'type', or 'display_filter' parameters in detail, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides an 'Endpoint table for a given layer' summing tx/rx frames and bytes per host. This distinguishes it from sibling tools like 'conversations' (which pairs endpoints) and 'protocol_hierarchy' (which aggregates protocols).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains sorting and paging but does not explicitly state when to use this tool versus alternatives among the many sibling tools. It lacks guidance on when not to use it or which tool to use for different aggregation needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-frame expert diagnostics — errors, warnings, notes, and chats.
Returns Wireshark's built-in anomaly detection results: TCP retransmissions,
malformed packets, unusual sequences, and protocol violations.
Each entry contains frame number (f), severity (s), protocol (p),
and message (m). Results are cached after the first scan.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | ||
| display_filter | No | ||
| skip | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses cache-after-first-scan behavior and lists output field identifiers (f, s, p, m). However, with no annotations, it could provide more details on thread safety, performance impacts, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two paragraphs with a clear summary at the start. It is mostly concise, though the second paragraph contains some redundant enumeration of what 'anomaly detection results' includes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 undocumented parameters, no output schema, and no annotations, the description is incomplete. It explains the output structure but fails to clarify parameter usage or broader invocation context, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters with 0% description coverage, and the description does not explain any of them (alias, display_filter, skip, limit). It adds no semantic meaning beyond the raw schema names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns per-frame expert diagnostics including errors, warnings, notes, and chats, and specifies it provides Wireshark's built-in anomaly detection results. This is a specific verb-resource pair, but it does not explicitly differentiate from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, nor are any prerequisites or exclusion criteria mentioned. The description only implies use for anomaly detection without contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List exportable objects of the given type found in the capture.
Each returned object includes a _download token that can be passed to
download_object to retrieve the raw content. Supported types:
http, dicom, smb, tftp, imf, ftp-data.
The PCAP is scanned only on the first call for a given type; subsequent pages are served from cache.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | ||
| type | No | http | |
| skip | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses caching behavior (scan on first call, cache subsequent) and download token, but no mention of auth, rate limits, or error states. Adequate given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with clear front-loading of purpose, no wasted words, but could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes return token and caching but lacks details on pagination (skip/limit), alias usage, and the full return format; adequate for a list tool but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only the 'type' parameter is described with enum values; alias, skip, and limit are undocumented in the description, leaving gaps despite 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly uses the verb 'list' on the resource 'exportable objects', and differentiates from sibling 'download_object' by explaining the token mechanism for later retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies using this tool to list and then 'download_object' for content, but does not explicitly state when not to use it or compare to other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract arbitrary fields per packet, e.g.
["ip.src", "tcp.dstport", "http.host"]. Returns rows of dicts keyed
by field name.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | ||
| fields | Yes | ||
| display_filter | No | ||
| skip | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It reveals return format but omits behavioral details like error handling if fields are invalid, performance impact, or whether a pcap must be loaded.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence plus example) and front-loaded. However, it could be structured to cover multiple parameters efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description is incomplete. Key aspects like pagination, filtering, and alias selection are missing, leaving gaps for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add meaning. Only 'fields' is illustrated via example; 'alias', 'display_filter', 'skip', and 'limit' are unexplained, leaving 4 out of 5 parameters ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts arbitrary fields per packet and returns rows of dicts, with a concrete example. It distinguishes from siblings like list_packets or packet_detail by focusing on field extraction, but lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., loaded pcap) or limitations, leaving the agent without decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reassemble a stream. display_filter selects it (e.g. tcp.stream eq 3).
Returns client/server addrs and base64 payload chunks with direction.
Long-lived streams can produce huge payload lists; max_payloads caps
how many chunks are returned. Set to 0 for no cap.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | ||
| protocol | Yes | ||
| display_filter | Yes | ||
| max_payloads | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behaviors: returns client/server addresses and base64 payload chunks with direction, and caps payload lists via max_payloads. However, it does not mention any authorization needs or 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, each adding value: purpose, return details, and payload limit. Front-loaded with the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return structure (addrs, payload chunks, direction) and the cap feature. However, it does not explain the alias or protocol parameters, leaving gaps for an agent to understand all inputs. Slightly incomplete for a tool with 4 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for display_filter (example) and max_payloads (cap, set to 0 for no cap), but alias and protocol are not described, leaving them to the schema alone. With 0% schema coverage, the description partially compensates but misses two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reassembles a stream with a specific verb ('Reassemble'), and the display_filter example distinguishes it from sibling tools like list_packets or conversations that return individual packets or conversations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 tap or extract_fields. The description implies use for stream analysis but does not state when not to use it or mention preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one or all sharkd dissector preferences.
Pass a dotted preference name (e.g. "tcp.check_checksum") to read a
single value, or omit to dump all preferences. Useful for checking
whether a dissector is enabled or what port a protocol is bound to.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | ||
| preference | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavioral traits. It indicates the tool is read-only, which is appropriate, but lacks details on error conditions, permissions, or side effects. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main action, and every sentence adds value. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers basic functionality. However, it omits details like return format and does not explain the 'alias' parameter, leaving minor gaps for a tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the 'preference' parameter in detail with an example, but does not clarify the 'alias' parameter. With 0% schema coverage, the description partially compensates but leaves a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads one or all sharkd dissector preferences, using a specific verb ('read') and resource. It distinguishes from sibling 'set_preference' by being a read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to use the tool: pass a dotted preference name for a single value or omit to dump all. It provides an example use case, but does not explicitly state when not to use it or compare to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-interval traffic graph for up to 8 simultaneous lines.
Each entry in graphs must be one of:
"packets" | "bytes" | "bits" — basic counters
"sum:" | "avg:" — aggregate a numeric field per interval
"min:" | "max:" — min/max of a numeric field per interval
"load:" | "frames:" — bit-rate or frame count for a field
filters — optional per-graph display filters (parallel list to graphs);
enables multi-line graphs of different protocol streams.
Results are paged with skip/limit (default 300 buckets ≈ 5 min at 1 s).
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | ||
| graphs | Yes | ||
| interval_ms | No | ||
| filters | No | ||
| skip | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively discloses key behavioral traits: it supports up to 8 lines, enumerates valid graph types, explains optional filters, and mentions pagination via skip/limit. It does not cover authentication or side effects, but such details may not be critical for a read-like data tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line purpose, a clear list of graph types, a brief note on filters, and pagination details. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description partially covers the tool's behavior and parameters, but it omits explanation of the 'alias' parameter and does not describe the structure of the returned data (e.g., bucket format). This leaves some ambiguity for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning. It explains the 'graphs' parameter with detailed syntax, 'filters' as a parallel list, and 'skip'/'limit' for pagination. It mentions 'interval_ms' implicitly via default bucket count. Only the 'alias' parameter is left unexplained, which is a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Per-interval traffic graph for up to 8 simultaneous lines.' It lists specific graph types and distinguishes itself from other sibling tools like io_stats and protocol_hierarchy by focusing on time-series graphing with configurable metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates usage for graphing traffic per interval, but lacks explicit guidance on when to use this tool over alternatives like io_stats (which might provide aggregate stats) or when not to use it. No clear exclusions or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-interval frame and byte counts. interval_ms is the bucket size.
Results are in chronological order and paged with skip/limit.
The PCAP is scanned only on the first call for a given (interval, filter)
combination; subsequent pages are served from cache.
Default limit is 300 intervals (~5 min at 1 s buckets). Set limit=0 for all.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | ||
| interval_ms | No | ||
| display_filter | No | ||
| skip | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the PCAP is scanned only on the first call per (interval, filter) combination, with subsequent pages served from cache. This is a useful behavioral trait. It does not explicitly state that the tool is read-only, but the context implies no modification. Overall, good transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: four sentences, each adding value. It is front-loaded with the core purpose, followed by paging and caching behavior, then default and special values. No redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no output schema, no annotations), the description covers the main usage patterns: pagination, caching, interval meaning. However, it does not detail the return format (e.g., whether each interval includes frame count and byte count as separate fields) or the behavior of the 'display_filter' parameter. This is a minor omission for a tool that is primarily about reading data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It explains that 'interval_ms' is the bucket size, and that 'skip'/'limit' control paging, with the default limit and special value (0) documented. However, the required parameter 'alias' and 'display_filter' are not explained at all, leaving gaps in semantic understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Per-interval frame and byte counts,' which clearly states the tool's function: it provides counts of frames and bytes aggregated over time intervals. This distinguishes it from sibling tools like iograph (which likely deals with I/O graphs) and protocol_stats (which probably concerns protocol-specific statistics).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains pagination with skip/limit and caching behavior (first call scans, subsequent pages from cache). It also mentions the default limit and how to get all results. However, it does not provide guidance on when to use this tool versus alternatives such as iograph or protocol_stats, nor does it specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Page through packets via sharkd frames.
display_filter accepts Wireshark display-filter syntax.
columns overrides the default column set with arbitrary field names
(e.g. ["frame.number", "ip.src", "tcp.dstport"]).
refs is a list of reference frame numbers for delta-time calculations.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | ||
| display_filter | No | ||
| skip | No | ||
| limit | No | ||
| columns | No | ||
| refs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It indicates a read-only operation but does not confirm safety, performance implications, or side effects. Lacks detail on return behavior beyond paging.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief and front-loaded with the main purpose. Uses examples and bullet-style explanation for parameters. No unnecessary sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing critical context: alias likely refers to a loaded pcap but unexused; skip/limit paging parameters not described; no output schema; no annotations to compensate. Tool has 6 parameters and no output schema, so incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description explains display_filter, columns, and refs with useful context (Wireshark syntax, example, purpose). However, alias (required), skip, and limit are not explained despite low schema coverage (0%). Covers 50% of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it pages through packets using sharkd frames, which is a list operation. It is distinct from packet_detail which provides detail for a single packet. However, it lacks explicit differentiation from siblings like extract_fields or follow_stream.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention prerequisites (e.g., a pcap must be loaded via list_pcaps/load_pcap) or when to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every loaded PCAP with its current sharkd status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only minimally discloses behavior (read-only list with status), lacking details on permissions, side effects, or output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence front-loading verb and resource, zero filler words, and perfectly scaled for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with an output schema, the description covers the essential purpose. It could clarify 'sharkd status' values or edge cases but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100% as defined. The description adds value by stating the output includes 'sharkd status', which exceeds the baseline of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('List') and the target ('every loaded PCAP') with additional qualifier ('with its current sharkd status'), making it distinct from siblings like load_pcap and unload_pcap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing all loaded PCAPs, but does not explicitly state when to use it over alternatives (e.g., pcap_summary for details on a single PCAP) or mention prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a PCAP/PCAPNG file into a fresh sharkd session.
alias defaults to the basename. Each loaded PCAP keeps a dedicated
sharkd subprocess warm so subsequent queries are interactive.
Returns the alias and basic status (frame count, duration, file size).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| alias | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that each PCAP gets a dedicated sharkd subprocess and that subsequent queries are interactive, and it mentions the return value format. However, it does not discuss potential destructive side effects or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with a short bullet point, no filler, and places the most important action first. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a load tool with no output schema, the description adequately covers the return value (alias and basic status) and behavioral nuance (dedicated subprocess). It is complete for an AI agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description compensates by explaining that 'alias defaults to the basename.' This adds meaningful context beyond the schema's property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Load a PCAP/PCAPNG file into a fresh sharkd session,' which is a specific verb and resource. It distinguishes from sibling tools like list_pcaps (lists loaded) and unload_pcap (removes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (initial loading before queries) but does not explicitly state when to use vs. alternatives or when not to use it. It lacks guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
UDP multicast stream statistics.
Returns per-stream packet counts, byte rates, and burst statistics for all UDP multicast flows in the capture.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | ||
| display_filter | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes outputs but does not disclose side effects, auth, or rate limits. No annotations to rely on.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks parameter details and usage guidance, incomplete for effective use given no annotations or output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameters 'alias' and 'display_filter' are not explained in description despite 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'returns' and specific resource 'UDP multicast streams' with detailed outputs. Distinguishes from siblings like rtp_streams.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied for obtaining multicast stream statistics, but no explicit when/when-not or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full protocol tree for one frame.
include_bytes — add raw bytes (base64) per layer.
include_hidden — include hidden protocol tree fields.
ref_frame — reference frame number for delta-time display.
prev_frame — previous frame number for delta-time display.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | ||
| frame_number | Yes | ||
| include_bytes | No | ||
| include_hidden | No | ||
| ref_frame | No | ||
| prev_frame | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It explains optional parameters and their effects (e.g., include_bytes adds raw bytes, ref_frame for delta-time). However, it does not explicitly state that the tool is read-only, or what operations it performs (e.g., no indication of side effects or data modification). The disclosure is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single introductory sentence followed by parameter explanations in a clear structure. It avoids unnecessary words. However, the parameter list could be formatted more cleanly (e.g., inline with the intro) but is still highly readable and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description should provide complete context. It lacks details about the return format (e.g., JSON tree structure), what fields are included in the 'full protocol tree,' and how parameters like ref_frame and prev_frame affect the output. The absence of behavioral or output information leaves significant gaps for an agent to understand the tool's behavior fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage (no parameter descriptions), so the tool description must compensate. It explains 4 of 6 parameters (include_bytes, include_hidden, ref_frame, prev_frame) beyond their types and defaults, adding semantic meaning (e.g., 'add raw bytes per layer'). The required parameters alias and frame_number are not described, but their purpose is inferable from context. Overall, the description adds significant value over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Full protocol tree for one frame.' This specifies the verb (retrieve) and resource (protocol tree for a single frame), effectively distinguishing it from sibling tools like list_packets (which lists frames) and follow_stream (which reassembles streams).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool vs. alternatives. While the purpose is clear, there is no guidance on prerequisites or comparisons with similar tools (e.g., extract_fields for specific fields). The parameter explanations imply use cases, but explicit when-to-use / when-not-to-use information is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Combined status + analyse: filename, size, frame count, duration,
protocols seen, first/last timestamps.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only lists output fields, not whether the operation is read-only, requires a loaded pcap, or has performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single line, which is concise. However, it front-loads a confusing phrase ('Combined status + analyse') and lacks structured details. It could be clearer without much extra length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and no annotations or output schema, the description should fully explain the tool. It lists output fields but omits that the pcap must be loaded via alias and what prerequisites exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'alias' with no description (0% coverage). The tool description does not reference the parameter or clarify its meaning, providing no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists fields like filename, size, frame count, etc., indicating it provides a summary of a pcap. However, it uses 'Combined status + analyse' which may confuse since those are not sibling tool names. The purpose is implied but not explicitly stated with a verb+resource structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 the many sibling tools (e.g., list_pcaps, packet_detail). There is no mention of prerequisites or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Protocol hierarchy stats — nested tree of frame/byte counts per protocol.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | ||
| display_filter | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only hints at the output structure (nested tree) but omits whether the operation is read-only, requires authentication, or has side effects. The description adds minimal value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise with no wasted words. However, it is too brief; it sacrifices essential information (e.g., parameter explanations) for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters, no output schema, and no annotations, the description is critically incomplete. It does not define the required 'alias' parameter or the optional 'display_filter', leading to potential misuse by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain either parameter ('alias' or 'display_filter'). The agent must rely solely on the parameter titles, which are insufficient for correct use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Protocol hierarchy stats — nested tree of frame/byte counts per protocol.' This clearly indicates the tool returns a hierarchical breakdown of protocol statistics. However, it does not explicitly state the action (e.g., 'get' or 'list') and fails to differentiate from the sibling tool 'protocol_stats'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'protocol_stats' or 'pcap_summary'. There is no mention of prerequisites, recommended contexts, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Protocol-level aggregate statistics.
protocol options: dns — query/response counts by type and return code http — HTTP request/response packet counters http_requests — requests grouped by URI http_server — load distribution across servers http_seq — HTTP request sequences http2 — HTTP/2 stream statistics rtsp — RTSP packet counters sip — SIP response code counters dhcp — DHCP message type distribution h225 — H.225 message and response status
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | ||
| protocol | Yes | ||
| display_filter | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. However, it does not mention any traits such as whether the operation is read-only, requires authentication, has rate limits, or what side effects occur. The agent cannot infer safety or prerequisites from the description alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single sentence followed by a clean list of protocol options. Each entry is brief but informative. No redundant or unnecessary text. The structure is easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are three parameters, no output schema, and no annotations, the description should provide comprehensive guidance for correct invocation. While the protocol options are well-covered, the required 'alias' parameter is unexplained, and the output format (e.g., aggregated counts or detailed statistics) is not specified. The agent lacks critical information to use the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value by enumerating and explaining the 'protocol' enum values. However, it does not describe the 'alias' parameter (which is required) or the optional 'display_filter'. With 0% schema description coverage, the agent must guess the meaning of 'alias' (likely a capture file alias) and the usage of 'display_filter'. The description partially compensates for the schema's lack of documentation but leaves key parameters unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Protocol-level aggregate statistics' and enumerates each protocol option with a brief explanation of what kind of statistics are provided (e.g., 'query/response counts by type and return code' for dns). This gives the agent a clear understanding of what the tool produces, though it does not explicitly differentiate from sibling tools like 'io_stats' or 'protocol_hierarchy'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. While the sibling tools are listed, there is no comparison or contextual cue to help the agent choose between 'protocol_stats' and tools like 'io_stats', 'expert_info', or 'protocol_hierarchy'. The description only lists available protocols without explaining when each is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Response time delay statistics for signalling protocols.
Measures per-transaction round-trip delay: h225_ras — H.225 RAS registration/admission delays megaco — MEGACO/H.248 gateway control delays mgcp — MGCP gateway control delays radius — RADIUS authentication/accounting delays
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | ||
| protocol | Yes | ||
| display_filter | No |
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 does not mention authentication requirements, rate limits, side effects, or output format, leaving significant gaps in understanding tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and front-loaded purpose. The protocol list is efficiently integrated, though no additional structure like parameter descriptions is provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no output schema, and no annotations, the description is incomplete. It omits explanation of 'alias' and 'display_filter', and lacks any description of return values or constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to compensate. Only the 'protocol' parameter is partially explained through the enum list; 'alias' and 'display_filter' remain undescribed, failing to add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool measures per-transaction round-trip delay statistics for signaling protocols, listing specific protocols (h225_ras, megaco, mgcp, radius) and their meanings. This distinguishes it from sibling tools like service_response_time or voip_calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like service_response_time. It neither states prerequisites nor scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
RTP stream inventory and per-stream quality analysis.
Without stream_spec — returns all RTP streams with SSRC, codec,
packet count, and timing.
With stream_spec — returns jitter, packet loss, and sequence error
statistics for one stream. Format:
<src_ip>_<src_port>_<dst_ip>_<dst_port>_<ssrc>
e.g. 200.57.7.195_9762_200.57.7.196_26946_0xd2bd4e3e
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | ||
| stream_spec | No | ||
| display_filter | No |
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 describes input/output behavior but does not disclose potential side effects, error handling, idempotency, or prerequisites like permissions. The description mentions returned fields but omits operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two paragraphs and front-loaded purpose. Each sentence adds value by detailing the two modes and the stream_spec format. It could be slightly more compact, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description provides useful return field hints for both modes. However, it does not cover error conditions, default behavior for missing parameters, or the relationship between alias and stream_spec. Completeness is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the stream_spec parameter with format and example, but does not explain the required alias parameter or the optional display_filter parameter. This leaves significant semantic gaps for two out of three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides RTP stream inventory and per-stream quality analysis, with distinct behaviors based on the presence of stream_spec. It identifies the specific resource (RTP streams) and action (analysis/inventory), but does not explicitly differentiate from sibling tools like multicast_streams or protocol_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains two usage modes: without stream_spec returns all streams, with stream_spec returns per-stream statistics. It provides a format example for stream_spec. However, it lacks guidance on when to choose this tool over alternatives, such as multicast_streams for multicast RTP, or voip_calls for call-level analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flow sequence diagram data for visualising packet exchanges.
Returns time-ordered node and flow entries suitable for rendering a sequence diagram (equivalent to Wireshark's Flow Graph window). any — all flows tcp — TCP flows (handshakes, data, teardowns) icmp — ICMP echo request/reply flows icmpv6 — ICMPv6 flows
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | ||
| type | No | tcp | |
| display_filter | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations available, and the description does not disclose side effects, authorization needs, or performance implications. It implies a read-only operation but lacks explicit safety guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise (two sentences plus list) and front-loaded with purpose. The list of type options is clear, but the initial sentence could be reworded for flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 0% parameter coverage, the description should detail return structure and parameter roles more fully. The brief mention of 'time-ordered node and flow entries' is insufficient for a tool producing complex data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds value by explaining the 'type' enum values (tcp, icmp, etc.). However, 'alias' and 'display_filter' are not elaborated, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool outputs sequence diagram data for visualizing packet exchanges, equivalent to Wireshark's Flow Graph. This distinguishes it from sibling tools like iograph or protocol_hierarchy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over siblings (e.g., iograph, packet_detail). The type parameter is hinted but not explicitly recommended.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all types available in this sharkd session: tap identifiers, follow protocols, column fields, and stats tree entries.
Useful for discovering valid values before calling conversations, endpoints, follow_stream, or protocol_hierarchy.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates a read-only listing operation, but lacks details on side effects, authorization needs, or rate limits. However, the basic behavior is adequately conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero fluff. Each sentence adds value: first states what it lists, second gives usage guidance. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides good usage context among sibling tools, but fails to document the single required parameter. Without output schema, return format is also unspecified. Adequate for basic understanding but incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'alias' with 0% description coverage. The description does not explain what 'alias' means or how it affects the results, leaving the agent with insufficient information to construct valid input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all available types in the sharkd session, enumerating specific categories (tap identifiers, follow protocols, etc.). It distinguishes this from sibling tools by indicating it's a discovery tool for valid values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: before calling conversations, endpoints, follow_stream, or protocol_hierarchy. This provides clear guidance on context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Service response time statistics — min/max/avg latency per request type.
Measures the elapsed time between a protocol request and its response. Useful for detecting slow servers, network congestion, or anomalous response-time patterns in application protocols.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | ||
| protocol | Yes | ||
| display_filter | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool measures latency between request and response and returns min/max/avg statistics. However, it does not mention whether data is aggregated across time or sessions, or any side effects. It implies read-only behavior but is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences and front-loaded with the key output. It is concise without unnecessary words. Could be slightly more efficient, but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (2 required) and no output schema, the description fails to cover parameter details or return format. It is not sufficient for an agent to correctly invoke the tool without additional knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain any of the three parameters (alias, protocol, display_filter). The user cannot infer what values to provide or how they affect the results. This is a critical gap for a tool with required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides min/max/avg latency per request type and measures elapsed time between request and response. It's specific about the resource (response time statistics) and the verb (measures). However, it does not explicitly differentiate from the sibling tool 'response_time_delay'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions use cases (detecting slow servers, network congestion, anomalous patterns) but provides no guidance on when to use this tool versus alternatives like 'response_time_delay' or 'protocol_stats'. No explicit when-to-use or when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a comment on a frame for the duration of this session (non-persistent).
Pass an empty string to clear an existing comment. Useful for annotating frames during forensic analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | ||
| frame_number | Yes | ||
| comment | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals key behaviors: non-persistent session duration, how to clear comments, and the use case. However, with no annotations, it fails to disclose potential overwrite behavior, permissions, or side effects beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences and a clear note. It is front-loaded with the core action and adds only essential details, wasting no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the main points: action, persistence, clearing mechanism, and use case. It is complete enough for an agent to understand the tool's function, though parameter details are sparse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description partially explains the 'comment' parameter by noting it can be cleared with an empty string. The 'alias' and 'frame_number' parameters are not described at all, leaving ambiguity for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Set a comment on a frame for the duration of this session (non-persistent).' It specifies the verb 'set' and the resource 'comment on a frame', making the purpose immediately obvious and distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Useful for annotating frames during forensic analysis.' It also explains how to clear a comment by passing an empty string. However, it does not explicitly state when not to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a sharkd dissector preference for this session.
Changes are session-scoped and do not persist after the server restarts.
Common uses: forcing a non-standard port to decode as a specific protocol
(e.g. name="http.tcp.port", value="8080"), or enabling/disabling a
dissector option.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | ||
| name | Yes | ||
| value | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that changes are session-scoped and non-persistent. No annotations exist, so description carries the burden; it does well but could mention error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus an example, no wasted words. Information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers scope, persistence, and common use. Missing return value or success indication, but acceptable for a mutation tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an example clarifying name and value, but does not explain the alias parameter. Input schema has 100% required fields with no descriptions, so baseline is 3 with partial added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets a sharkd dissector preference for the session, with specific examples of usage. It distinguishes its purpose from sibling tools like get_preference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on session-scoping and common use cases, but does not explicitly address when to avoid using it or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run one or more sharkd statistics taps in a single PCAP scan.
specs — tap identifiers from server_info, e.g.
["expert", "conv:TCP", "stat:dns", "srt:smb"]
filter — global display filter applied to all taps (sharkd supports
only one filter per tap call; per-tap filters are iograph-only)
skip / limit — pagination applied to each tap's flat list result
Up to 16 specs per call (sharkd limit). Results are cached after the
first scan; paginated follow-up calls are served from memory.
Use server_info to discover all valid tap identifiers.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | ||
| specs | Yes | ||
| filter | No | ||
| skip | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses caching behavior, pagination, and the sharkd limit of 16 specs. However, it does not mention whether the operation is read-only or has side effects, though reading pcap data is likely safe. The caching detail is a positive addition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, using a short introductory sentence followed by clear bullet-point explanations for each parameter. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 parameter semantics, limits, caching, and references server_info. It does not describe the return format, but the output schema is absent, so the description is fairly complete for using the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds significant meaning: it explains the format of specs (with examples), the use of filter (with limitation), and pagination parameters. The alias parameter is required but not described, which is a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs one or more sharkd statistics taps in a single PCAP scan. It identifies the specific resource (sharkd statistics taps) and action (run), effectively distinguishing it from sibling tools like server_info or iograph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage details: limits (up to 16 specs), pagination (skip/limit), and references server_info for tap discovery. It notes that per-tap filters are only for iograph, but does not explicitly state when to prefer this tool over alternatives, though it is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Terminate the sharkd session for alias and free its memory.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions freeing memory, indicating a destructive action, but lacks details on side effects, idempotency, or error handling. With no annotations, this is only partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no extraneous words; information is front-loaded and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no parameter descriptions, and a simple task, the description still fails to explain what a 'sharkd session' is or how the alias is used, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description only restates the parameter name 'alias' without explaining its meaning, format, or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the action 'terminate the sharkd session' and the resource 'alias', clearly distinguishing from sibling tools like load_pcap and list_pcaps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a display-filter expression and/or a field name.
filter — Wireshark display filter (e.g. tcp.port == 443).
field — fully qualified field name (e.g. http.request.method).
Returns {"status":"OK"} on success or an error object.
At least one of filter or field must be provided.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | ||
| filter | No | ||
| field | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It discloses the return format on success ('status:OK') and on failure (error object). No side effects or other traits are needed for a validation-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five lines, front-loaded with the main purpose, and uses bullet-like formatting for parameters. Every sentence adds value with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, two out of three parameters, and the return value. Given no output schema, this is adequate but incomplete due to the missing 'alias' explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain all three parameters. It explains 'filter' and 'field' with examples, but the required 'alias' parameter is not mentioned at all, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it validates a display-filter expression and/or a field name. The verb 'validate' and resource 'display-filter expression/field name' are specific. No sibling tool performs validation, so it is well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'At least one of filter or field must be provided', which is a usage guideline. However, it does not specify when to use this tool versus alternatives, though no direct sibling exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
VoIP call list with state, duration, and participant addresses.
Detects SIP, H.323, MGCP, and SKINNY calls in the capture and reconstructs the call flow from signalling messages.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | ||
| display_filter | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry the burden. It discloses that it detects various protocols and reconstructs call flow, but doesn't mention side effects (likely read-only) or output format. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key output fields. Concise, though the second sentence is slightly technical. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should provide more context about return values and prerequisites. It fails to explain parameters or what the output looks like, making it incomplete for a 2-param tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 2 parameters (alias required, display_filter optional) with 0% description coverage. The description does not explain either parameter, leaving the agent with no semantic guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists VoIP calls with state, duration, and participant addresses, and mentions specific protocols (SIP, H.323, MGCP, SKINNY) and call flow reconstruction. However, it does not differentiate it from sibling tools like rtp_streams or endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It implies it's for VoIP analysis but doesn't specify scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct operation on packet capture data, such as loading, listing, extracting fields, following streams, or computing statistics. Overlaps like io_stats and iograph are clarified by descriptions (one simple counts, the other multi-line graphs). No two tools appear to do the same thing.
Tool names mix verb_noun patterns (list_pcaps, load_pcap, set_preference) with noun-only names (protocol_hierarchy, voip_calls, rtp_streams). While the naming is readable and uses snake_case consistently, the lack of a uniform verb prefix creates inconsistency.
30 tools cover a broad range of PCAP analysis features (loading, filtering, statistics, protocol details, export). This is slightly above the typical 15-20 but justified given the extensive functionality of Wireshark/sharkd. No obvious bloat.
The tool surface is comprehensive for analyzing packet captures: it covers file management, packet listing, field extraction, stream reassembly, export objects, multiple statistics taps, protocol-specific analysis, preferences, and validation. Missing features like live capture or saving are outside the server's stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Provide detailed Pokémon data and information through a standardized MCP interface. Enable LLMs an…
File uploads for AI agents. Upload, list, and manage files. No signup required.
The all-in-one data stack for agents. Upload files, run SQL, evolve tables, and render charts.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/weirdmachine64/SharkMCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
