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., "@steganography-mcp Analyze image.jpg for steganographic content"
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.
Steganography is the art of hiding data in plain sight — inside images, audio files, documents, and even Unicode text. It is used in CTF competitions, digital forensics investigations, covert communication channels, and malware payloads. Detecting it requires a combination of statistical analysis, format-specific parsing, entropy measurement, and domain expertise.
Traditional steganography analysis workflow:
detect image stego -> zsteg + stegsolve (2 tools, Ruby + Java)
chi-square analysis -> custom Python script
RS analysis -> custom MATLAB/Python code
JPEG DCT forensics -> stegdetect (abandoned C tool from 2004)
extract LSB data -> zsteg + steghide + openstego (3 tools)
audio steganography -> Audacity manual + custom scripts
zero-width text detection -> web-based tools + manual inspection
file forensics / binwalk -> binwalk + foremost + xxd (3 tools)
EXIF metadata -> exiftool (Perl dependency)
encoding detection -> CyberChef web UI + manual guessing
─────────────────────────────────
Total: 10+ tools, 5+ languages, hours of manual correlationsteganography-mcp gives your AI agent 128 tools across 17 categories via the Model Context Protocol. The agent performs image steganalysis, advanced JPEG forensics (F5/JSteg/OutGuess/PVD detection), BPCS analysis, video & GIF steganography, network covert channel detection, MP3 stego, spread spectrum watermark detection, archive stego, QR code analysis, audio analysis, text steganography detection, file forensics, document analysis, and encoding identification — all in a single conversation, all running 100% locally with zero dependencies on external services.
With steganography-mcp:
You: "Analyze this CTF challenge image for hidden data"
Agent: -> img_detect: Chi-square p=0.0001 (LSB embedding detected),
RS analysis estimates 42% embedding rate, entropy anomaly
in lower-right quadrant
-> img_lsb_extract: Extracted 847 bytes from RGB LSBs
-> crypto_detect: Extracted data is Base64-encoded
-> crypto_decode: Decoded to "FLAG{hidden_in_plain_sight_2024}"
-> img_known_tools: Signature match for OpenStego
"The image contains LSB steganography embedded with OpenStego.
Chi-square test confirms LSB replacement in all three RGB
channels with 42% embedding rate. The hidden payload is
Base64-encoded and decodes to the flag:
FLAG{hidden_in_plain_sight_2024}"Related MCP server: osint-mcp-server
Most steganography tools are single-purpose utilities. steganography-mcp gives your AI agent the ability to reason across all steganography techniques simultaneously.
npx -y steganography-mcpAll 128 tools work immediately. No API keys. No configuration. 100% offline.
bunx steganography-mcpgit clone https://github.com/badchars/steganography-mcp.git
cd steganography-mcp
bun install# With npx
claude mcp add steganography -- npx -y steganography-mcp
# With local clone
claude mcp add steganography -- bun run /path/to/steganography-mcp/src/index.tsAdd to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"steganography": {
"command": "npx",
"args": ["-y", "steganography-mcp"]
}
}
}Same JSON config format. Point the command to npx -y steganography-mcp or your local installation path.
You: "Check this image for hidden data"That's it. The agent runs chi-square analysis, RS analysis, entropy mapping, metadata extraction, appended data detection, and tool signature scanning — automatically.
You: "Solve this CTF steganography challenge — the image is at challenge.png"
Agent: -> img_detect: Chi-square steganalysis detects LSB embedding
(p=0.00012), RS analysis estimates 38% embedding rate,
entropy anomaly at blocks (12,4)-(15,8)
-> img_lsb_extract: Extracted 1,247 bytes from RGB channel LSBs
-> crypto_detect: Data matches Base64 pattern (confidence: 0.95)
-> crypto_decode: "Q1RGe3N0M2cwX21hc3Rlcn0=" -> "CTF{st3g0_master}"
-> img_known_tools: OpenStego signature detected in PNG chunks
"Found the flag: CTF{st3g0_master}
The image uses LSB steganography embedded by OpenStego.
The payload was Base64-encoded in the RGB least significant
bits with a 38% embedding rate."You: "Analyze suspect.png and suspect.wav for covert communication"
Agent: -> img_detect: No LSB stego detected, but appended data found
(12,847 bytes after PNG IEND marker)
-> file_identify: Appended data starts with ZIP signature (PK)
-> img_metadata: PNG tEXt chunk contains unusual key "comm"
with Base64 value
-> audio_detect: WAV file has LSB chi-square anomaly (p=0.003)
-> audio_silence: 3 silent sections with active LSBs detected
-> audio_lsb_extract: Extracted 2,048 bytes of hidden data
"Both files contain hidden data:
1. suspect.png has a ZIP archive appended after the PNG EOF
marker, plus a Base64-encoded message in metadata
2. suspect.wav contains LSB steganography, specifically in
silent sections — a strong indicator of intentional hiding.
Recommend extracting the ZIP and analyzing WAV payload."You: "This email looks normal but might have hidden text"
Agent: -> text_detect: 847 zero-width characters detected between
visible characters
-> text_zwc_detect: ZWSP (342), ZWNJ (505) found at 127
positions throughout the text
-> text_zwc_extract: Binary decoding yields "EXFIL-ROUTE-7"
-> text_invisible_scan: 3 additional invisible Unicode chars
(U+2060, U+FEFF) found in header section
"The email contains a hidden message encoded with zero-width
characters: 'EXFIL-ROUTE-7'. 847 invisible characters are
dispersed throughout the visible text using ZWSP/ZWNJ binary
encoding. Additionally, 3 Word Joiner and BOM characters
were found in the header — likely metadata artifacts."You: "Is this JPEG image authentic or has it been tampered with?"
Agent: -> jpeg_structure: 14 markers parsed, normal JFIF structure
-> jpeg_double_compression: Double compression DETECTED —
blocking artifact score 0.73, quantization anomaly ratio 0.81
-> jpeg_quantization: Quality ~75 (luminance), but residual
patterns suggest original was quality ~92
-> jpeg_exif_deep: EXIF says "iPhone 14 Pro" but Software
field says "Adobe Photoshop 25.0"
-> jpeg_thumbnail_compare: Thumbnail dimensions do NOT match
main image (thumbnail: 4032x3024, main: 2048x1536)
"This JPEG has been tampered with. Evidence:
1. Double compression detected — the image was decoded and
re-encoded at lower quality (original ~92, current ~75)
2. EXIF claims iPhone 14 Pro but software field reveals
Photoshop editing
3. Thumbnail is from the original 4032x3024 capture but
the main image was resized to 2048x1536
All three findings independently confirm post-capture
modification."Category | Tools | Description |
14 | LSB detection, chi-square, RS analysis, entropy mapping, bit planes, histogram, metadata, tool signatures | |
7 | DCT histogram, double compression, quantization tables, deep EXIF, thumbnail forensics, comment analysis | |
7 | F5, JSteg, OutGuess, PVD detection, sliding window chi-square, crop-recalibrate steganalysis, tool compatibility | |
7 | WAV LSB detection, spectrum analysis, silence region analysis, echo hiding, metadata extraction | |
10 | Zero-width chars, whitespace encoding, invisible Unicode, homoglyphs, acrostics, Unicode analysis | |
10 | Magic bytes, polyglot detection, embedded files, appended data, entropy, hex dump, strings, headers | |
5 | PDF hidden content, PDF metadata, PDF streams, HTML hidden content, XML metadata | |
7 | Encoding detection, multi-format decoder, frequency analysis, entropy, XOR brute-force, hash ID, cipher patterns | |
8 | AVI frame LSB, inter-frame analysis, frame comparison, metadata, structure, EOF data | |
8 | Palette LSB, LZW sub-block entropy, comment extensions, application extensions, frame analysis | |
8 | PCAP covert channels, IP/TCP header analysis, ICMP payloads, DNS tunneling, HTTP headers, timing | |
7 | ID3 hidden data, frame analysis, padding manipulation, sample analysis, metadata, structure | |
5 | DFT magnitude spectrum, autocorrelation, watermark detection, noise floor analysis, patchwork detection | |
5 | Bit-plane complexity segmentation, complexity mapping, threshold analysis, data extraction, capacity estimation | |
7 | ZIP slack spaces, extra fields, comments, polyglot detection, structure analysis, metadata | |
7 | EOF injection, metadata injection, whitespace encoding, null cipher, polyglot creation, comment injection, palette embedding | |
6 | QR stego detection, structure analysis, ECC capacity, module analysis, data extraction, comparison |
Tool | Description |
| Auto-detect steganography in an image. Runs chi-square, RS analysis, entropy, metadata, appended data, and tool signature checks. Returns a comprehensive JSON report |
| Statistical LSB steganography detection. Runs chi-square and sample pair analysis on each color channel independently |
| Extract hidden data from image LSBs. Extracts bits from specified channels and bit plane, attempts UTF-8 decode, and shows hex dump |
| Embed a message into an image using LSB steganography. Reads a PNG file, embeds the message into the least significant bits, and writes a new PNG file |
| Extract and visualize a specific bit plane from an image channel. Shows dimensions, percentage of 1-bits, and an ASCII art preview |
| Chi-square steganalysis attack on each color channel independently. Detects LSB replacement by testing whether adjacent pixel value pairs are equalized |
| RS (Regular-Singular) steganalysis using the Fridrich-Goljan-Du method. Analyzes pixel groups to estimate LSB embedding rate per channel |
| Generate a pixel value histogram with anomaly detection. Detects Pairs-of-Values (PoV) anomalies that indicate LSB steganography |
| Per-block entropy analysis of an image. Splits the image into blocks and calculates Shannon entropy per block, flagging high-entropy regions |
| Deep metadata extraction from an image. For PNG: text chunks, chunk list, IHDR info. For JPEG: EXIF, comments, quantization tables, marker list |
| Detect and extract data appended after the image EOF marker. Checks for hidden data past PNG IEND, JPEG EOI, or BMP file size boundary |
| Pixel-by-pixel comparison of two images. Reports identical/different pixel counts, max difference, and which channels are affected |
| Per-channel statistical analysis for R, G, B, and A channels. Reports mean, standard deviation, entropy, min, max, and unique value count |
| Scan image file bytes for known steganography tool signatures. Checks against a database of patterns from OpenStego, Steghide, JSteg, F5, and others |
Tool | Description |
| Parse JPEG markers/segments with offsets and sizes. Shows internal structure including all markers, positions, and segment lengths |
| DCT coefficient distribution analysis for steganography detection. Analyzes Y-channel pixel value distribution and SOS entropy data to detect anomalies caused by JSteg, F5, and OutGuess |
| Detect double JPEG compression artifacts. Identifies characteristic blocking artifacts and quantization table anomalies — a common indicator of image tampering or stego embedding |
| Quantization table analysis with quality estimation. Displays all quantization tables in 8x8 grid format and estimates the JPEG quality factor |
| Deep EXIF analysis including GPS coordinates, timestamps, software info, thumbnails, maker notes, and all IFD entries. Flags forensically interesting fields |
| Compare EXIF thumbnail against the main JPEG image. Dimension or content mismatch indicates post-capture modification — a common forensic artifact |
| Extract and analyze JPEG COM (comment) markers. Checks for hidden data patterns, unusually large comments, and high-entropy content |
Tool | Description |
| Auto-detect audio steganography in a WAV file. Runs LSB chi-square, entropy analysis, metadata inspection, and checks for appended data |
| PCM sample LSB statistical analysis. Performs chi-square test on LSBs grouped by value pairs to detect LSB replacement steganography |
| Extract LSB data from audio samples. Reads the least significant bit of each PCM sample and attempts to decode hidden data |
| Spectral analysis for hidden signals in WAV audio. Analyzes sample value distribution, zero-crossing rate, RMS energy per block, and detects anomalous quiet sections |
| Extract metadata from a WAV file including RIFF INFO chunks, format details, and all chunk information |
| Analyze silent sections in WAV audio for hidden data. Finds near-zero sample regions and checks their LSBs — silent sections with active LSBs are a strong stego indicator |
| Echo hiding detection via autocorrelation analysis. Computes normalized autocorrelation at common echo delays. Regular echo patterns indicate steganographic echo hiding |
Tool | Description |
| Auto-detect text steganography. Checks for zero-width characters, whitespace encoding, invisible Unicode, homoglyphs, and unusual patterns |
| Detect zero-width characters (ZWSP, ZWNJ, ZWJ, BOM) in text. Reports positions, counts, and potential encoded message length |
| Decode a zero-width character encoded message. Extracts ZWC chars and decodes binary: ZWSP=0, ZWNJ=1 (attempts both polarities) |
| Embed a secret message into cover text using zero-width characters. Encodes message to binary and maps bits to ZWSP(0)/ZWNJ(1) |
| Detect whitespace encoding in text. Checks each line for trailing whitespace patterns where space=0 and tab=1 might encode binary data |
| Extract a whitespace-encoded message from text. Reads trailing whitespace from each line and decodes space=0/tab=1 binary encoding |
| Scan text for ALL invisible Unicode characters. Checks every character against the full invisible character database and reports positions and names |
| Detect Unicode homoglyph substitutions in text. Identifies non-ASCII characters that visually resemble ASCII letters (Cyrillic a vs Latin a, etc.) |
| Full Unicode character distribution analysis. Categorizes all characters by script block, performs entropy analysis, and detects suspicious script mixing |
| Detect first-letter, first-word, last-letter, last-word, or nth-character patterns (acrostic messages) hidden across lines of text |
Tool | Description |
| File type identification via magic bytes. Reads the file header and matches against a comprehensive database of known file signatures. Checks for extension mismatch |
| Detect polyglot files valid as two or more formats simultaneously. Checks for multiple valid file signatures at different offsets (PDF+ZIP, PNG+PDF, etc.) |
| Scan for embedded files within a binary, similar to binwalk. Searches for known magic byte signatures at every offset to discover hidden or appended files |
| Detect data appended after a file's format-specific EOF marker. Supports PNG (IEND), JPEG (FFD9), BMP, ZIP (EOCD), and PDF (%%EOF) |
| Section-by-section entropy analysis. Calculates Shannon entropy per block and overall, flagging anomalous high-entropy sections |
| ASCII entropy visualization of a file. Renders a text-based bar chart showing entropy levels across the file for visual anomaly detection |
| Extract printable and Unicode strings from binary files. Scans for runs of printable characters and reports them with file offsets. Supports ASCII, UTF-8, UTF-16 |
| Hex dump with ASCII sidebar display. Traditional hex editor format with offset addresses, hex bytes, and printable ASCII representation |
| Deep header and structure analysis for known formats. Parses PNG IHDR, JPEG SOF, BMP info header, ZIP local file headers, and PDF version/metadata |
| Binary diff between two files. Byte-by-byte comparison reporting differences with offsets, percentage identical, and LSB-only difference detection for stego analysis |
Tool | Description |
| Hidden PDF content detection. Scans for JavaScript, auto-actions, OpenAction, hidden annotations, invisible text, embedded files, and other covert content |
| PDF metadata extraction. Parses the /Info dictionary and XMP metadata blocks for forensic attribution and document provenance analysis |
| PDF stream analysis. Locates all stream/endstream blocks, attempts zlib decompression, and reports sizes and entropy for finding hidden data |
| Hidden HTML content detection. Scans for comments, display:none elements, data-* attributes, hidden inputs, base64 content, zero-size elements, and invisible text |
| XML and Office document metadata extraction. Parses Dublin Core, Microsoft Office properties, processing instructions, and other metadata fields |
Tool | Description |
| Auto-detect encoding type of an input string. Tests against all known patterns (Base64, hex, binary, morse, URL encoding, HTML entities, etc.) and returns matches sorted by confidence |
| Multi-format decoder supporting Base64, hex, binary, decimal, octal, URL encoding, ROT13, Base32, Morse code, and HTML entities. Auto mode detects encoding first |
| Character frequency analysis for cryptanalysis. Counts character occurrences, compares to standard English frequency (ETAOINSHRDLU), and calculates Index of Coincidence |
| Shannon entropy calculation and classification for strings. Computes character-level and byte-level entropy, classifying into categories from repeated data to encrypted/random |
| XOR key brute-force for single-byte and multi-byte keys. Tries all 256 single-byte keys and scores by English text probability. Uses IC for multi-byte key length estimation |
| Hash type identification. Matches input against known hash patterns by length and format (MD5, SHA-1, SHA-256, SHA-512, bcrypt, CRC32, NTLM, etc.) |
| Known cipher and encoding pattern detection. Analyzes text for Caesar cipher, substitution cipher, Vigenere, rail fence transposition, Atbash, and reversed text |
Tool | Description |
| F5 steganography detection. Analyzes DCT coefficient histogram for shrinkage at zero and asymmetric distribution around zero |
| JSteg detection. Chi-square test on coefficient value pairs, zero AC coefficient preservation analysis |
| OutGuess detection. First-order histogram smoothness, second-order statistics, inter-block correlation analysis |
| Pixel Value Differencing detection. Horizontal/vertical difference histograms, staircase artifacts at PVD range boundaries |
| Sliding window chi-square analysis. Per-window p-values to detect embedding start/end points and estimate message length |
| Crop-recalibrate steganalysis. Compares original vs cropped image statistics to reveal DCT modifications |
| JPEG stego tool compatibility check. Analyzes markers, quality, encoding type to determine which tools (JSteg, F5, OutGuess, steghide, JPHS) could have been used |
Tool | Description |
| Auto-detect steganography in AVI files. Runs LSB analysis on frames, checks for appended data, analyzes frame size variance |
| LSB analysis of a specific video frame. Extracts raw pixel data, checks LSB balance/distribution and entropy |
| Extract LSB bits from specified frames. Assembles into byte stream with hex dump and text preview |
| Compare two frames byte-by-byte. Reports MSE, PSNR, max difference, and LSB-only modification detection |
| Analyze idx1 index entries for keyframe vs delta frame distribution, flag histogram, and size statistics |
| Extract AVI metadata: dimensions, FPS, codec, stream details, duration, audio presence |
| Recursively visualize the RIFF/LIST chunk tree with fourCC codes, offsets, and sizes |
| Detect and analyze data appended after the RIFF container boundary |
Tool | Description |
| Auto-detect GIF steganography. Analyzes color table LSBs, appended data, comment extensions, animation anomalies |
| Palette analysis: sort order, duplicates, unused entries, luminance distribution, LSB-differing adjacent pairs |
| Extract LSB from each R/G/B channel of the global color table. Per-channel balance and chi-square tests |
| Multi-frame animation analysis: per-frame size, delay times, disposal methods, local color tables |
| Extract all comment extensions with text content, entropy, printable ratio, and hex dump |
| Application extension analysis. Parses NETSCAPE loop counts, detects non-standard extensions |
| LZW sub-block entropy analysis per frame. Detects anomalous sub-block sizes and cross-frame entropy outliers |
| Visualize complete GIF block structure: header, color tables, extensions, image descriptors, trailer |
Tool | Description |
| Auto-detect network steganography in PCAP files. Runs IP covert field, ICMP payload, DNS tunneling, and timing analysis |
| IP header covert field analysis. TTL patterns, IP identification entropy, TOS/DSCP usage |
| TCP seq/ack number analysis. ISN analysis, per-flow sequence increments, TCP options, window size variability |
| ICMP echo payload analysis. Per-packet entropy, printable content ratio, payload size anomalies |
| DNS tunneling detection. Subdomain length distribution, per-label entropy, TXT record usage, query frequency |
| HTTP header covert channel analysis. Custom headers, X-header entropy, cookie value entropy |
| Inter-packet timing analysis. Interval statistics, timing covert channel detection via binary splitting |
| PCAP statistics summary. Protocol distribution, top IP pairs, port usage, throughput |
Tool | Description |
| Auto-detect MP3 steganography. Checks ID3 padding, PRIV frames, pre-audio gaps, trailing data, bitrate anomalies |
| Frame header analysis. Bitrate distribution, padding bit entropy, frame size statistics, channel mode consistency |
| ID3v1/v2 hidden data analysis. APIC, PRIV, GEOB frames, unknown frame IDs, padding content inspection |
| Bit reservoir/padding manipulation detection. Pre-audio gaps, inter-frame gaps with per-gap entropy |
| Statistical analysis of frame sizes. Distribution histogram, entropy of sizes and deltas, outlier detection |
| Full MP3 metadata extraction. Audio properties, ID3v2 frames with decoded text, file structure layout |
| Frame structure visualization. Per-frame table, bitrate map, and padding bit map |
Tool | Description |
| DFT magnitude spectrum analysis. Spectral flatness, frequency band energy, dominant frequencies for hidden signal detection |
| Autocorrelation-based detection. Finds periodic embedding patterns, distinguishes natural peaks from suspicious ones |
| Statistical watermark detection. Block-based pixel variance comparison, checkerboard patterns, quadrant uniformity |
| Noise floor embedding detection. Laplacian noise estimation, smooth vs textured region noise comparison |
| Patchwork watermark detection. Multi-seed PRNG group splitting, statistical hypothesis testing |
Tool | Description |
| Auto-detect BPCS embedding. Complexity analysis across all 24 bit planes (8 planes x 3 channels), MSB/LSB trend analysis |
| Full complexity map with ASCII spatial visualization and distribution histograms for all 8 bit planes |
| Threshold sweep analysis from 0.05 to 0.95. Finds optimal BPCS boundary and suspicious complexity patterns |
| Extract data from complex regions. Gathers bits above threshold in raster-scan order, analyzes for structure |
| Estimate BPCS embedding capacity across all channels and planes, accounting for conjugation map overhead |
Tool | Description |
| Auto-detect archive steganography. Checks slack spaces, prepended/appended data, unusual extra fields, comments |
| ZIP entry structure analysis. Lists all local file headers with offsets, sizes, compression methods, CRC-32 |
| Parse extra fields from local and central directory entries. Flags unknown header IDs as potential hiding spots |
| Extract archive-level and per-file comments with entropy analysis and hex dumps |
| Identify gaps between ZIP entries with size, entropy, printable ratio, and hex dumps |
| Detect if ZIP has prepended/appended data valid as another format (PDF, PNG, ELF, PE, etc.) |
| Summary of file count, compression ratios, timestamps, version info, encryption flags |
Tool | Description |
| Append data after a file's EOF marker. Takes file_path, data, and output_path |
| Inject data into metadata fields. PNG tEXt chunks, JPEG COM segments, generic append |
| Encode data in trailing whitespace (space=0, tab=1) on text file lines |
| Generate null cipher text. First-letter mode or nth-word arrangement |
| Concatenate two files to create a polyglot valid as both formats |
| Inject into format-specific comment fields (PNG tEXt, JPEG COM, GIF Comment Extension) |
| Embed data in palette LSBs for indexed PNG (PLTE) and GIF (Global Color Table) |
Tool | Description |
| Detect steganography in QR code images. Pixel distribution bimodality, LSB randomization, non-pure module values |
| QR structure analysis. Finder patterns, version estimation, module size, grid dimensions |
| Error correction capacity analysis. ECC levels L/M/Q/H, steganographic capacity from sacrificing ECC codewords |
| Per-module pixel variance analysis. Clean QR codes should have zero intra-module variance |
| Extract data region pixels excluding function patterns. Module values, binary string, entropy statistics |
| Compare two QR code images. Data region vs function pattern differences, LSB-only modification detection |
# Show help
npx -y steganography-mcp --help
# List all 128 tools with descriptions
npx -y steganography-mcp --list
# Detect steganography in an image
npx -y steganography-mcp --tool img_detect '{"file_path":"challenge.png"}'
# Extract hidden message from LSBs
npx -y steganography-mcp --tool img_lsb_extract '{"file_path":"stego.png"}'
# Chi-square steganalysis
npx -y steganography-mcp --tool img_chi_square '{"file_path":"suspect.png"}'
# RS analysis (Fridrich-Goljan-Du method)
npx -y steganography-mcp --tool img_rs_analysis '{"file_path":"suspect.png"}'
# JPEG double compression detection
npx -y steganography-mcp --tool jpeg_double_compression '{"file_path":"photo.jpg"}'
# Deep EXIF analysis
npx -y steganography-mcp --tool jpeg_exif_deep '{"file_path":"photo.jpg"}'
# Audio steganography detection
npx -y steganography-mcp --tool audio_detect '{"file_path":"message.wav"}'
# Detect zero-width character encoding
npx -y steganography-mcp --tool text_zwc_detect '{"text":"suspicious text here"}'
# Embed a hidden message with zero-width characters
npx -y steganography-mcp --tool text_zwc_embed '{"text":"cover text","message":"secret"}'
# Identify file type and detect polyglots
npx -y steganography-mcp --tool file_polyglot '{"file_path":"suspicious.pdf"}'
# Scan for embedded files (binwalk-style)
npx -y steganography-mcp --tool file_embedded '{"file_path":"mystery.bin"}'
# Entropy visualization
npx -y steganography-mcp --tool file_entropy_visual '{"file_path":"data.bin"}'
# Auto-detect encoding
npx -y steganography-mcp --tool crypto_detect '{"input":"aGVsbG8gd29ybGQ="}'
# XOR brute-force
npx -y steganography-mcp --tool crypto_xor '{"input":"4f5243484e"}'
# Detect cipher patterns
npx -y steganography-mcp --tool crypto_patterns '{"input":"Gur dhvpx oebja sbk"}'
# Video steganography detection
npx -y steganography-mcp --tool video_detect '{"file_path":"movie.avi"}'
# GIF palette LSB analysis
npx -y steganography-mcp --tool gif_palette_lsb '{"file_path":"animation.gif"}'
# Network covert channel detection
npx -y steganography-mcp --tool net_dns_tunnel '{"file_path":"capture.pcap"}'
# MP3 hidden data detection
npx -y steganography-mcp --tool mp3_detect '{"file_path":"song.mp3"}'
# F5 JPEG stego detection
npx -y steganography-mcp --tool jpegadv_f5_detect '{"file_path":"suspect.jpg"}'
# BPCS embedding detection
npx -y steganography-mcp --tool bpcs_detect '{"file_path":"image.png"}'
# Archive slack space analysis
npx -y steganography-mcp --tool archive_slack '{"file_path":"archive.zip"}'
# QR code stego detection
npx -y steganography-mcp --tool qr_detect '{"file_path":"qrcode.bmp"}'
# Spread spectrum watermark detection
npx -y steganography-mcp --tool spread_patchwork '{"file_path":"image.png"}'
# Create a polyglot file
npx -y steganography-mcp --tool create_polyglot '{"file1_path":"image.png","file2_path":"secret.zip","output_path":"polyglot.png"}'
# Using Bun (faster startup)
bunx steganography-mcp --tool img_detect '{"file_path":"image.png"}'Solve steganography challenges in capture-the-flag competitions. The AI agent can systematically apply all detection techniques — LSB analysis, metadata inspection, appended data, encoding detection, and cipher identification — to find hidden flags in images, audio files, documents, and text.
Detect covert communication channels in forensic investigations. Analyze suspect files for hidden data using statistical steganalysis (chi-square, RS analysis), check for data appended after EOF markers, scan for embedded files, and identify steganography tool signatures.
Analyze steganography tools and techniques. Compare original and stego images pixel-by-pixel, study DCT coefficient distributions in JPEG stego, measure entropy changes from embedding, and reverse-engineer encoding schemes.
Learn how steganography techniques work. Embed and extract LSB messages, encode text with zero-width characters, visualize bit planes and entropy maps, analyze file structures with hex dumps, and study cipher patterns with frequency analysis.
During incident response, check documents and images for hidden exfiltration channels. Scan PDFs for hidden JavaScript and embedded files, detect zero-width character encoding in emails, identify polyglot files, and analyze suspicious encodings.
src/
index.ts # CLI entrypoint (--help, --list, --tool, stdio server)
protocol/
mcp-server.ts # MCP server setup (stdio transport)
tools.ts # Tool registry — all 128 tools assembled here
types/
index.ts # Shared types (ToolDef, ToolContext, ToolResult)
utils/
binary.ts # Binary file reading, hex dump, format detection
stats.ts # Shannon entropy, chi-square, DFT, autocorrelation, BPCS complexity, patchwork test
cache.ts # TTL cache
png-parser.ts # Pure TS PNG parser (IHDR, chunks, pixel data)
jpeg-parser.ts # Pure TS JPEG parser (markers, EXIF, quantization, DCT coefficients)
wav-parser.ts # Pure TS WAV parser (RIFF chunks, PCM samples)
bmp-parser.ts # Pure TS BMP parser (header, pixel data)
avi-parser.ts # Pure TS AVI/RIFF parser (chunks, streams, idx1, frames)
gif-parser.ts # Pure TS GIF89a parser (color tables, extensions, LZW blocks)
pcap-parser.ts # Pure TS PCAP parser (IP/TCP/UDP/ICMP/DNS/HTTP)
mp3-parser.ts # Pure TS MP3 parser (ID3v1/v2, frame headers)
zip-parser.ts # Pure TS ZIP parser (local headers, central directory, extra fields)
image/ # Image Steganalysis tools (14)
jpeg/ # JPEG Analysis tools (7)
jpegadv/ # Advanced JPEG tools (7) — F5, JSteg, OutGuess, PVD
audio/ # Audio Steganalysis tools (7)
text/ # Text & Unicode tools (10)
file/ # File Forensics tools (10)
document/ # Document Analysis tools (5)
crypto/ # Encoding & Crypto tools (7)
video/ # Video Steganography tools (8) — AVI frame analysis
gif/ # GIF Steganography tools (8) — palette, LZW, animation
network/ # Network Steganography tools (8) — PCAP covert channels
mp3/ # MP3 Steganography tools (7) — ID3, padding, frames
spread/ # Spread Spectrum tools (5) — DFT, watermark, patchwork
bpcs/ # BPCS Analysis tools (5) — bit-plane complexity
archive/ # Archive Steganography tools (7) — ZIP slack, extra fields
create/ # Create & Embed tools (7) — EOF inject, polyglot, palette
qrcode/ # QR Code Steganography tools (6) — ECC, modules, compare
data/
encoding-patterns.ts # Encoding regex patterns + decoders
magic-bytes.ts # File signature database (100+ formats)
stego-signatures.ts # Known steganography tool signatures
unicode-invisible.ts # Invisible Unicode character databaseDesign decisions:
4 dependencies, nothing else — @modelcontextprotocol/sdk for the MCP protocol, zod for input validation, pngjs for PNG pixel access, jpeg-js for JPEG decoding. No bloated dependency tree. No native modules. No C bindings. No Python. No Java.
100% offline — Every tool runs entirely locally. No HTTP requests. No API calls. No telemetry. No cloud dependencies. Your files never leave your machine.
Pure TypeScript statistical analysis — Chi-square test, RS analysis (Fridrich-Goljan-Du), Sample Pair Analysis, Shannon entropy, DFT, autocorrelation, BPCS border complexity, patchwork test, Index of Coincidence, and frequency analysis are all implemented in pure TypeScript. No external math libraries.
11 custom format parsers — PNG, JPEG, WAV, BMP, AVI/RIFF, GIF89a, PCAP, MP3/ID3, and ZIP are parsed with zero external dependencies using the utils/ parsers. This allows deep format-specific analysis that general-purpose libraries cannot provide.
17 providers, 1 server — Each analysis category is an independent module. The AI agent picks which tools to use based on the investigation context.
Clean ToolDef pattern — Every tool follows the same { name, description, schema, execute } pattern. Adding a new tool is a single object in the appropriate module.
Zod validation on every field — Every schema field has .describe() for AI agent context. Invalid inputs are caught before execution with clear error messages.
Project | Domain | Tools |
Browser-based security testing | 39 tools | |
Cloud security (AWS/Azure/GCP) | 38 tools | |
GitHub security posture | 39 tools | |
Vulnerability intelligence | 23 tools | |
OSINT & reconnaissance | 37 tools | |
Dark web & threat intelligence | 66 tools | |
DNS security intelligence | 103 tools | |
steganography-mcp | Steganography analysis | 128 tools |
Contributions are welcome. See CONTRIBUTING.md for guidelines.
Extract archive-level and per-file comments from a ZIP archive. Comments are a common steganographic hiding spot as they can contain arbitrary data without affecting archive functionality.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to ZIP archive |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains that comments can contain arbitrary data without affecting archive functionality (implying non-destructiveness), but does not explicitly state read-only behavior, permissions, or other 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?
Two concise sentences that front-load the purpose and provide context. No superfluous wording.
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?
Adequate for a simple extraction tool with one parameter and no output schema. The context about steganographic significance adds value, though the output format is not described.
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 100% for the single parameter. The description adds no additional semantic meaning beyond what the schema already provides, achieving baseline 3.
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?
Clearly states the tool extracts archive-level and per-file comments from ZIP archives, with a specific verb and resource. Distinguishes itself from sibling tools by targeting comments as a steganographic hiding spot.
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 when-to-use or when-not-to-use guidance. The mention of steganographic hiding spots implies a use case, but there is no comparison to alternatives or guidance on prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Auto-detect steganography in ZIP archives. Checks for slack spaces between entries, prepended data before the first local header, appended data after the end-of-central-directory record, unusual extra fields, and file/archive comments that may conceal hidden data.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to ZIP archive |
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 thoroughly discloses what the tool checks (slack spaces, prepended data, appended data, extra fields, comments), giving a clear understanding of its behavior. It implies read-only detection.
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 no wasted words, efficiently listing all detection methods. It is well-structured 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?
Given the tool's complexity (multiple detection techniques), the description fully covers what it does. With one parameter and no output schema, no further detail is necessary.
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 100% for the single parameter, but the description adds contextual value by explaining that the tool analyzes the archive for hidden data, helping the agent understand the parameter's role in a broader task.
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 auto-detects steganography in ZIP archives and lists specific techniques, distinguishing it from siblings that focus on individual aspects like comments or extra fields.
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?
While it doesn't explicitly state when to use this vs siblings, the description's comprehensive list of checks implies it's for a broad scan, and the sibling tools are more specific. This provides good context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ZIP extra field analysis. Parses and describes each extra field in every entry of the archive (both local file headers and central directory entries). Extra fields can hide arbitrary data using custom or unknown header IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to ZIP archive |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. It describes the tool as analytical (parsing and describing), implying non-destructive behavior, but does not explicitly state read-only or safety aspects.
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, front-loading the main purpose and adding necessary detail without 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?
While the input is clear, the output format is not described. For a simple analysis tool, this is a gap. The description adequately covers inputs and operations but lacks output details.
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 100% for the single parameter file_path, and the tool description adds no additional information beyond what the schema provides.
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: parsing and describing extra fields in ZIP archives. It distinguishes from siblings like archive_comment and archive_structure by focusing on extra fields.
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 the use case (hiding arbitrary data) but does not explicitly state when to use this tool over alternatives. It lacks exclusions or explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Archive metadata summary. Reports file count, total compressed and uncompressed sizes, overall compression ratio, per-entry compression ratios, timestamps, version info, and encryption flags. Provides a high-level overview of the archive.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to ZIP archive |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It lists the information reported but does not explicitly state it is read-only, nor does it describe potential side effects (likely none). It lacks details on permissions or 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?
The description is concise with two sentences, front-loading the purpose. It avoids unnecessary elaboration but could be slightly more 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 simple tool (1 required param, no output schema), the description is adequate but does not cover potential errors or return format. However, for a metadata report tool, it provides the key information.
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 only parameter, file_path, is fully described in the schema as 'Path to ZIP archive'. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
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 reports a metadata summary including specific details (file count, sizes, compression ratios, timestamps, etc.) and distinguishes it from sibling archive tools like archive_comment or archive_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?
The description implies usage for obtaining a high-level overview of an archive, but it does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any preconditions or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Archive polyglot detection. Checks if a ZIP archive has prepended data that could make it valid as another file format (e.g., PDF+ZIP, PNG+ZIP, ELF+ZIP). Polyglot files are used in CTF challenges and to bypass file type filters.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to ZIP archive |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description states it 'checks' but does not clarify whether it is read-only, what the output looks like, or any side effects. Given the lack of annotation support, the description carries the full burden and does not sufficiently disclose behavioral traits.
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 long, front-loading the core action, then explaining the concept and use cases. Every sentence provides 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?
For a simple detection tool with one parameter and no output schema, the description covers the purpose, input, and common use cases. It could optionally describe the return type (e.g., boolean or details) but is largely complete given the tool's simplicity.
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 sole parameter 'file_path' is described in the schema as 'Path to ZIP archive', and the description reinforces that it is for a ZIP archive. With 100% schema coverage, the description adds meaningful context beyond the schema by specifying the file type context.
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 ('checks if a ZIP archive has prepended data') and the resource ('ZIP archive'). It distinguishes the tool from siblings like 'create_polyglot' and other archive tools by focusing on detection.
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 context ('used in CTF challenges and to bypass file type filters') but lacks explicit guidance on when to use this tool versus alternatives like 'file_polyglot' or other detection tools. Usage is implied but not clearly scoped.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Slack space analysis for ZIP archives. Identifies and hex-dumps gaps between ZIP local file entries. Slack spaces are unused bytes between entries that can conceal hidden data without altering the archive's functionality.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to ZIP archive | |
| max_dump_size | No | Max bytes to hex-dump per slack space (default: 256) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the tool 'identifies and hex-dumps gaps' and explains slack spaces are unused bytes that conceal data without altering functionality. However, it does not disclose whether the operation is read-only, any required permissions, or potential side effects like file modification.
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, no filler, highly efficient. Every sentence contributes to understanding the tool's purpose and behavior.
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?
No output schema, but description adequately covers what the tool does and its main behavioral aspect (hex-dumping slack spaces). Lacks details on return values or handling of edge cases, but overall sufficient for a simple analysis 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?
Input schema covers both parameters with descriptions. Description adds no further meaning beyond schema: file_path is simply 'Path to ZIP archive' and max_dump_size is 'Max bytes to hex-dump per slack space (default: 256)'. Baseline 3 is appropriate.
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 performs 'Slack space analysis for ZIP archives' and explains what slack spaces are and their relevance to hiding data. It distinguishes from sibling tools like archive_structure and archive_comment by specifying a unique focus on gaps between local file entries.
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. Description implies usage when investigating hidden data in ZIP archives, but lacks when-not-to-use or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ZIP entry structure analysis. Lists all local file headers with their byte offsets, compressed and uncompressed sizes, compression method, CRC-32, flags, and data start offsets. Provides a low-level structural map of the archive.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to ZIP archive |
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 analysis operation by mentioning 'analysis' and 'structural map,' but does not explicitly confirm non-destructiveness or disclose additional behavioral traits like performance 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 two concise sentences with front-loaded purpose ('ZIP entry structure analysis'). Every sentence adds value, with no unnecessary 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 simple input schema (one required parameter with clear description) and no output schema, the description fully explains what the tool does and what information it returns. It is complete for a one-parameter scanning 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 coverage is 100% with a clear parameter description. The tool description adds no further meaning to the file_path parameter beyond what the schema already provides.
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 performs 'ZIP entry structure analysis' and lists the specific fields it provides (byte offsets, sizes, compression method, CRC-32, flags, data start offsets). This distinguishes it from siblings that focus on comments, metadata, or extra fields.
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 low-level structural analysis of ZIP archives but does not explicitly state when to use or avoid this tool versus alternatives like archive_comment or archive_metadata. No exclusions or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Auto-detect audio steganography in a WAV file. Runs LSB chi-square, entropy analysis, metadata inspection, and checks for appended data after the WAV data chunk.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to audio file (WAV) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool runs multiple analyses (LSB chi-square, entropy analysis, metadata inspection, appended data check), which is good transparency. However, it does not describe the output format or any side effects, leaving some gaps.
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 that clearly states the purpose and methods. There is no wasted text, and it front-loads the main action. Every word earns its place.
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 one simple parameter with full schema coverage and no output schema, the description is adequate but missing details on return values or how results are presented. For a detection tool, the agent would benefit from knowing the output format.
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 parameter 'file_path' with 100% coverage. The description adds no additional meaning beyond the schema; it mentions 'WAV file' but the schema's description already specifies 'Path to audio file (WAV)'. Baseline 3 is appropriate.
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 verb 'auto-detect' and the resource 'audio steganography in a WAV file'. It lists specific analysis methods (LSB chi-square, entropy analysis, metadata inspection, appended data check), which distinguishes it from sibling tools like audio_lsb_detect or audio_echo_detect.
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 detecting audio steganography but provides no explicit guidance on when to use this tool versus alternatives such as audio_lsb_detect or audio_echo_detect. There is no mention of prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Echo hiding detection via autocorrelation analysis. Computes normalized autocorrelation at common echo delays (50-1000 samples). Unusually regular echo patterns indicate steganographic echo hiding.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to WAV file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral transparency. It discloses the analysis method (autocorrelation), the delay range examined, and the interpretation of results. It does not mention side effects or output format, but the read-only nature is implied. A score of 4 reflects good transparency for a simple analysis 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 extremely concise with only two sentences, no filler, and the purpose is front-loaded. Every sentence provides essential information about the tool's function and method.
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 simple tool with one parameter and no output schema, the description adequately covers the purpose, method, and interpretation. It does not explicitly state the output format, but the mention of 'indicate' implies a detection result. Given no annotations, it is reasonably 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 schema has 100% coverage for the single parameter (file_path) which is well-documented as 'Path to WAV file'. The tool description does not add additional semantic meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
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: detecting echo hiding in audio files via autocorrelation analysis. It specifies the method (normalized autocorrelation at common echo delays 50-1000 samples) and the indicator (unusually regular echo patterns). This distinguishes it from other audio steganography detection siblings like audio_lsb_detect.
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 the tool is for echo hiding detection but lacks explicit guidance on when to use it vs. alternative audio stego detection tools (e.g., audio_lsb_detect). No mention of prerequisites or when not to use it, which is a gap given the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PCM sample LSB statistical analysis. Performs chi-square test on LSBs grouped by value pairs to detect LSB replacement steganography in WAV audio.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to WAV file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It explains the chi-square method and grouping by value pairs, but does not disclose the output format (e.g., p-value, boolean), error conditions, or limitations (e.g., only works on uncompressed WAV). Partial transparency leaves gaps.
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: the first states the tool's function, the second details the method. It is concise and front-loaded, but could be slightly tighter (e.g., combining 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?
For a single-parameter detection tool with no output schema, the description explains the method but omits the output format (e.g., returns a chi-square statistic or detection verdict). This leaves the agent uncertain about how to interpret results.
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 100% for the single parameter (file_path), documented as 'Path to WAV file'. The description adds no additional semantics beyond the schema, so baseline 3 is appropriate.
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 tool's function: PCM sample LSB statistical analysis using a chi-square test to detect LSB replacement steganography in WAV audio. It clearly distinguishes from sibling tools like audio_lsb_extract (extraction) and audio_echo_detect (different technique).
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 (e.g., audio_detect, img_chi_square) or when not to use it. The description only states what it detects, but lacks context for selection among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract LSB data from audio samples. Reads the least significant bit of each PCM sample and attempts to decode hidden data.
| Name | Required | Description | Default |
|---|---|---|---|
| channel | No | Audio channel (default: 0) | |
| file_path | Yes | Path to WAV file | |
| max_bytes | No | Max bytes to extract (default: 4096) |
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 mentions extraction and decoding attempts but lacks details on file modification, return behavior on failure, or prerequisites. Essential safety information is missing.
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 long, no wasted words, and directly addresses the tool's function. It is efficiently front-loaded with the key action.
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 and annotations, the description is minimal but covers the basic action. However, it omits details on return format, error handling, and behavior for empty or missing hidden data, making it only adequately complete for a simple 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 coverage is 100%, so the description adds no additional meaning beyond the schema. It does not explain parameter formats or provide context beyond what is already in the schema. Baseline score of 3 is appropriate.
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 verb 'extract' and the resource 'LSB data from audio samples', and distinguishes itself from the sibling tool 'audio_lsb_detect' by focusing on extraction rather than detection.
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 extracting hidden data from audio files but does not explicitly state when to use this tool versus alternatives like 'audio_lsb_detect' or other steganography tools. No when-not-to-use or alternative names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract metadata from a WAV file including RIFF INFO chunks, format details, and all chunk information.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to WAV file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavioral traits. It correctly implies a read-only operation but does not explicitly state safety or side effects. No contradictions, but additional details (e.g., no file modification) 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 a single, well-structured sentence with no extraneous words. It front-loads the core action and details 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 simple parameter schema and no output schema, the description adequately covers what the tool does. It could mention output format or limitations, but for a straightforward metadata extraction tool, it is sufficiently 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?
Schema coverage is 100% and the parameter 'file_path' is adequately described in the schema. The description adds context about the extraction output, but does not enhance parameter semantics beyond the schema's description.
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 action (extract metadata), the resource (WAV file), and specifics (RIFF INFO chunks, format details, all chunk information). It differentiates well from sibling tools like audio_detect or audio_echo_detect, which focus on other aspects.
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. While the purpose is clear from the description, it does not provide context such as preferred use cases or exclusion criteria compared to other audio tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze silent sections in WAV audio for hidden data. Finds near-zero sample regions and checks their LSBs — silent sections with active LSBs are a strong indicator of steganography.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to WAV file | |
| threshold | No | Silence threshold (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explains the method (finding near-zero regions and checking LSBs) and indicates the result is a strong steganography indicator. However, it does not explicitly state read-only behavior, file format requirements, or whether the tool modifies files.
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, front-loaded with the purpose, and every word adds value. No redundancy or wasted 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 the tool's moderate complexity and the simplicity of the input schema (two parameters, no output schema), the description adequately explains the core functionality and methodology. It could briefly mention output format or return type, but overall it is complete enough for typical use.
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 100% with both parameters described in the input schema. The description does not add additional meaning beyond the schema; it does not mention the threshold parameter or its default value. Baseline 3 is appropriate.
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 analyzes silent sections in WAV audio for hidden data using LSB checking. It uses a specific verb 'analyze' and resource 'WAV audio', and distinguishes itself from sibling tools like audio_lsb_detect and audio_echo_detect by focusing on silent regions.
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 detecting steganography in silent audio sections but does not explicitly state when to use this tool versus alternatives like audio_lsb_detect or audio_echo_detect. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Basic spectral analysis for hidden signals in WAV audio. Analyzes sample value distribution, zero-crossing rate, RMS energy per block, and detects anomalous quiet sections with high entropy.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to WAV file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses the analyses performed (read-only operations like analyzing distribution, zero-crossing, RMS) but does not explicitly state read-only nature, auth needs, or side effects. Adequate but could be more 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?
Description is a single sentence with a list of analyses, front-loading the purpose. No redundancy, but could be slightly more structured (e.g., separate usage note).
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, description should explain return values or output format. It does not. Also lacks usage context among many audio sibling tools. Incomplete for an analyst to know what to expect.
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 parameter file_path, which has schema description 'Path to WAV file'. Tool description adds context about analysis but no additional parameter-specific semantics. With 100% schema coverage, baseline 3 is appropriate.
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 the tool performs basic spectral analysis on WAV audio, listing specific analyses: sample value distribution, zero-crossing rate, RMS energy, and anomalous quiet sections. This distinguishes it from siblings like audio_detect or audio_echo_detect.
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?
Description implies use for spectral analysis of WAV files but provides no explicit guidance on when to use this tool vs alternatives (e.g., audio_detect, audio_lsb_detect). No when-not-to-use or prerequisite info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate BPCS embedding capacity. Counts the number of complex blocks at various thresholds across all bit planes and channels, then calculates the maximum data that could be hidden using BPCS. Reports capacity in bits, bytes, and as a percentage of the image size.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to image file (PNG or JPEG) for capacity estimation | |
| threshold | No | Complexity threshold (0.0-1.0, default: 0.3) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It describes the estimation process but does not explicitly state that the tool is read-only and does not modify the file. It also omits any prerequisites beyond the input format mentioned in the schema.
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 (3 sentences), front-loaded with purpose, and every sentence adds value: purpose, method, and output units. 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?
The description explains output units (bits, bytes, percentage) despite lacking an output schema. It also mentions the algorithm's scope (all bit planes and channels) and input format, making it complete for a simple estimation 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 100%, so baseline is 3. The description adds context about how the threshold is used in the algorithm but does not provide meaning beyond what the schema already states.
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: 'Estimate BPCS embedding capacity.' It explains the method (counting complex blocks across bit planes and channels) and output units (bits, bytes, percentage). This distinguishes it from siblings like bpcs_detect, bpcs_extract, and bpcs_complexity_map.
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 versus alternatives. The usage is implied (when needing capacity estimation before embedding), but no exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a detailed complexity map of all bit planes for a given channel. Computes border complexity for each 8x8 block across all 8 bit planes, producing a spatial map showing where complex (potentially data-carrying) regions are located in the image.
| Name | Required | Description | Default |
|---|---|---|---|
| channel | No | Color channel: 0=R, 1=G, 2=B (default: 0) | |
| file_path | Yes | Path to image file (PNG or JPEG) for complexity mapping | |
| threshold | No | Complexity threshold (0.0-1.0, default: 0.3) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It explains that the tool computes border complexity and produces a spatial map, but it does not specify the output format, whether the tool modifies files, or any required permissions. The information is 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 concise and front-loaded with the core purpose. Two sentences efficiently convey the tool's action and methodology without extraneous 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?
The tool lacks an output schema, and the description does not clarify the output format (e.g., image, data structure). For a tool that produces a 'spatial map,' more details on return type or visualization are needed for completeness. Additionally, given sibling tools, more differentiation would be helpful.
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 100% with descriptions for all three parameters (channel, file_path, threshold). The description adds minimal value beyond the schema, mentioning 'for a given channel' but not providing additional context on usage or syntax. Baseline of 3 is appropriate.
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: generating a detailed complexity map of all bit planes for a given channel. It specifies the method (border complexity for 8x8 blocks across all 8 bit planes) and the output (spatial map showing complex regions). This effectively distinguishes it from sibling tools like bpcs_detect or bpcs_extract.
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. It does not mention exclusions, prerequisites, or other tools' use cases. This leaves the agent without context for choosing between complexity_map and related tools like bpcs_capacity or bpcs_threshold.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Auto-detect BPCS (Bit-Plane Complexity Segmentation) steganographic embedding. Computes the complexity map across all bit planes and channels, then checks for an abnormally high ratio of complex blocks — the signature of BPCS embedding which replaces complex bit-plane regions with hidden data.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to image file (PNG or JPEG) for BPCS detection | |
| threshold | No | Complexity threshold (0.0-1.0, default: 0.3) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the internal algorithm (complexity map across bit planes and channels, checking ratio of complex blocks). It does not disclose error handling or performance, but the core read-only detection behavior is well 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?
Two concise sentences, zero waste. First sentence front-loads the purpose, second provides the technical method. Every word earns its place.
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 explains the detection logic and parameters but does not mention the output format (e.g., returns true/false or a confidence score). For a detection tool with no output schema, this is a gap. File type restrictions are covered in schema, but overall 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 coverage is 100%, so baseline is 3. The description does not add information beyond what the schema already provides for both file_path and threshold. The threshold's range and default are already in the schema description.
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 auto-detects BPCS steganography, specifying the verb 'auto-detect' and the resource 'BPCS steganographic embedding'. It explains the detection method (complexity map on all bit planes and channels) and mentions the signature of BPCS, which distinguishes it from siblings like bpcs_extract or bpcs_capacity.
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 use when suspecting BPCS embedding, but it does not explicitly state when not to use it or suggest alternatives. The context is clear, but lacking explicit when-not advice keeps it from a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract data from BPCS complex regions. Gathers bits from all blocks that exceed the complexity threshold in the specified bit plane, assembling them in raster-scan order. The extracted bytes are analyzed for structure including magic bytes, entropy, and printable text content.
| Name | Required | Description | Default |
|---|---|---|---|
| plane | No | Bit plane: 0=LSB, 7=MSB (default: 0) | |
| channel | No | Color channel: 0=R, 1=G, 2=B (default: 0) | |
| file_path | Yes | Path to image file (PNG or JPEG) for BPCS extraction | |
| max_bytes | No | Maximum bytes to extract (default: 4096) | |
| threshold | No | Complexity threshold (0.0-1.0, default: 0.3) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the extraction process (gathers bits, assembles, analyzes for structure) which is helpful. However, it does not explicitly state that the tool does not modify the file (non-destructive) or mention any 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?
Two sentences with no fluff. The first sentence states the purpose, the second elaborates on the process. Efficient and 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?
With 5 parameters and no output schema or annotations, the description provides a good overview of the tool's workings. It does not mention return format or file type constraints, but schema covers file_path type. Reasonably complete for a complex extraction 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 descriptions are detailed (100% coverage) and the tool description adds context by explaining how the parameters (threshold, plane) affect the extraction logic. This goes beyond the individual parameter descriptions.
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 'Extract data from BPCS complex regions' and details the process (gathers bits from blocks exceeding threshold, assembles in raster-scan order). This distinguishes it from sibling tools like bpcs_detect and bpcs_complexity_map, which serve different purposes.
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 or not use this tool vs alternatives. The description implies it is used after detection, but does not mention appropriate contexts or mention sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Complexity threshold analysis for BPCS steganalysis. Tests multiple threshold values and analyzes how the complex/simple block ratio changes. Finds the optimal threshold boundary where BPCS embedding would be most detectable, and identifies threshold ranges that produce suspicious ratios.
| Name | Required | Description | Default |
|---|---|---|---|
| plane | No | Bit plane to analyze: 0=LSB, 7=MSB (default: 0) | |
| channel | No | Color channel: 0=R, 1=G, 2=B (default: 0) | |
| file_path | Yes | Path to image file (PNG or JPEG) for threshold analysis |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It explains the analysis process (testing thresholds, analyzing ratio changes) but does not state that the tool is read-only (no modifications to files) or any potential side effects. Additional context like required permissions or performance impact is missing.
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, concise and front-loaded with the core purpose. It avoids unnecessary words. However, it could be slightly more compact by integrating the second and third sentences, but it remains 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 no output schema and the tool's analytical nature, the description provides an overview of what it does but lacks detail on the output format (e.g., what kind of data is returned). It mentions identifying suspicious ratios but not how they are presented. The tool's complexity warrants a bit more detail on outputs.
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 100%, meaning each parameter is described in the schema. The description adds general context about the tool's purpose but does not elaborate on the specific parameters (plane, channel, file_path) beyond what the schema provides. Baseline 3 is appropriate.
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: complexity threshold analysis for BPCS steganalysis. It uses specific verbs like 'tests', 'analyzes', 'finds', and 'identifies', and distinguishes from sibling bpcs tools by focusing on threshold boundary and suspicious ratios.
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 the tool is used for threshold analysis to find detectability boundaries, but it does not explicitly state when to use it versus other bpcs tools (e.g., bpcs_detect, bpcs_complexity_map) or provide when-not-to-use guidance. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inject data into format-specific comment fields. Supports PNG tEXt chunks, JPEG COM markers, and GIF comment extensions. The comment is stored in a standards-compliant way that most viewers ignore but metadata tools can read.
| Name | Required | Description | Default |
|---|---|---|---|
| comment | Yes | Comment data to inject | |
| file_path | Yes | Path to the cover image file (PNG, JPEG, or GIF) | |
| output_path | Yes | Path for the output file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description carries full burden. It usefully discloses that the comment is stored in a standards-compliant way that most viewers ignore, indicating stealthy behavior. However, it does not mention side effects, size limits, or error handling.
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 no wasted words. The action comes first, and the rest provides essential detail. Perfectly concise for the tool's complexity.
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 3 parameters, no output schema, and no annotations, the description covers the core purpose, supported formats, and an important behavioral attribute. It lacks return value details and error conditions, but for a simple injection tool it is fairly 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?
Schema coverage is 100%, so baseline is 3. The parameter descriptions in the schema are minimal but clear. The tool description adds context about format-specific comment fields but does not elaborate on constraints like comment length or encoding 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 it injects data into format-specific comment fields, lists supported formats (PNG, JPEG, GIF), and distinguishes itself from siblings like gif_comment and jpeg_comment which are likely for reading comments.
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 it is for writing comments by saying 'Inject data', but does not explicitly guide when to use this tool vs alternatives like create_metadata or format-specific comment tools. No when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Append data after a file's end-of-file marker. The injected data is invisible to most viewers/parsers since they stop reading at the format EOF. Supports any file format — simply appends the given data string to the file's end.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | String data to inject after EOF | |
| file_path | Yes | Path to the cover file | |
| output_path | Yes | Path for the output file |
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 mentions that injected data is invisible to most parsers, but does not disclose potential side effects (e.g., file integrity, detection methods, permissions needed, or whether the operation is reversible). For a tool that modifies files, this is insufficient.
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 with no filler. The primary action and key behavior are front-loaded. Every word earns its place.
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?
No output schema is provided, but the tool's output (probably a file path or success status) is not described. With no annotations, the description should cover error conditions or prerequisites. It is functional but could be more 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?
Schema coverage is 100%, so the schema already describes parameters. The description adds context for 'data' (appended as string), but does not elaborate on file_path or output_path beyond what the schema provides. Baseline 3 is appropriate.
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 the verb 'append' and resource 'after a file's end-of-file marker', distinguishing it from sibling tools like create_comment or create_metadata. The purpose is specific and 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?
Description explains when to use (to hide data invisible to most viewers) and that it supports any file format. It does not explicitly mention alternatives or when not to use, but the context is clear enough given the sibling tool list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inject data into a file's metadata fields. For PNG files, inserts a tEXt chunk with the given field name and data. For JPEG files, inserts EXIF APP1 data. The injected metadata persists in the file and is accessible via metadata readers.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Data to inject into the metadata field | |
| field | Yes | Metadata field name (e.g., 'Comment', 'Author', 'Description') | |
| file_path | Yes | Path to the cover file | |
| output_path | Yes | Path for the output file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It mentions persistence and accessibility, but lacks details on permissions, reversibility, side effects, or error behavior for unsupported file types. For a mutation tool, this is insufficient.
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, front-loaded with the main purpose. No fluff. Efficient 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?
No output schema; description explains file-type behavior but omits important context: what happens to original file (overwritten?), handling of other image formats, and output file specifics. Adequate but not thorough for a multi-format injection 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 100%, so baseline is 3. The description adds value by explaining the injection format (tEXt/EXIF), providing context beyond the parameter descriptions. However, it doesn't clarify JPEG field naming conventions.
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 verb 'Inject data into a file's metadata fields' and specifies the resource. It distinguishes behavior for PNG (tEXt chunk) and JPEG (EXIF APP1), which differentiates it from sibling tools like create_comment or jpeg_comment.
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 when to use (when metadata injection is needed) but provides no explicit guidance on when not to use it or how it compares to siblings like archive_metadata or doc_pdf_metadata. No exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create null cipher text that hides a secret message using letter selection. In 'first_letter' mode, the first letter of each word spells out the secret. In 'nth_word' mode, every Nth word's first letter spells the secret. Returns the generated cipher text.
| Name | Required | Description | Default |
|---|---|---|---|
| method | Yes | Embedding method: 'first_letter' uses the first letter of each word, 'nth_word' uses every Nth word | |
| cover_text | Yes | Cover text to use as source material. Must have enough words for the chosen method. | |
| secret_message | Yes | Secret message to embed (letters only, case-insensitive) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose important behavioral details such as the missing 'n' parameter for nth_word mode, nor does it state the tool is non-destructive or has no side effects. Since no annotations are provided, the description carries the full burden but falls short.
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, ~60 words), front-loaded with the purpose, and efficiently explains the two modes and output. Every sentence earns its place with no fluff.
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 fails to mention that nth_word mode requires an additional 'n' parameter, which is absent from the input schema. This omission makes the tool specification incomplete and potentially confusing. No output schema is provided, but description adequately states return value.
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 100%, so baseline is 3. The description repeats information already in the schema's parameter descriptions (e.g., modes explained in both places). It adds no new semantic value about the parameters themselves.
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 creates a null cipher text hiding a secret message via letter selection, and distinguishes two modes. However, it does not explicitly differentiate from sibling creation tools like text_acrostic, and the missing 'n' parameter for nth_word mode slightly undermines clarity.
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 (e.g., text_acrostic or other text steganography creation tools). The description only explains functionality without suggesting appropriate scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Embed data in palette color entry LSBs for indexed-color images (PNG with PLTE chunk or GIF). Each palette entry has R, G, B values — the least significant bit of each channel encodes one bit of the secret data. Capacity is 3 bits per palette entry.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Secret data string to embed in palette LSBs | |
| file_path | Yes | Path to an indexed-color image (PNG palette or GIF) | |
| output_path | Yes | Path for the output file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It explains the embedding method (3 bits per palette entry) and capacity but does not disclose whether the operation is destructive (overwrites LSBs), requires a certain palette size, or alters the image structure beyond LSBs.
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 contains no unnecessary words or redundancy. Every sentence provides essential 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?
The description covers the core functionality and capacity but lacks information about output format, error handling, or input validation. No output schema exists to supplement, so the description should be more comprehensive for a complete understanding.
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 100%, so baseline is 3. The description adds context about the embedding mechanism but does not provide additional details beyond the schema for parameters like data encoding or file format 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?
Description clearly states 'Embed data in palette color entry LSBs for indexed-color images' and specifies file formats (PNG PLTE or GIF), distinguishing it from sibling tools like gif_palette_lsb (likely detection/extraction) and img_lsb_embed (for non-palette images).
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 use for indexed-color images but does not explicitly state when to use versus alternatives (e.g., img_lsb_embed for direct-color) or when not to use (e.g., if palette has insufficient entries). No exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create polyglot files by prepending one file format before another. The resulting file is valid when interpreted as either format. For example, prepend a PDF before a ZIP to create a file that is both a valid PDF and a valid ZIP.
| Name | Required | Description | Default |
|---|---|---|---|
| file1_path | Yes | Path to the first file (will be at the start of the output) | |
| file2_path | Yes | Path to the second file (will be appended after the first) | |
| output_path | Yes | Path for the output polyglot file |
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 the output file is valid as either format, but does not mention potential side effects (e.g., file modification, permissions, limitations on file types). More detail on behavior 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?
Two sentences concisely convey the tool's purpose, method, and an example. No redundant information, clearly front-loaded with the core action.
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 adequately covers the tool's function and provides a concrete example. Lacks detail on error cases or compatibility, but is complete enough for a straightforward creation 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 coverage is 100% with clear parameter descriptions. The tool description does not add new meaning beyond the schema, as it only repeats that file1 is prepended and file2 is appended. Baseline score of 3 is appropriate.
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 identifies the verb 'create' and the resource 'polyglot files', explaining the method of prepending one file format before another. It distinguishes from sibling tools like 'file_polyglot' (likely detection) and provides an illustrative example with PDF and ZIP.
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 creating polyglot files but does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The usage is suggested but not clarified beyond the core purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Embed data in file whitespace using trailing spaces and tabs on text lines. Each bit of the secret data is encoded as a trailing space (0) or tab (1) appended to lines in the cover text file. The whitespace is invisible in most text editors.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Secret data string to embed | |
| file_path | Yes | Path to a text cover file | |
| output_path | Yes | Path for the output file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description explains the encoding mechanism (spaces/tabs) and notes invisibility in most editors. It does not disclose potential side effects like file size increase or compatibility issues with whitespace-stripping editors, but overall provides useful behavioral context.
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, front-loaded with the core purpose. No unnecessary information. Each 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?
The description lacks information about prerequisites (input must be a text file), limitations (whitespace may be stripped by some tools), and the fact that the output file preserves visible text. For a tool that modifies files, more completeness is needed.
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 100% with descriptions for each parameter. The description adds context about the encoding scheme but does not elaborate on parameter specifics beyond what the schema already provides. Baseline 3 is appropriate.
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 embeds data into file whitespace by encoding bits as trailing spaces (0) or tabs (1). It distinguishes itself from sibling tools like text_whitespace_detect and text_whitespace_extract, which are for detection and extraction.
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 embedding secret data in text files but does not provide explicit guidance on when to use this tool versus other embedding tools or when not to use it. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multi-format decoder supporting Base64, hex, binary, decimal, octal, URL encoding, ROT13, Base32, Morse code, and HTML entities. In auto mode, detects the encoding first and applies the appropriate decoder.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | String to decode | |
| encoding | No | Encoding format (default: auto) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the decoding action and auto-detection behavior. No annotations provided, but description does not disclose any side effects, auth needs, or limitations. Adequate but not detailed.
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 front-loading all supported formats and the auto mode feature. No redundant 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?
Provides core functionality but omits output format and error handling. Without output schema, agent lacks info on return value. Sufficient for simple usage 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?
Schema covers both parameters with descriptions. Description adds value by explaining auto mode behavior for encoding parameter, beyond enum list. Does not elaborate on input format specifics.
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?
Clearly specifies it is a multi-format decoder supporting Base64, hex, binary, etc. Distinct from sibling tools like crypto_detect or crypto_entropy, which are not decoders.
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?
States it is a decoder for multiple formats and mentions auto mode, implying use when decoding various encodings. Lacks explicit when-not or alternatives, but sibling context shows it is the only decoder.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Auto-detect encoding type of an input string. Tests against all known encoding patterns (Base64, hex, binary, morse, URL encoding, HTML entities, etc.) and returns matches sorted by confidence, with attempted decoding for top results.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Encoded string to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adequately discloses behavior: tests all patterns, returns sorted matches with confidence, attempts decoding for top results. Lacks mention of potential limitations like false positives or performance impact, but covers main actions.
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 that convey all necessary information without redundancy. Every word adds value. Very 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 no output schema, the description provides a reasonable summary of return behavior (matches sorted by confidence with decoding attempts). Slightly incomplete on exact format but sufficient for a detection 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 already fully describes the single parameter ('Encoded string to analyze'). The description adds no additional semantic information beyond what the schema provides. Baseline score applies due to high 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?
Clearly states the tool's function: auto-detect encoding type of an input string, testing against known patterns. Specifically distinguishes itself from siblings like crypto_decode by focusing on detection rather than decoding a known format.
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?
Describes the tool's general purpose but provides no explicit guidance on when to use it versus siblings (e.g., crypto_decode for known encodings, crypto_hash_id for hashes). Use context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shannon entropy calculation and classification for strings. Computes both character-level and byte-level entropy, classifying the result into categories: very low (repeated), low (simple text), normal text, compressed/encoded, or encrypted/random.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | String to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions entropy calculation and classification but does not disclose behavioral traits such as performance characteristics, edge case handling, or any limitations beyond basic functionality.
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 that efficiently convey the core purpose and additional detail. No unnecessary words; front-loaded with the main action.
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 ideally describe return values. It mentions classification categories but not the structure of results. For a simple tool with one parameter, it is adequate 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?
Schema coverage is 100% (one parameter with description 'String to analyze'). The description adds value by explaining the output classification categories, which goes beyond the schema. However, it could still be more explicit about expected input formats.
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 calculates Shannon entropy for strings, specifying both character and byte levels and classification. While clear, it doesn't explicitly differentiate from similar sibling tools like file_entropy or img_entropy_map, which may operate on different data types.
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 crypto_frequency or file_entropy. The description merely states what it does without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Character frequency analysis for cryptanalysis. Counts character occurrences, compares to standard English letter frequency (ETAOINSHRDLU), and calculates the Index of Coincidence. IC near 0.0667 suggests English/monoalphabetic, IC near 0.038 suggests random/polyalphabetic.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Text to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It clearly indicates a read-only analysis (no modification) and explains what computations are performed. It does not mention any side effects or permissions, but for a passive analysis tool this is adequate.
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, front-loaded with the core purpose, and each sentence adds value without redundancy. No fluff or extraneous details.
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 simple tool with one parameter and no output schema, the description covers the what, how, and interpretation of results (IC values). It is sufficiently complete given the tool's complexity.
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 one parameter with description 'Text to analyze', and coverage is 100%. The description adds context on the analysis but does not enhance the parameter's meaning beyond what the schema provides. Baseline score of 3 is appropriate.
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 performs character frequency analysis for cryptanalysis, including counting occurrences, comparing to standard English letter frequency, and calculating Index of Coincidence. This specific verb+resource job distinguishes it from siblings like crypto_detect or crypto_entropy.
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 tells when to use it (cryptanalysis frequency analysis) and provides interpretation guidelines for IC values. However, it does not explicitly state when not to use it or mention alternatives, though the sibling context implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hash type identification. Matches the input against known hash patterns by length and format to identify possible hash algorithms (MD5, SHA-1, SHA-256, SHA-512, bcrypt, CRC32, NTLM, MySQL, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Hash string to identify |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description provides basic behavioral context (matching by length and format, possible algorithms) but lacks details on output behavior (e.g., single vs multiple matches, error handling, confidence indicators).
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?
Extremely concise: two sentences, first is a clear label, second explains the mechanism. No redundant information; every word is functional.
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 full context: no output specification (e.g., return format), no error handling details, and no mention of edge cases. With no output schema, the description should be more explicit about what the tool returns.
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?
Despite 100% schema coverage, description adds value by explaining the input's purpose and listing algorithms checked, going beyond the schema's minimal 'Hash string to identify' description.
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 the tool identifies hash types by matching input against known patterns, with specific algorithm examples (MD5, SHA-1, etc.). It distinguishes itself from siblings like crypto_decode (for decoding) and crypto_entropy (for entropy analysis) by focusing on hash pattern identification.
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. Does not mention limitations or when not to use it. Usage context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Known cipher and encoding pattern detection. Analyzes text for indicators of Caesar cipher, substitution cipher, Vigenere, rail fence transposition, Atbash cipher, and reversed text. Uses statistical methods like Index of Coincidence and frequency analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Text to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses use of statistical methods and lists detectable ciphers, but does not detail output format, side effects, or determinism. Adequate but not thorough.
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, concise and front-loaded with key info. Every word adds value; 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?
With no output schema and no annotations, the description could improve by explaining what the tool returns (e.g., list of detected patterns, confidence scores). Current description covers input and method but not output, leaving a gap.
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 100% (single 'input' parameter described as 'Text to analyze'). Description adds no extra semantic meaning beyond schema; baseline 3 applies.
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 detects known cipher patterns in text, listing specific ciphers (Caesar, substitution, Vigenere, etc.) and methods (Index of Coincidence, frequency analysis). This differentiates it from siblings like crypto_detect or crypto_decode.
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 does not mention when not to use it or compare with other crypto tools, leaving the agent to infer usage from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
XOR key brute-force for single-byte and multi-byte keys. Tries all single-byte XOR keys (0x00-0xFF) and scores by printable character ratio. For multi-byte keys, uses Index of Coincidence to estimate key length. Returns top 5 most likely results.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Hex-encoded or base64 ciphertext | |
| max_key_length | No | Maximum key length to try (default: 4) |
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 the brute-force approach, scoring criteria, and key length estimation method. It does not mention error handling or performance, but the key behaviors are transparent.
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: first states the core action and method, second details multi-byte approach and output. No superfluous information; 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?
The description covers the algorithm and result count (top 5), but lacks details about the output format (e.g., what exactly is returned: keys, scores, decoded text?). For a tool without output schema, this is a minor gap.
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 100% with both parameters described. The description adds context by explaining how 'input' is ciphertext (hex/base64) and how 'max_key_length' is used in multi-byte brute-force, adding value beyond 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 it performs XOR key brute-force for single-byte and multi-byte keys, explaining the scoring method (printable character ratio) and key length estimation (Index of Coincidence). This distinguishes it from sibling tools like crypto_detect, crypto_decode, etc.
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 when XOR-encrypted data is suspected, but does not explicitly state when to use it over alternatives (e.g., crypto_detect, crypto_decode) or provide exclusions. Usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PDF metadata extraction. Parses the /Info dictionary for standard fields (Title, Author, Creator, Producer, CreationDate, ModDate) and searches for XMP metadata blocks. Useful for forensic attribution and document provenance analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to PDF file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the extraction process (parsing /Info dictionary and XMP) but lacks details on error handling, file requirements (e.g., encryption), or return format. Basic transparency 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 sentences. The first states the core function, the second adds technical details and a use case. Every sentence is informative 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 the simple tool (one parameter, no output schema), the description covers basic functionality and a use case. However, it does not specify the output format (e.g., returns a dictionary) or mention potential edge cases (e.g., missing metadata). This leaves some gaps for an agent to understand what the tool returns.
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 100% with a clear description of the file_path parameter. The description adds the context that the tool extracts metadata, but does not provide additional details about parameter format, validation, or allowed values 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 'PDF metadata extraction' with specific details about parsing /Info dictionary and XMP metadata. This distinguishes it from sibling tools like doc_xml_metadata (for XML files) and doc_pdf_hidden (for hidden content).
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 a use case ('forensic attribution and document provenance analysis') but does not explicitly guide when to use this tool over alternatives or specify exclusions. No comparison with sibling tools is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PDF stream analysis. Locates all stream/endstream blocks in a PDF, attempts zlib decompression on each, and reports sizes and entropy. Useful for finding hidden data within compressed PDF content streams.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to PDF file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains the process: locating all stream/endstream blocks, attempting zlib decompression, and reporting sizes and entropy. This is transparent about the tool's actions, though it does not mention if it modifies the file (assumed read-only) or any permission requirements.
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, front-loaded with the main action, and efficiently adds detail without redundancy. Every sentence contributes meaning.
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 core functionality well but lacks detail on the output format (e.g., how sizes and entropy are reported). Given no output schema, this is a gap. However, the tool is simple with one parameter, so it is largely adequate.
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 only parameter (file_path) is fully described in the schema with 'Path to PDF file'. The tool description adds no further semantic value beyond the schema. Schema coverage is 100%, so baseline score of 3 is appropriate.
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 verb 'analyzes' and the resource 'PDF streams', detailing the exact steps (locating blocks, decompression, reporting sizes and entropy). It distinguishes from siblings like doc_pdf_hidden and doc_pdf_metadata by focusing on compressed 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 explicitly states the use case: 'finding hidden data within compressed PDF content streams.' This provides clear context for when to use the tool. However, it does not explicitly state when not to use it or compare with specific siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
XML and Office document metadata extraction. Parses XML-like content for Dublin Core metadata (dc:creator, dc:title), Microsoft Office properties, processing instructions, and other metadata that may reveal authorship, editing history, or hidden information.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to XML file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that it parses XML-like content and may reveal hidden data, but does not explicitly state that it is read-only, safe, or what side effects (none) to expect. 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?
Description is two sentences, concise and front-loaded with the main purpose. Every sentence adds value without repetition or fluff.
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 tool with one parameter and no output schema, the description covers what the tool does, what inputs are expected, and what outputs (metadata types) to expect. No gaps remain.
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 sole parameter 'file_path' has a schema description 'Path to XML file'. The tool description adds context by listing the types of metadata extracted (Dublin Core, Office properties, etc.), which enriches understanding beyond the schema. Baseline 3 adjusted upward for 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 extracts metadata from XML and Office documents, listing specific metadata types like Dublin Core and MS Office properties. It is specific about the resource and action, but does not explicitly differentiate from sibling tools such as doc_pdf_metadata or file_strings.
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. The description does not mention scenarios where it is appropriate or inappropriate, nor does it reference sibling tools for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect data appended after a file's format-specific end-of-file marker. Supports PNG (IEND), JPEG (FFD9), BMP (file size header), ZIP (end of central directory), and PDF (%%EOF). Commonly used to hide data in images and documents.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the detection mechanism with format-specific markers, which is transparent. But with no annotations, it omits details about output, side effects, or limitations.
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 concise sentences front-load the purpose, list supported formats, and mention common usage. No 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 no output schema and no annotations, the description covers the tool's function and detection scope adequately but lacks details on return values and error handling.
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 single parameter file_path is fully described in the schema (100% coverage). The description adds no extra semantics beyond what the schema provides.
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 detects data appended after file-specific EOF markers, lists supported formats and common use. However, it does not differentiate from siblings like img_appended_data or file_embedded.
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 PNG, JPEG, BMP, ZIP, and PDF files when suspecting hidden data, but does not provide explicit guidance on when to use this tool over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Binary diff between two files. Compares files byte-by-byte and reports size comparison, first N differences with their offsets and values, percentage of identical bytes, and a summary of the changes. Useful for detecting steganographic modifications.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path_1 | Yes | First file path | |
| file_path_2 | Yes | Second file path |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully describes behavior: it reports size comparison, first N differences with offsets and values, percentage of identical bytes, and summary. No destructive actions are implied. The description is transparent and accurate.
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 long, front-loaded with the main purpose ('Binary diff between two files'). 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?
Although there is no output schema, the description explains the return values in sufficient detail (size comparison, differences, offsets, values, percentage, summary). For a comparison tool with only two parameters, this is complete enough for an agent to understand 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 100% with descriptions like 'First file path' and 'Second file path'. The description does not add meaning beyond what the schema provides. Baseline 3 is appropriate as the schema already documents the parameters adequately.
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 performs a binary diff between two files, comparing byte-by-byte. It specifies the outputs (size comparison, differences, offsets, values, percentage identical, summary). This distinguishes it from sibling tools like file_strings or file_hex.
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 the tool is useful for detecting steganographic modifications, providing a clear use case. It doesn't explicitly list when not to use it, but the purpose is well-defined, implying it's for binary comparison scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan for embedded files within a binary, similar to binwalk. Searches for known magic byte signatures at every offset within the file to discover hidden or appended files, concatenated archives, and other embedded content.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to file | |
| scan_depth | No | Bytes to scan (default: full file) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that scanning occurs at every offset for magic bytes, but does not discuss performance implications (e.g., long scan times on large files) or potential false positives. The binwalk analogy adds some context, but limitations are absent.
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 a single concise sentence with two clauses, no redundant wording. The binwalk analogy efficiently conveys context. A second sentence could add value (e.g., output format), but as is, it is well-structured 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?
Given no output schema, the description should clarify what the tool returns (e.g., list of offsets, file types). It covers the core purpose and method but lacks details on output format, edge cases, or performance characteristics, leaving the agent with incomplete understanding for a scanning tool of this complexity.
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 100%, so the schema already documents both parameters. The description does not add additional meaning beyond the schema; 'scan_depth' is already described in the schema as 'Bytes to scan (default: full file)'. Baseline 3 is appropriate.
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 that the tool scans for embedded files within a binary by searching for magic byte signatures, similar to binwalk. It explicitly distinguishes itself by focusing on hidden, appended files, and concatenated archives, which differentiates it from siblings like file_appended or file_strings.
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 binary file analysis via the binwalk analogy, but provides no explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned among the many sibling tools, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Section-by-section entropy analysis of a file. Calculates Shannon entropy per block and overall, flagging anomalous high-entropy sections that may indicate encrypted, compressed, or steganographically embedded data.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to file | |
| block_size | No | Block size in bytes (default: 1024) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the computational method (Shannon entropy per block) and the purpose (flagging anomalies). However, it does not mention whether the tool is read-only, what permissions are needed, or details about the output format, leaving some behavioral aspects unclear.
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 with no wasted words. The first sentence defines the core action, and the second adds crucial context. Ideal length and front-loading.
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 is sufficient for a simple analysis tool but lacks details on output structure (since no output schema is provided). It does not mention error handling, prerequisites (e.g., file existence), or expected return format, which an agent might need.
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 100%, providing basic parameter descriptions. The tool description adds value by contextualizing block_size as 'section-by-section' and explaining the significance of high-entropy flags, which goes beyond the schema alone.
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 calculates Shannon entropy per block and overall, flagging anomalous high-entropy sections. It specifies the resource (file) and the action (entropy analysis). Though it doesn't explicitly differentiate from siblings like crypto_entropy or file_entropy_visual, the context of file-level block analysis is distinct enough.
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 detecting encrypted, compressed, or steganographic data but does not explicitly state when to use this tool over alternatives. No exclusions or context for when not to use are provided, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ASCII entropy visualization of a file. Renders a text-based bar chart showing entropy levels across the file, making it easy to visually spot high-entropy regions that may contain hidden data, encryption, or compression.
| Name | Required | Description | Default |
|---|---|---|---|
| width | No | Chart width in characters (default: 60) | |
| file_path | Yes | Path to file | |
| block_size | No | Block size (default: 512) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry full burden. It states the output is an ASCII bar chart and hints at detecting hidden data, but does not describe the output format in detail (e.g., how Y-axis is scaled, whether it returns a string or prints). It also does not mention any side effects (though likely read-only).
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 with no wasted words. Front-loaded with the core purpose and followed by a brief rationale. Every sentence earns its place.
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 output more. It says 'text-based bar chart' but doesn't specify if it's printed or returned, or how to interpret the axes. For a visualization tool, 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 100%, so baseline is 3. The description adds context for the overall purpose but does not elaborate on parameters like width or block_size beyond what the schema already provides. The defaults are in schema, so the description adds minimal parametric insight.
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 is an 'ASCII entropy visualization of a file' that 'renders a text-based bar chart'. It specifies the verb 'renders' and resource (entropy visualization), and distinguishes it from other entropy tools like file_entropy which likely provides a single numeric value.
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 when to use it: 'making it easy to visually spot high-entropy regions that may contain hidden data, encryption, or compression.' It gives a clear use case but does not explicitly state when not to use it or suggest alternatives, though the context implies it is for visual inspection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deep header and structure analysis for known file formats. Parses and displays format-specific header fields including PNG IHDR chunk, JPEG SOF markers, BMP info header, ZIP local file headers, and PDF version/metadata. Provides low-level structural insight.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It details that the tool parses and displays header fields without modifying files, which is good. However, it does not mention limitations (e.g., unsupported formats), performance considerations, or any potential side effects. A 3 reflects adequate but not exceptional 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 two sentences with no wasted words. The first sentence states the purpose, the second provides concrete examples. It is front-loaded and efficiently conveys the tool's capability.
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 moderate complexity, one parameter, and no output schema or annotations, the description covers the key aspects: target formats and parsed data. It lacks specification of the output format (e.g., text or structured data), but overall it is sufficiently complete for agent 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 input schema has high coverage (100%) with a single parameter 'file_path' described as 'Path to file'. The description adds no additional semantic value beyond the schema, so the baseline of 3 is appropriate.
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 ('Parses and displays') and resource ('header fields for known file formats'), and lists specific examples (PNG IHDR, JPEG SOF, BMP info header, ZIP local file headers, PDF version/metadata), distinguishing it from sibling tools like file_identify (format identification) or file_hex (raw hex view).
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 low-level structural insight but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusion criteria. The context is clear, but no direct guidance on choosing among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hex dump with ASCII sidebar display. Shows file contents in traditional hex editor format with offset addresses, hexadecimal byte values, and printable ASCII representation. Useful for manual inspection of binary file structures.
| Name | Required | Description | Default |
|---|---|---|---|
| length | No | Number of bytes to dump (default: 512) | |
| offset | No | Start offset in bytes | |
| file_path | Yes | Path to file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden. It accurately describes the output format (offset addresses, hex bytes, ASCII sidebar) and implies a read-only operation. It does not cover potential edge cases like large files or permissions, but is sufficient for a simple read 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?
Three sentences efficiently convey purpose, format, and use case. No redundant information; 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?
Given the tool's simplicity and full schema coverage, the description is complete. It explains what the tool does, how it displays data, and when it is useful. No output schema is needed as the output is self-explanatory.
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 100% and all parameters have descriptions. The description does not add any additional context beyond what the schema already provides (e.g., byte order, endianness). Baseline 3 is appropriate.
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's a hex dump with ASCII sidebar, showing file contents in traditional hex editor format. It is distinct from sibling tools like file_strings or file_header, which serve different purposes.
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 it is 'useful for manual inspection of binary file structures,' providing some context, but does not explicitly state when not to use it or compare with alternatives. With many sibling tools available, more guidance would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
File type identification via magic bytes. Reads the file header and matches against a comprehensive database of known file signatures. Also checks for extension vs actual type mismatch.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the method (magic bytes, database matching, extension mismatch check). No annotations exist, so description carries full burden; it sufficiently indicates a safe read-only 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?
Two concise sentences covering the core functionality without extraneous 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?
For a simple single-parameter tool, the description covers the main capabilities. Could mention that it returns a file type string or MIME type, but omission is minor.
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 one parameter 'file_path' with schema description 'Path to file'. Tool description does not add further parameter-level detail beyond what the schema provides.
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?
Clearly states it identifies file type via magic bytes and extension mismatch. Distinguishes from siblings like file_header (displays header) and file_compare (compares files).
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 when to use or alternatives, but the purpose is straightforward. Does not mention cases where other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect polyglot files that are valid as two or more different file formats simultaneously. Checks for multiple valid file signatures at different offsets (e.g., PDF+ZIP, PNG+PDF). Useful for CTF challenges and forensic analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Discloses checking multiple file signatures at offsets, a core behavior. However, omits side effects, permissions, or output format (e.g., boolean vs list). Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then examples and use context. No filler, every sentence earns its place.
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, description would benefit from hinting at return type (e.g., 'returns a list of detected formats'). Otherwise, covers the tool's domain well: purpose, method, and typical scenarios.
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 one parameter with schema description 'Path to file'. Tool description adds meaning beyond schema by explaining what the tool does with the file (checks signatures at offsets), though it does not clarify parameter constraints or format. Schema coverage is 100%, so description adds 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?
Description clearly states verb 'Detect' and resource 'polyglot files', defines them as valid in multiple formats simultaneously, and gives examples (PDF+ZIP, PNG+PDF). Distinct from siblings like file_identify or file_embedded.
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?
Mentions use cases (CTF, forensics) but no explicit when-not-to-use or alternatives among many sibling file analysis tools. Implies usage but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract printable and Unicode strings from binary files, similar to the Unix 'strings' command. Scans for runs of printable characters of a configurable minimum length and reports them with their file offsets. Supports ASCII, UTF-8, and UTF-16.
| Name | Required | Description | Default |
|---|---|---|---|
| encoding | No | Encoding to search for (default: ascii) | |
| file_path | Yes | Path to file | |
| min_length | No | Minimum string length (default: 4) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively explains the scanning for runs of printable characters, configurable minimum length, and reporting with file offsets. However, it does not mention performance considerations, file size limits, 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?
Two concise sentences with no redundancy. Front-loaded with the tool's primary action and relevant comparison, making it easy to scan.
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 key aspects: file path, encoding options, minimum length, and output format (offsets). Without output schema, it could specify the exact output structure, but it's sufficient for a straightforward extraction 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?
The description adds context beyond the schema by explaining the overall scanning behavior and offset reporting. Schema coverage is complete, but the description enriches understanding by linking parameters to the extraction process.
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 printable and Unicode strings from binary files, analogous to Unix 'strings', with specific supported encodings. It distinguishes itself from sibling tools that target audio, images, crypto, or documents.
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 via the Unix 'strings' analogy but does not explicitly state when to use it over alternatives. No exclusions or conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze GIF application extensions. Inspects NETSCAPE and other application extension blocks for anomalies or hidden data payloads.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to GIF image file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states 'Analyze' and 'Inspects,' implying a read-only operation, but does not explicitly confirm non-destructiveness, permission requirements, or any side effects. The description is insufficient to fully inform an agent about the tool's behavior, such as whether it modifies the file or requires specific access.
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 sentences, no fluff, and front-loads the core purpose. Every sentence is meaningful and directly related to the tool's function.
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 and the specific domain (GIF steganography), the description is incomplete. It does not describe the output format or what anomalies or hidden data payloads might look like. For a tool with a single parameter and no schema to describe returns, the description should provide more context on what the agent can expect after 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 100% with one required parameter 'file_path' described as 'Path to GIF image file.' The description adds no extra semantics beyond the schema, such as path format, size limits, or file type restrictions. Baseline of 3 is appropriate since the schema already covers the parameter, but the description provides minimal additional 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 the tool analyzes GIF application extensions, specifically NETSCAPE and other blocks, for anomalies or hidden data. The verb 'Analyze' and 'Inspects' combined with the specific resource 'GIF application extensions' makes the purpose precise and distinguishable from sibling tools like gif_comment (which analyzes comments) or gif_structure (which analyzes overall 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?
The description implies usage for analyzing application extensions but does not explicitly state when to use this tool over siblings like gif_comment or gif_palette. It lacks when-not-to-use clauses or alternatives, providing only implicit guidance. For a tool with many siblings, more explicit differentiation would improve the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract and analyze GIF comment extensions. Comments can be used to hide data within a GIF file. Reports all comment text, sizes, and entropy.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to GIF image file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses that reports comment text, sizes, and entropy, but does not clarify if the tool is read-only or if it modifies the file. Missing details about permissions 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?
Two sentences, no unnecessary words. Front-loaded with the main action and details. 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?
Given the tool's low complexity (one param, no output schema), the description covers the essentials: extraction, analysis, and reported attributes. Minor omission: could mention read-only nature, but still adequate.
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 100% with one parameter (file_path) having a description. The description adds no new meaning beyond the schema, as the purpose is already clear from the tool name.
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 and analyzes GIF comment extensions, specifically mentioning data hiding. It distinguishes from siblings like gif_appext or gif_structure by focusing on comments.
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 use for GIF comment analysis but does not explicitly state when to use this tool over alternatives or when not to use it. No exclusions or sibling comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Auto-detect steganography in a GIF file. Analyzes the global color table for LSB patterns, checks for appended data after the trailer, inspects comment extensions, and reports frame count and animation info.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to GIF image file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes key analysis actions but does not explicitly state read-only nature, error conditions, or limitations. With no annotations, the description only partially discloses behavior; the agent must assume non-destructive 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?
Two sentences, front-loaded with purpose, then specific analyses. No redundant information; every sentence adds value. Ideal length for quick comprehension.
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 input and analysis actions but omits output details (format of report, boolean vs. detailed). Since no output schema exists, the description should describe the return value for completeness. Missing this context reduces completeness.
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 one parameter (file_path) with schema description 'Path to GIF image file'. The tool description adds 'GIF file' context but no additional semantics beyond the schema. Schema coverage is 100%, so baseline 3 is appropriate.
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?
Clearly states auto-detection of steganography in GIF files, listing specific techniques (LSB, appended data, comment extensions) and reports (frame count, animation info). Distinguishes from sibling tools like gif_frame_analysis or gif_palette_lsb.
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. Does not mention when not to use it or suggest specialized tools for specific stego types, leaving the agent to infer from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze multi-frame GIF animation properties. Reports per-frame size, delay times, disposal methods, local color tables, and anomalies in frame dimensions or compression.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to GIF image file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It lists reported properties but does not state whether the tool is read-only, requires permissions, or has side effects. The analytical nature is implied but not confirmed.
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 succinct sentences, front-loaded with purpose and followed by specific attributes. No redundant 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?
With one parameter and no output schema, the description covers core functionality but lacks details on error scenarios, file constraints, or return format. Adequate but not comprehensive.
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 one parameter with schema description covering 100%. Description adds no extra meaning beyond 'Path to GIF image file', so baseline 3 is appropriate.
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 verb 'Analyze' and resource 'multi-frame GIF animation properties', listing specific reported attributes. This distinguishes it from siblings like gif_structure or gif_detect by focusing on animation-specific frame details.
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 usage for multi-frame GIF animation analysis, but no explicit guidance on when not to use (e.g., static GIFs) or how it differs from other GIF tools among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze LZW compressed sub-block sizes and entropy in GIF image data. Checks individual sub-block sizes for anomalies and patterns that may indicate steganographic manipulation of the compressed stream.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to GIF image file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It describes the analysis behavior (checking sub-block sizes and entropy for anomalies) but does not explicitly state whether the tool is read-only, requires permissions, or has any side effects. The behavioral traits are adequately implied but not fully disclosed.
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 that front-load the action ('Analyze...') and add purpose ('Checks... for anomalies...'). Every sentence provides value; no fluff or 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 one parameter, no output schema, and simple analysis purpose, the description is mostly complete. It explains what the tool does and why (steganography detection). Minor gap: could mention output format briefly, but not critical for this 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 coverage is 100% with a clear description for file_path. The tool description does not add additional meaning beyond what the schema already provides (path to GIF file). Per rules, baseline 3 is appropriate.
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 analyzes LZW compressed sub-block sizes and entropy in GIF images, with a specific focus on detecting steganographic manipulation. This verb+resource combination distinguishes it from sibling tools like gif_frame_analysis or gif_palette, which do not mention LZW analysis.
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 the tool is for detecting steganography in GIF LZW streams ('may indicate steganographic manipulation'), but it does not explicitly state when to use it versus alternatives or provide exclusion criteria. No guidance on prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze the GIF global color table for steganographic indicators. Reports sort order, duplicate entries, unused slots, color distribution, and luminance profile.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to GIF image file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively discloses behavioral traits: it is a read-only analysis tool that reports specific metrics (sort order, duplicates, etc.). No side effects or contradictions are noted, and the description sufficiently informs the agent of expected 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, using two sentences to convey the core purpose and details. It is front-loaded with the key action and avoids unnecessary verbiage. Every sentence provides 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 simple single-parameter tool, the description is nearly complete. It lists what the report covers (color distribution, luminance profile, etc.), which compensates for the lack of an output schema. Minor omission: it does not specify the output format (e.g., text report), but this is not critical.
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 sole parameter 'file_path' is described in the schema as 'Path to GIF image file'. The description adds no further semantics beyond this, and schema coverage is 100% for the single parameter. Baseline 3 is appropriate since the description does not enhance parameter 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 clearly states the tool's purpose: analyzing the GIF global color table for steganographic indicators. It specifies what it reports (sort order, duplicate entries, etc.) and distinguishes itself from sibling tools like gif_palette_lsb by focusing on global table analysis.
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 steganographic analysis of GIF color tables but does not provide explicit guidance on when to use this tool versus alternatives. No 'when-not' conditions or alternative tool names are mentioned, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract and analyze LSB patterns from GIF color table entries. Reports per-channel LSB bit strings, balance ratios, and chi-square test results for LSB uniformity.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to GIF image file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits beyond its function (e.g., read-only nature, permissions, side effects). It only states what it reports, not how it operates.
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, front-loaded sentences with no redundant information. The first sentence states the action, the second lists outputs.
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 adequately summarizes the output format and content. It clarifies the scope (GIF color table entries), which is useful among many steganalysis tools.
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 one parameter (file_path) with 100% schema description coverage. The description adds no extra semantics beyond the schema, so baseline of 3 is appropriate.
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 and analyzes LSB patterns from GIF color table entries, listing specific outputs (per-channel bit strings, balance ratios, chi-square test results). This distinguishes it from siblings like gif_palette or img_lsb_detect.
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 (e.g., img_lsb_detect for generic images). The description doesn't mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Visualize the GIF block structure. Shows all blocks (header, color tables, extensions, image descriptors, trailer) with offsets and sizes for forensic analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to GIF image file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states 'visualize' and 'shows' implying a read-only operation, but does not explicitly confirm non-destructiveness or disclose any behavioral traits such as permissions 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?
Two concise sentences with front-loaded purpose and immediate detail. 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?
For a single-parameter tool without output schema, the description effectively conveys inputs and high-level output (blocks with offsets/sizes). Slightly abstract about the output format, but sufficient for a visualization 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 100% with file_path described as 'Path to GIF image file'. The description adds no additional meaning beyond the schema, warranting the baseline score of 3.
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 uses a clear verb (visualize) and specific resource (GIF block structure). It lists concrete block types and mentions offsets/sizes for forensic analysis, distinguishing it from siblings like gif_frame_analysis or gif_lzw_analysis.
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 forensic analysis of GIF structure but provides no explicit guidance on when to use this tool versus alternatives like gif_structure vs gif_detect or gif_frame_analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect and extract data appended after the image EOF marker. Checks for hidden data past PNG IEND, JPEG EOI, or BMP file size boundary.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to image file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that it checks for hidden data past specific markers, but does not describe whether it modifies files, required permissions, or output format. Lacks details on error handling when no data found.
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 purpose and specific details. No superfluous 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 no output schema, description lacks return value information (e.g., boolean or extracted data). For a simple single-param tool, it is mostly adequate but missing output context.
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?
Single parameter file_path with full schema coverage. Description does not add significant meaning beyond 'Path to image file' already in schema. Mentions supported formats but that is general behavior, not parameter-specific.
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 verb (detect and extract), resource (data appended after image EOF marker), and specifies file types (PNG, JPEG, BMP). Distinguishes from sibling tools like img_lsb_detect by focusing on post-EOF data.
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 usage for detecting hidden data after EOF, but does not explicitly state when to use this vs alternatives (e.g., other steganography tools). No when-not or alternative mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract and visualize a specific bit plane from an image channel. Shows dimensions, percentage of 1-bits, and an ASCII art preview of the first rows.
| Name | Required | Description | Default |
|---|---|---|---|
| plane | No | Bit plane 0-7 (default: 0=LSB) | |
| channel | No | Channel: 0=R, 1=G, 2=B, 3=A (default: 0=Red) | |
| file_path | Yes | Path to image file |
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 mentions outputs but does not state whether the tool modifies the image, requires permissions, or has side effects. As a likely read-only tool, this omission is a notable gap.
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 clear sentences, front-loaded with the main action, no wasted words. An example of effective conciseness.
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?
No output schema exists, so the description must convey return values. It mentions dimensions, percentage, and ASCII preview, which covers the main outputs, but it is unclear whether the extracted bit plane image data is also returned. Adequate 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?
Schema description coverage is 100%, so baseline is 3. The description adds general context about extraction and visualization but does not provide extra meaning beyond what the schema's parameter descriptions already offer.
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 extracts and visualizes a specific bit plane from an image channel, and lists what it shows (dimensions, percentage, ASCII preview). However, it does not distinguish itself from sibling tools like img_lsb_extract which also deal with bit planes.
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. The description implies use for bit plane analysis but provides no context on prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-channel statistical analysis for R, G, B, and A channels. Reports mean, standard deviation, entropy, min, max, and unique value count for each channel.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to image file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It indicates the tool is read-only ('reports') and processes each channel individually, but does not detail handling of missing channels, file size limits, or side effects. It adds basic context but is 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 two sentences: first states the purpose, second lists outputs. Front-loaded and without extraneous words. 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 simple tool with one parameter and no output schema, the description adequately explains the analysis performed and the statistics computed. It is missing details on output format and error conditions, but given the low complexity, it is nearly 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?
Schema description coverage is 100% (file_path described as 'Path to image file'). The description does not add further parameter semantics, such as accepted formats or handling of non-image files. Baseline of 3 applies per rule.
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 performs per-channel statistical analysis for R, G, B, and A channels and lists the reported statistics (mean, std, entropy, min, max, unique count). This verb+resource combination is specific and distinguishes it from sibling tools like img_histogram or img_entropy_map.
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 lacks any guidance on when to use this tool vs. alternatives such as img_histogram or img_bitplane. It does not mention explicit conditions for its use or exclude cases like grayscale images.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Chi-square steganalysis attack on each color channel independently. Detects LSB replacement by testing whether adjacent pixel value pairs are equalized.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to image file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the detection mechanism (testing equalization of adjacent pixel values) but does not describe the output format, return type, or behavior for non-stego images. This is a meaningful but incomplete behavioral disclosure.
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 with no redundancy. First sentence states the tool's identity, second explains the detection method. Every word earns its place.
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 single-parameter detection tool, the description explains the technique but omits the expected output (e.g., boolean, score, detailed report). Given no output schema, this is a notable gap in completeness.
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?
There is only one parameter (file_path) with schema description 'Path to image file'. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate with no 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 identifies the tool as a chi-square steganalysis attack for detecting LSB replacement, working on each color channel independently. It uses specific verb 'detects' and resource 'LSB replacement', and distinguishes from siblings like img_lsb_detect and img_rs_analysis by specifying the technique.
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 the tool should be used when LSB replacement detection is needed, but it does not provide explicit guidance on when to use this tool over alternatives (e.g., RS analysis, ensemble methods) or any exclusion criteria. Usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pixel-by-pixel comparison of two images. Reports identical/different pixel counts, max difference, and which channels are affected. Useful for detecting steganographic modifications.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path_1 | Yes | Path to first image file | |
| file_path_2 | Yes | Path to second image file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description transparently explains the tool's behavior: it performs pixel-by-pixel comparison and reports quantitative results. It does not mention side effects or access requirements, but the tool is inherently read-only and non-destructive.
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, consisting of three sentences with no redundancies. Every sentence adds essential information: operation, output details, and use case.
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 simple two-parameter tool with no output schema, the description is mostly complete, covering what it does and what it reports. However, it omits prerequisites like same image dimensions or format, which could affect 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?
Both parameters have schema descriptions ('Path to first image file', 'Path to second image file') providing full coverage. The description adds context by tying parameters to the comparison operation but does not add new semantic details beyond what the schema already provides.
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 verb (pixel-by-pixel comparison) and resource (two images), and specifies the outputs (identical/different pixel counts, max difference, affected channels). It distinguishes from sibling tools like img_lsb_detect by focusing on general pixel-level comparison for steganography detection.
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 indicates usefulness for detecting steganographic modifications, providing a use case. However, it does not explicitly guide when to use this tool over alternatives like img_lsb_detect or img_chi_square, nor does it state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Auto-detect steganography in an image. Runs chi-square, RS analysis, entropy, metadata, appended data, and tool signature checks. Returns a comprehensive JSON report.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to image file |
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 the tool runs multiple non-destructive analyses and returns a JSON report. It does not mention any destructive actions or side effects, which is appropriate for a read-only detection 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?
Two concise sentences: the first states the purpose, and the second lists the methods and output. No superfluous words, and the structure is front-loaded with the key action.
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 mentions the return of a comprehensive JSON report, which is valuable despite no output schema. For a detection tool with multiple built-in algorithms, it provides sufficient context for an agent to understand the tool's capabilities, though it could hint at report structure.
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 only parameter is 'file_path' with a schema description of 'Path to image file'. The description does not add additional meaning such as supported formats or size limits. Since schema coverage is 100%, a baseline score of 3 is appropriate.
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 detects steganography in images using multiple methods like chi-square, RS analysis, entropy, metadata, appended data, and tool signature checks. It distinguishes itself from sibling tools like img_chi_square or img_rs_analysis by being a comprehensive detection tool.
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 comprehensive steganography detection but does not explicitly state when to use it versus alternatives, nor does it provide exclusions or prerequisites. The list of methods gives context, but without direct guidance, the agent must infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-block entropy analysis of an image. Splits the image into blocks and calculates Shannon entropy per block, flagging high-entropy regions that may contain hidden data.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to image file | |
| block_size | No | Block size in pixels (default: 64) |
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 the algorithm steps (splitting into blocks, calculating entropy, flagging high-entropy regions) but does not mention the output format, whether it returns an image or data, or any side effects. The mutability is implied as read-only but not stated.
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, concise and without fluff. It efficiently conveys the purpose and method. However, it could benefit from a slightly more explicit structure, such as indicating the output type.
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, the description should at least hint at the return format (e.g., a heatmap image, coordinates list). It only says 'flagging high-entropy regions' without specifying how. Additionally, no information about supported image formats or error handling is provided. The tool's context is moderately covered.
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 100%, so baseline is 3. The description adds context that block_size controls the size of blocks for entropy calculation but does not add significant semantics beyond what the schema already provides for the 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 performs per-block entropy analysis on an image, calculating Shannon entropy and flagging high-entropy regions. It uses a specific verb-resource combination and distinguishes itself from sibling tools like file_entropy (overall file entropy) and img_chi_square (chi-square analysis).
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 detecting hidden data via entropy analysis but does not explicitly say when to use this tool versus alternatives like img_lsb_detect or img_rs_analysis. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a pixel value histogram with anomaly detection. Detects Pairs-of-Values (PoV) anomalies that indicate LSB steganography.
| Name | Required | Description | Default |
|---|---|---|---|
| channel | No | Channel: 0=R, 1=G, 2=B, 3=A (default: all RGB combined) | |
| file_path | Yes | Path to image file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description carries full burden. It discloses the detection technique (PoV) and purpose but does not mention side effects, permissions, or output format. Adequate for a read-only analysis tool, but could add reassurance that it does not modify files.
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, no fluff. First sentence states main purpose, second adds specific anomaly detection detail. Ideal conciseness for a straightforward tool.
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?
No output schema defined, yet description fails to specify what the tool returns (histogram data, anomaly flags, or visual output). Without this, an AI agent cannot properly interpret the tool's results. Also lacks context on when to choose this over similar siblings like img_chi_square or img_rs_analysis.
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 100% with both parameters fully described. The description adds no additional meaning beyond the schema's own descriptions for 'file_path' and 'channel'. Baseline 3 is appropriate.
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 verb 'generate' and resource 'pixel value histogram with anomaly detection'. It specifies the detection method (PoV) and target (LSB steganography), distinguishing it from sibling tools like img_chi_square and img_rs_analysis.
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 usage: detect LSB steganography via histogram anomalies. No explicit 'when to use' or 'when not to use', nor alternatives mentioned. Context is clear but lacks guiding boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan image file bytes for known steganography tool signatures. Checks against a database of known patterns from tools like OpenStego, Steghide, JSteg, F5, and others.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to image file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the tool 'scans' bytes, suggesting a read-only operation, but does not disclose whether it modifies the file, requires permissions, or handles errors. It is 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 two concise sentences, front-loaded with the main purpose. Every sentence adds value, with no wasted words or 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 an output schema, the description should explain what the tool returns (e.g., list of signatures found). It only describes the input and process, leaving the agent guessing about the output format or success indication.
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 100%, and the description adds little beyond the schema's description of file_path. The description mentions 'image file' but does not provide additional constraints or formatting details, so it meets the baseline without exceeding it.
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 uses the specific verb 'Scan' and resource 'image file bytes for known steganography tool signatures'. It lists example tools like OpenStego, Steghide, etc., which clearly distinguishes this from sibling tools like img_lsb_detect or img_chi_square that use different detection methods.
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 this tool is for detecting known tool patterns, which contrasts with statistical or LSB-based detection among siblings. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or context like best-suited scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Statistical LSB steganography detection. Runs chi-square and sample pair analysis on each color channel independently.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to image file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description must cover behavior. Discloses use of two statistical analyses per color channel independently, but fails to state whether the tool is read-only or what side effects exist. Moderate disclosure.
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, efficient and front-loaded with core purpose. No extraneous 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?
Lacks output description. For a detection tool, it is crucial to describe what result is returned (e.g., probability scores, detection flags). No output schema exists, so the description should compensate. 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?
Schema covers file_path with a basic description. The tool description does not add any additional meaning about the parameter, such as supported file formats or path requirements. Baseline 3 is appropriate.
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?
Describes specific verb (detect) and resource (LSB steganography). Differentiates from sibling tools like img_lsb_embed and img_lsb_extract by focusing on detection. The mention of specific methods (chi-square, sample pair) adds clarity.
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 when-to-use or alternatives provided. The description does not differentiate from other detection tools like img_chi_square or img_rs_analysis, leaving the agent without guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Embed a message into an image using LSB steganography. Reads a PNG file, embeds the message into the least significant bits, and writes a new PNG file.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | Message to embed | |
| channels | No | Channels to embed into: r,g,b,a (default: r,g,b) | |
| file_path | Yes | Path to source PNG image file | |
| output_path | Yes | Output file path for the stego image |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It discloses file operations but omits details like maximum embeddable message size, effect on image pixels, or any irreversible changes.
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 with no filler. The first sentence defines the action, the second adds process detail, achieving maximum efficiency.
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 tool with 4 parameters and no annotations or output schema, the description covers the main action but lacks critical context like message capacity, requirements for source image, or behavior on failure.
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?
Parameter descriptions in the schema already explain each field (e.g., 'message' as 'Message to embed'). The description adds no new per-parameter meaning, meeting the baseline for 100% 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 states the tool's purpose: embedding a message into an image using LSB steganography. It specifies the file type (PNG) and the process (reads, embeds, writes), effectively distinguishing it from sibling tools like img_lsb_extract.
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 hiding messages but provides no explicit guidance on when to use this tool versus alternatives (e.g., img_lsb_detect or extract) or conditions like message size limits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract hidden data from image LSBs. Extracts bits from specified channels and bit plane, attempts UTF-8 decode, and shows hex dump.
| Name | Required | Description | Default |
|---|---|---|---|
| order | No | Pixel traversal order (default: row) | |
| channels | No | Channels to extract from: r,g,b,a (default: r,g,b) | |
| bit_plane | No | Bit plane 0-7 (default: 0=LSB) | |
| file_path | Yes | Path to image file | |
| max_bytes | No | Max bytes to extract (default: 8192) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states it extracts bits, attempts UTF-8 decode, and shows hex dump, but lacks details on failure behavior, performance, or side effects. Adequate but not thorough.
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 extraneous words. First sentence states purpose, second expands on behavior with key details (channels, bit plane, decode, hex dump). Front-loaded 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?
Given 5 parameters, no output schema, and many siblings, description covers core functionality but omits output structure and error conditions. It adds value with decode and hex dump context, but could be more 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?
Schema description coverage is 100%, so baseline is 3. Description adds context about extracting from specified channels and bit plane, but this closely mirrors schema descriptions. The mention of UTF-8 decode and hex dump relates to output, not parameter semantics.
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 'Extract hidden data from image LSBs', a specific verb+resource. It distinguishes from siblings like img_lsb_detect (detection) and img_lsb_embed (embedding) by focusing on extraction and mentioning output details like hex dump and UTF-8 decode.
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?
Description does not provide explicit when-to-use or when-not-to-use guidance. Usage is implied for extraction of hidden LSB data, but no comparison with alternatives like img_lsb_detect or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deep metadata extraction from an image. For PNG: extracts text chunks, chunk list, IHDR info. For JPEG: extracts EXIF, comments, quantization tables, marker list.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to image file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It lists extracted elements for PNG and JPEG, indicating a read-only operation, but omits potential limitations (e.g., file size, supported formats beyond PNG/JPEG) 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?
The description is concise, with two clear sentences that front-load the main purpose before detailing format-specific extraction. No wasted words, though it could be slightly more 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 a single parameter and no output schema, the description adequately covers PNG and JPEG but omits other image formats and does not hint at the return structure or potential performance considerations.
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 100% for the sole parameter (file_path). The description adds no additional meaning beyond what the schema provides, so baseline score of 3 applies.
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: 'Deep metadata extraction from an image.' It specifies distinct operations for PNG and JPEG formats, making it specific and distinguishable from sibling tools like img_detect or jpeg_exif_deep.
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 what the tool does but does not provide explicit guidance on when to use it versus alternatives (e.g., jpeg_exif_deep for deeper JPEG EXIF). Usage context is implied but not directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
RS (Regular-Singular) steganalysis using the Fridrich-Goljan-Du method. Analyzes pixel groups to estimate LSB embedding rate per channel.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to image file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals the method (RS analysis) and output (LSB embedding rate per channel), but with no annotations, it fails to disclose whether the tool modifies the image, expected return format, error handling, or format restrictions. This is adequate but not fully transparent.
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 deliver the essential technical method and purpose without extraneous text. Front-loading the method name followed by a brief explanation is efficient and easy to parse.
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 simple tool with one parameter and no output schema, the description covers the core functionality adequately. However, the lack of output format description (e.g., numeric rates per channel) leaves minor ambiguity about what the agent receives.
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 single parameter file_path is fully described in the input schema. The description adds no further details about file format constraints, size limits, or examples, which is acceptable given 100% schema coverage, but no 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 explicitly states the tool performs RS steganalysis using the Fridrich-Goljan-Du method, analyzing pixel groups to estimate LSB embedding rate per channel. This clearly distinguishes it from sibling tools like img_lsb_detect or img_chi_square.
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 vs. alternative steganalysis methods (e.g., img_chi_square, img_lsb_detect). The description lacks context on prerequisites, typical use cases, or limitations, leaving the agent to infer usage without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crop-recalibrate steganalysis. Crops the image by removing a few pixel rows/columns to break DCT block alignment, then compares DCT and pixel statistics between the original and calibrated version. Steganographic modifications are revealed because recalibration restores natural statistics that embedding had disrupted.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the JPEG file for calibration-based steganalysis | |
| crop_pixels | No | Number of pixels to crop from edges to break DCT alignment (default: 4) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explains the behavior: cropping to break DCT alignment and comparing statistics to reveal steganography. However, it omits potential limitations, false positives, or output format, which is needed for a detection 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 two sentences long, front-loads the purpose, and every sentence adds value. It is concise without 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 complexity of steganalysis and the absence of an output schema, the description fails to indicate what the tool returns (e.g., a boolean detection result, a confidence score, or statistical data). Also missing are prerequisites or caveats, leaving the agent underinformed about how to use the output.
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 100%, so the baseline is 3. The description adds minimal extra meaning beyond the schema, only implicitly referencing crop_pixels by mentioning 'removing a few pixel rows/columns'. It does not elaborate on file_path or further clarify parameter usage.
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: 'Crop-recalibrate steganalysis.' It specifies the action (crop and compare statistics) and the resource (JPEG image), and the technique distinguishes it from sibling jpegadv detection tools like jpegadv_f5_detect and jpegadv_jsteg_detect.
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 general steganalysis detection but does not explicitly state when to use this tool versus alternatives (e.g., other jpegadv detection methods). No exclusions or context for choosing this method are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sliding window chi-square analysis over sequential DCT coefficients. Divides the coefficient stream into windows of configurable size and runs chi-square pair analysis on each window. Returns per-window p-values and detection results to map where embedding starts and stops.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the JPEG file for sliding window chi-square analysis | |
| window_size | No | Number of coefficients per window (default: auto-calculated from file size) | |
| window_count | No | Number of windows to divide the data into (default: 20, max: 50) |
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 the analysis process ('divides... runs chi-square pair analysis') and outputs, but does not disclose read-only nature, performance implications, or other behavioral traits beyond the core functionality.
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, ~50 words, front-loaded with the main purpose. No unnecessary information; every sentence contributes to understanding the tool's function and output.
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 states what the tool does and what it returns, which is adequate for a moderately complex steganalysis tool. However, it lacks detail on the output format (e.g., structure of p-values or detection results) that an agent might need to interpret the results.
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 100% with parameter descriptions. The description adds value by explaining how parameters are used in the algorithm ('configurable size', 'runs chi-square pair analysis on each window'), providing context beyond the schema's basic definitions.
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 performs 'sliding window chi-square analysis over sequential DCT coefficients' and specifies the output ('per-window p-values and detection results'). This distinguishes it from siblings like 'img_chi_square' and other jpegadv tools by focusing on sliding window and DCT coefficients.
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 'jpegadv_f5_detect' or 'jpegadv_jsteg_detect'. The phrase 'to map where embedding starts and stops' implies a specific use case but does not provide 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.
JPEG stego tool compatibility check. Analyzes the image to determine which steganography tools could have been used based on its properties: color space, quality factor, progressive vs baseline encoding, marker structure, quantization tables, and metadata patterns.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the JPEG file for stego tool compatibility analysis |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for transparency. It discloses that the tool analyzes properties and lists them, suggesting a read-only operation. However, it does not explicitly state that no modifications are made, nor does it mention any prerequisites 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 two sentences. The first sentence states the purpose directly, and the second provides essential detail on what is analyzed. No extraneous information or 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?
While the description explains the analysis scope, it does not mention the output format or how results are presented (e.g., list of tools, confidence scores). Given the complexity of compatibility analysis and lack of output schema, this omission limits the agent's ability to interpret results accurately.
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 100% with a clear description of the single parameter 'file_path'. The tool description adds minimal value beyond the schema, merely confirming the file type (JPEG) without adding constraints, format specifics, or examples.
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: a JPEG stego tool compatibility check that analyzes image properties to determine which steganography tools could have been used. It provides specific details on analyzed properties (color space, quality factor, etc.), effectively distinguishing it from sibling tools that focus on specific detection or structure analysis.
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 initial assessment of potential stego tools, but it does not provide explicit guidance on when to use this tool versus specific sibling detectors (e.g., jpegadv_f5_detect). No exclusion criteria or alternatives are mentioned, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
F5 steganography detection. F5 embeds data by decrementing the absolute values of DCT coefficients toward zero (shrinkage). Detects the characteristic excess of zeros relative to near-zero coefficients and the histogram dip at +/-1 that F5 matrix embedding produces.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the JPEG file to analyze for F5 steganography |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the full burden. It explains the detection logic but does not disclose whether the tool modifies the file, requires specific file attributes, or describes side effects. An agent needs to infer read-only behavior from context.
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: first states purpose, second provides technical mechanism. No wasted words, front-loaded with essential 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?
Adequately explains what is detected and how, but does not specify the output format (e.g., boolean, confidence score, or evidence). For a complex detection tool, this omission may require the agent to assume standard output conventions.
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?
Single parameter 'file_path' is fully described in the schema (absolute path to JPEG file). The description adds no additional meaning beyond the schema's parameter description. Baseline score of 3 is appropriate due to complete 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?
Description clearly states it detects F5 steganography, explains the embedding technique (decrementing DCT coefficients) and the detection method (excess zeros, histogram dip). Distinguishes from sibling tools like jpegadv_jsteg_detect by specifying F5-specific signs.
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 (e.g., other JPEG steganography detectors). Does not mention prerequisites or false positive considerations. Adequate for a direct detection task but lacks comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
JSteg steganography detection. JSteg replaces the LSB of non-zero, non-one DCT coefficients. Uses chi-square test on coefficient value pairs (2k, 2k+1) to detect the equalization that JSteg embedding produces. Includes sliding window analysis on sequential AC coefficients.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the JPEG file to analyze for JSteg steganography |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides good technical detail about the detection mechanism (chi-square test on DCT coefficient pairs, sliding window analysis) and explains what JSteg embedding does. However, it does not discuss potential false positives, detection thresholds, or reliability limitations.
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: three sentences each serving a distinct purpose (purpose, mechanism, additional analysis feature). No redundant or irrelevant 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?
The description omits critical context: there is no output schema or annotation, yet the description does not explain what the tool returns (e.g., boolean, confidence score, detailed report). It also fails to mention error conditions or prerequisites (e.g., valid JPEG file).
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 only parameter, file_path, is fully described in the input schema. The description adds no further meaning beyond the schema, which is already clear. With 100% schema coverage, a baseline score of 3 is appropriate.
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 identifies the tool as a JSteg steganography detector, explains the embedding technique (LSB of non-zero, non-one DCT coefficients), and specifies the detection method (chi-square test on coefficient pairs). This differentiates it from sibling tools like jpegadv_f5_detect or jpegadv_outguess_detect.
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 the tool is for detecting JSteg, but it does not explicitly state when to use it vs. alternatives (e.g., other steganography detection tools) nor when it is not appropriate. No contraindications or required conditions (like file validity) are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
OutGuess steganography detection. OutGuess embeds data in DCT coefficients and adjusts unused coefficients to preserve first-order statistics. Detects by analyzing second-order statistics (inter-block coefficient correlations) that OutGuess disrupts, and checks for preserved histogram with disrupted spatial correlations.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the JPEG file to analyze for OutGuess steganography |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the internal detection method (second-order statistics, histogram preservation), which provides some behavioral insight. However, it does not state external behaviors like whether the tool is read-only, or what it returns (e.g., boolean, confidence). With no annotations provided, the description should have covered these aspects more thoroughly.
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, no wasted words. The first sentence states the purpose, the second adds technical context. It is front-loaded 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?
Given the tool's complexity (steg detection), the description omits critical information about return values or output format. Without an output schema, the agent cannot know what to expect from the tool, making it incomplete for practical use.
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 single parameter 'file_path' is fully described in the schema (100% coverage). The description adds no additional semantic detail beyond the schema, so the baseline score of 3 is appropriate.
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 detects OutGuess steganography in JPEG files, with a specific verb ('detection') and resource. It explains the detection methodology, distinguishing it from sibling tools that target different steganography methods like F5 or JSteg.
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 lacks any explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, false positives, or situations where other detection tools might be more appropriate, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pixel Value Differencing (PVD) steganography detection applied to JPEG. PVD encodes data in the differences between adjacent pixel values. Detects by analyzing the distribution of pixel differences for the staircase pattern at PVD range boundaries (Wu-Tsai ranges). Works on decoded pixel data via jpeg-js.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the JPEG file to analyze for PVD steganography |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It explains the detection method but omits critical details: what the output looks like (e.g., boolean, confidence score), whether the tool is purely read-only, and any side effects or requirements (e.g., decompression overhead). The agent is left unsure how to interpret results.
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 at two sentences, no wasted words. It front-loads the core purpose and then adds technical detail. Slightly technical language may be less accessible, 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 tool has a single parameter and no output schema, the description should elaborate on return values or how to interpret detection results. The agent lacks information on success/failure conditions, output format, or false positive considerations, making it incomplete for effective 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 100% with a clear description of file_path. The tool description adds little beyond restating 'JPEG file to analyze,' which is already in the schema. Baseline score of 3 is appropriate as the schema does the heavy lifting.
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 detects PVD steganography in JPEG files, specifying the method (analyzing pixel difference distributions for staircase patterns) and that it works on decoded pixel data via jpeg-js. It is specific and distinguishable from siblings by its focus on PVD, though it does not explicitly contrast with other jpegadv detect 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 no guidance on when to use this tool versus alternatives (e.g., jpegadv_f5_detect, jpegadv_jsteg_detect). It does not mention prerequisites, limitations, or contexts where PVD detection is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract and analyze JPEG COM (comment) markers. Checks for hidden data patterns, unusually large comment segments, and high-entropy content that could indicate steganographic payloads concealed in comment fields.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to JPEG file for comment analysis |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description offers partial behavioral context (checks for hidden data, large segments, high entropy), but lacks details on read-only status, error handling, 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?
The description is two sentences, front-loading the core action, with no superfluous 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?
The description covers purpose and analysis targets but lacks details on return values, which is significant given 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?
Schema coverage is 100% and the description adds no extra meaning beyond the schema's parameter description, resulting in baseline score.
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 and analyzes JPEG COM markers for steganographic payloads, specifying a unique verb-resource combination that distinguishes it from sibling tools like jpeg_exif_deep or jpeg_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?
The description implies usage when steganography in JPEG comments is suspected, but does not explicitly compare with siblings or state when to avoid using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DCT coefficient distribution analysis for steganography detection. Analyzes the Y-channel pixel value distribution and SOS entropy data to detect anomalies caused by DCT-domain stego tools like JSteg, F5, and OutGuess.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to JPEG file to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It describes what is analyzed but fails to mention that the tool is read-only, any prerequisites, or output format. Key behavioral details like potential side effects or limitations are missing.
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, front-loaded with the core purpose. 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?
For a simple tool with one parameter, no output schema, and no annotations, the description provides enough context to understand the tool's function and target. However, it could mention output type or expected results.
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 100% for the single parameter (file_path). The description does not add additional meaning beyond the schema's 'Path to JPEG file to analyze'. Baseline 3 is appropriate.
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 analyzes DCT coefficient distribution for steganography detection, specifying Y-channel and SOS entropy, and names specific stego tools (JSteg, F5, OutGuess). This is a specific verb+resource that distinguishes it from spatial-domain or other JPEG analysis siblings.
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 DCT-domain stego detection but does not explicitly state when to use this tool versus alternatives (e.g., img_lsb_detect, img_chi_square). No exclusions or context for selection are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect double JPEG compression artifacts. Double compression occurs when a JPEG is decoded and re-encoded, which introduces characteristic blocking artifacts and quantization table anomalies — a common indicator of image tampering or steganographic embedding.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to JPEG file to analyze for double compression |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions detection artifacts and anomalies but does not disclose output format, side effects, or error handling. More behavioral context is needed.
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, no wasted words. First sentence states action, second provides technical rationale and use cases.
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 simple single-parameter detection tool, the description covers purpose, technical basis, and use cases. Missing return format details, but overall adequate.
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 100% and the parameter description 'Path to JPEG file to analyze for double compression' is already clear. The tool description adds context about why detection matters but does not significantly enhance parameter 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 the tool detects double JPEG compression artifacts, explains the underlying mechanism, and ties it to image tampering and steganography. It uses a specific verb 'detect' and distinguishes from sibling JPEG tools like jpeg_quantization or jpeg_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?
The description implies usage for tampering and steganography detection but does not explicitly state when to use or not use this tool, nor does it mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deep EXIF analysis including GPS coordinates, timestamps, software info, thumbnails, maker notes, and all IFD entries. Flags interesting fields for forensic investigation such as editing software traces, GPS location, and temporal inconsistencies.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to JPEG file for deep EXIF analysis |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description effectively discloses behavioral traits: it returns deep EXIF data and flags forensic items. Assumes read-only 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?
Two sentences, front-loaded with purpose, no extraneous 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?
Lacks output format or structure description, which is needed since no output schema is provided. Otherwise covers inputs adequately.
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 one parameter with 100% schema coverage; description does not add significant meaning beyond naming the file path, but it is consistent and adequate.
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?
Clearly states it performs deep EXIF analysis, listing specific components like GPS, timestamps, and forensic flags. Distinguishes from siblings such as img_metadata and jpeg_comment.
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 use for forensic deep EXIF analysis but lacks explicit guidance on when to use vs alternatives, or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quantization table analysis with quality estimation. Displays all quantization tables in 8x8 grid format and estimates the JPEG quality factor by comparing against the standard luminance/chrominance tables — essential for forensic analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to JPEG file for quantization analysis |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes output format (8x8 grid) and estimation of quality factor. No annotations provided, so description carries burden. Does not mention any side effects or limitations beyond the analysis scope, but is adequate for a read-only forensic 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?
Single sentence conveying two key actions (display tables, estimate quality). Slightly verbose with 'essential for forensic analysis' but overall concise 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?
For a simple tool with one parameter and no output schema, the description adequately explains what it does and the format of results. No missing critical information for an AI agent to invoke it 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 100% with a single parameter (file_path) whose description is sufficient. The tool description does not add additional semantic meaning beyond the schema; baseline score of 3 applies.
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?
Clearly states it performs quantization table analysis with quality estimation. Distinct from sibling JPEG tools like jpeg_structure or jpeg_dct_histogram by focusing on quantization tables and quality factor estimation.
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?
Mentions 'essential for forensic analysis' as context, but does not explicitly specify when to use over alternatives or when not to use. Lacks exclusion criteria or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse JPEG markers/segments with offsets and sizes. Shows the internal structure of a JPEG file including all markers, their positions, and segment lengths — useful for identifying hidden data or anomalous segments.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to JPEG file to analyze |
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 the tool outputs offsets, sizes, positions, and segment lengths, which are behavioral details beyond a generic parse. However, it does not mention whether the tool is read-only, required permissions, or any side effects like file modification. For a read-only analysis tool, the description provides moderate 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?
Two sentences: the first clearly states the action and output components, the second adds context and use case. No wasteful words, information is front-loaded, and 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 simple tool with one parameter, no output schema, and no annotations, the description covers the essentials. It explains what the tool outputs (markers, positions, sizes) and why it's useful. Lacks mention of JPEG variants (e.g., JPEG 2000) but is otherwise 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 one parameter (file_path) exists with full schema coverage (100%). The description's 'Path to JPEG file to analyze' matches the schema and adds no extra meaning or constraints (e.g., file size limits, supported paths). Baseline score of 3 is appropriate given complete 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 verb (Parse) and resource (JPEG markers/segments with offsets and sizes). It details the output (internal structure, markers, positions, segment lengths) and use case (identifying hidden data or anomalous segments), distinguishing it from siblings like jpeg_comment or jpeg_dct_histogram.
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 use for structural analysis and hidden data detection, but does not explicitly state when to use this tool over alternatives (e.g., jpeg_comment for comment extraction, jpeg_dct_histogram for DCT analysis). No when-not-to-use guidance or prerequisite conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare the EXIF thumbnail against the main JPEG image. A dimension or content mismatch between the thumbnail and the main image is a strong indicator that the main image was modified after capture while the original thumbnail was preserved — a common forensic artifact.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to JPEG file for thumbnail comparison |
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 the tool compares thumbnail and main image, which is non-destructive. It does not mention limitations or permissions, but the behavior is straightforward.
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: first states the action, second explains the forensic significance. No filler or 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?
For a one-parameter tool with no output schema, the description adequately explains what the tool does and what the result implies. It could mention the return format, but the interpretation is provided.
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 single parameter 'file_path' has a schema description that already states its purpose. The tool description does not add any additional semantic meaning beyond that.
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 compares the EXIF thumbnail against the main JPEG image, with specific forensic purpose (detecting modification after capture). This is distinct from sibling tools like img_compare or img_detect.
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 when investigating image authenticity or forensic artifacts, and explains what a mismatch indicates. However, it does not explicitly state when not to use it or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Auto-detect MP3 steganography. Checks ID3 tag padding, gaps before first audio frame, trailing data after last frame, bitrate anomalies, and inter-frame gaps for signs of hidden data.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to MP3 audio file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses the specific detection methods, adding behavioral context such as checking multiple MP3 structures. It does not, however, describe output format 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?
Two sentences: first states purpose, second enumerates checks. No superfluous information, front-loaded with key action.
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 tool is simple with one parameter and no output schema. The description covers detection methods but omits expected output type (e.g., boolean or report), which would enhance completeness.
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 100% and the only parameter (file_path) is described in the schema. The description adds no additional meaning beyond the schema baseline.
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 auto-detects MP3 steganography and lists specific checks (ID3 tag padding, gaps, trailing data, bitrate anomalies, inter-frame gaps), distinguishing it from siblings like mp3_id3_hidden or mp3_padding.
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 MP3 steganography detection but does not provide explicit when-to-use or when-not-to-use guidance relative to alternatives like audio_detect or mp3_structure.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
MP3 frame header analysis. Examines bitrate changes, padding patterns, VBR detection, frame size consistency, and layer/version anomalies across audio frames.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to MP3 audio file |
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 the analysis scope but does not mention potential side effects, read-only nature, or performance impact, though 'analysis' implies a non-destructive 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 a single, well-structured sentence that front-loads the main purpose and lists specifics efficiently, with 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?
The description outlines what the tool examines but does not explain the output or return values (no output schema provided). For a simple analysis tool, it is moderately complete but could benefit from describing the nature of the results.
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 100% for the single parameter (file_path). The description adds no further meaning beyond the schema, so baseline 3 is appropriate.
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 performs MP3 frame header analysis and lists specific aspects examined (bitrate changes, padding patterns, VBR detection, etc.), distinguishing it from sibling tools like mp3_detect or mp3_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?
The description implies the tool is for detailed frame header analysis but does not explicitly state when to use it over alternatives, nor does it provide exclusions or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full MP3 metadata extraction. Reports ID3v1 tag, ID3v2 frames with content, duration, bitrate, VBR status, sample rate, and file structure overview.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to MP3 audio file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only lists what is reported but does not mention whether the file is read-only, permissions required, or any side effects. This is insufficient for a tool that processes files.
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 front-loaded with the core purpose. Every word adds value, listing specific outputs 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?
While the description lists key metadata, it lacks details about the output format or what 'file structure overview' includes. Given the complexity of MP3 metadata and absence of output schema, more context would improve completeness.
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 100% and the description does not add meaning beyond 'file_path: Path to MP3 audio file'. The description focuses on output rather than parameter details, so baseline score of 3 is appropriate.
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 'Full MP3 metadata extraction' and lists specific metadata types (ID3v1 tag, ID3v2 frames, duration, bitrate, VBR status, sample rate, file structure overview), distinguishing it from sibling tools like mp3_detect or mp3_frame_analysis which focus on detection or frame-level details.
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. With many related sibling tools (e.g., mp3_id3_hidden, mp3_padding, mp3_structure), the absence of context or exclusions leaves the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bit reservoir and padding manipulation detection. Analyzes the gap before the first audio frame, inter-frame gaps between consecutive frames, and checks for data inserted between or around audio frames.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to MP3 audio file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of behavioral disclosure. It explains what the tool analyzes (gaps, inter-frame data) but does not specify if the tool modifies files, requires permissions, or has side effects. It also omits behavior for invalid files or edge cases.
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, consisting of two clear sentences. The first sentence front-loads the primary purpose, and the second adds specifics. No extraneous information, though it could be better structured with bullet points for clarity.
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 analysis scope but lacks output details (e.g., whether results are boolean, metrics, or raw data). Given no output schema and one parameter, more context on expected output would improve completeness.
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 specifies 'file_path' with a description. The tool description adds no additional parameter-level details beyond what the schema provides. With 100% schema description coverage, the baseline of 3 is appropriate.
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 identifies the tool's purpose as detecting bit reservoir and padding manipulation in MP3 files. It specifies the exact analysis performed (gaps before first frame, inter-frame gaps, data inserted between/around frames), distinguishing it from sibling tools like mp3_detect (general detection) and mp3_frame_analysis (frame-level details).
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. It does not mention prerequisites, file types, or scenarios where this tool is preferred over other MP3 analysis tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Statistical analysis of decoded MP3 frame sizes. Computes entropy, variance, and anomalies in frame size distribution to detect steganographic manipulation of audio frame data.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to MP3 audio file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavior. It states the tool 'computes' and 'detects,' implying read-only analysis, but does not explicitly confirm it does not modify the file or mention any prerequisites.
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 with no wasted words. The first sentence states the core purpose; the second provides detail on what is computed and why.
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 simple one-parameter tool with no output schema, the description covers what it does but does not hint at the return format or whether results are displayed or saved. It is adequate but not comprehensive.
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 100% for the single parameter with a basic description. The tool description adds context about analyzing decoded frame sizes but does not improve parameter understanding 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 performs statistical analysis of decoded MP3 frame sizes and lists specific computations (entropy, variance, anomalies) to detect steganography. It distinguishes from siblings like mp3_frame_analysis which likely focuses on frame structure rather than statistical distribution.
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 implies use for steganography detection but does not mention when not to use or compare to related tools like mp3_detect or audio_detect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
MP3 frame structure visualization. Displays the first N frames with bitrate, padding bit, channel mode, and frame size for a detailed map of the file's audio frame layout.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to MP3 audio file | |
| max_frames | No | Maximum frames to display (default: 50) |
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 the tool is read-only ('displays', 'visualization') with no destructive side effects, but does not disclose potential performance impacts or error handling (e.g., non-MP3 files). Adequate but not thorough.
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, well-structured sentence that packs all necessary information without redundancy. Every phrase is informative and earns its place.
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 explains what the output includes (bitrate, padding, channel mode, frame size), which is sufficient given no output schema. It covers the key aspects of the tool's behavior, though it could mention the return format or limits on large files.
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 100%, and the description adds minimal extra meaning beyond the schema. It confirms that 'max_frames' controls the number of frames displayed but does not explain default behavior or constraints beyond what the schema already states.
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 visualizes MP3 frame structure, listing specific attributes (bitrate, padding bit, channel mode, frame size). It distinguishes from siblings like mp3_detect, mp3_metadata, and mp3_frame_analysis by focusing on layout visualization.
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 frame structure but does not explicitly state when to use this tool over alternatives like mp3_frame_analysis or mp3_sample_analysis. No when-not-to-use or prerequisite guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Auto-detect network steganography in a PCAP file. Checks IP covert header fields, ICMP payload anomalies, DNS tunneling indicators, and inter-packet timing patterns. Returns a combined suspicion score.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to PCAP capture file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states inputs and outputs but fails to disclose operational details such as whether the file is modified, read-only nature, output format specifics, or performance 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 extremely concise: two sentences covering purpose, methods, and output with no extraneous content. Information is front-loaded 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?
Given the complexity of network steganography detection and no output schema, the description lacks details about the suspicion score (range, interpretation) and whether individual check results are provided. This is insufficient for an agent to fully understand the tool's capability.
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 already describes the single parameter 'file_path' as 'Path to PCAP capture file', achieving 100% coverage. The description adds no additional parameter semantics, so baseline score of 3 applies.
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 explicitly states the tool auto-detects network steganography in PCAP files, lists specific checks (IP header, ICMP, DNS, timing), and mentions output (suspicion score). It clearly differentiates from sibling tools which focus on individual techniques.
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. The description implies it is a comprehensive detection tool, but does not state priorities or suggest it as a first-step scan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DNS tunneling detection. Analyzes subdomain length distribution, label entropy, TXT record usage, query frequency per domain, and unique subdomain counts to identify DNS-based covert channels.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to PCAP capture file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must bear the full burden of behavioral disclosure. It describes the analysis dimensions but omits details on side effects, auth requirements, or whether the tool is read-only. Given the lack of contradictory hints, a mid-range score is appropriate; it does not contradict annotations since none exist.
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 that front-load the core purpose and immediately list the key analytic dimensions. No redundant or verbose phrases; every word serves a purpose.
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 complexity (multi-factor DNS analysis), the description covers the input (PCAP file) and analytic dimensions. However, the absence of an output schema means the description could better explain what the detection result looks like (e.g., a score, list of suspicious domains). Still, it is largely complete for guiding a capable 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 100% for the single parameter 'file_path' (described as 'Path to PCAP capture file'). The tool description adds no additional semantic meaning beyond this, earning the baseline score.
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: 'DNS tunneling detection' and lists specific analysis techniques (subdomain length distribution, label entropy, TXT record usage, etc.), making the function highly specific and distinguishable from sibling tools like net_http_header or net_icmp_payload.
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 detecting DNS covert channels in PCAP files but provides no explicit guidance on when to use this tool versus alternatives (e.g., net_detect, net_stats). No exclusions or conditional scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
HTTP header covert channel analysis. Examines unusual/custom headers, cookie value entropy, header ordering anomalies, and hidden data in standard header fields across HTTP traffic in a PCAP.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to PCAP capture file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It lists analysis aspects but does not disclose behavioral traits such as read-only nature, performance impact, or output format, limiting 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 a single sentence that efficiently conveys purpose and key details. While concise, it could be structured for clarity (e.g., bullet points) especially given the list of examined items.
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 single-parameter analysis tool, the description adequately covers what it does but lacks details on output or side effects. Given no output schema, some completeness is missing.
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 100% for the single parameter file_path, so baseline is 3. The description adds context about PCAP files but does not add new parameter 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 the tool is for 'HTTP header covert channel analysis' and lists specific items examined, distinguishing it from siblings like net_ip_header and net_tcp_header.
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 detecting hidden data in HTTP headers but does not provide explicit when-to-use or when-not-to-use guidance, nor mention alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ICMP echo payload analysis. Examines entropy, printable content ratio, payload size anomalies, and pattern consistency of ICMP echo request/reply payloads to detect covert data exfiltration.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to PCAP capture file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the burden of behavioral disclosure. It mentions examining entropy, content ratio, size anomalies, and pattern consistency, indicating a read-only analysis. However, it does not explicitly state non-destructive behavior or any 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 a single, dense sentence that conveys key information upfront. It is concise without waste, though splitting into two sentences could improve readability.
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?
No output schema is provided, and the description does not explain return values or output format. For a network analysis tool, knowing the result structure (e.g., report, score) is helpful for agent workflow. The description adequately covers input and analysis dimensions but lacks output context.
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 single parameter 'file_path' is fully described in the schema (100% coverage) as a path to a PCAP file. The description adds no additional parameter semantics beyond schema, so baseline of 3 applies.
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 analyzes ICMP echo payloads for covert data exfiltration, specifying verb ('examines') and resource ('ICMP echo request/reply payloads'). It differentiates from sibling network tools by focusing on ICMP payload steganography detection.
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 ICMP echo payload analysis but does not explicitly state when to use this tool over alternatives like net_detect or net_dns_tunnel. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
IP header covert field analysis. Examines TTL patterns, IP identification field entropy, and TOS/DSCP usage across packets to detect hidden data in IP header fields.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to PCAP capture file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states it examines patterns and entropy to detect hidden data, but does not clarify if it modifies data, what output format to expect, or any prerequisites beyond file_path. Lacks detail on side effects or read-only nature.
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 that front-load the purpose. No superfluous words. Could be slightly improved by combining information, 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 tool's complexity (analyzing multiple IP fields for covert data) and lack of output schema, the description should clarify what results are produced (e.g., flagged packets, entropy values). Current description leaves the agent guessing about output, making it incomplete for informed selection.
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 100% with a single parameter file_path described as 'Path to PCAP capture file'. The description adds no further meaning to the parameter beyond the schema, so baseline of 3 is appropriate.
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?
Describes specific verb-examines TTL patterns, IP ID entropy, TOS/DSCP to detect hidden data in IP header fields. Distinguishes from sibling tools like net_tcp_header and net_icmp_payload which focus on different layers. However, 'examines' is somewhat passive; a more active verb like 'analyzes' would be clearer.
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 usage when covert data is suspected in IP header fields, but does not explicitly state when to use this tool vs alternatives like net_tcp_header or net_dns_tunnel. No exclusions or contextual clues provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PCAP statistics summary. Reports packet count, protocol distribution, top IP pairs, port usage, capture duration, and data volume for an overview of the capture file.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to PCAP capture file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implicitly indicates the tool reads a PCAP file and outputs statistics, but does not disclose potential side effects (e.g., file locking), authentication needs, or performance implications. It 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?
One sentence, front-loaded with 'PCAP statistics summary', and efficiently lists the key outputs. 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?
For a tool with one parameter and no output schema, the description covers the main outputs. It could mention any file size constraints or error conditions, but overall is fairly 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?
Schema coverage is 100% with a single parameter 'file_path' described. The tool description adds value by explaining what statistics are computed, going beyond the schema's simple path description.
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 a summary of PCAP statistics, listing specific metrics (packet count, protocol distribution, etc.). It implies an overview function, distinguishing from sibling net_* tools that focus on specific aspects like DNS tunneling or HTTP headers, but does not explicitly differentiate.
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 only describes what it does, without mentioning exclusions or alternative tools for more specific analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TCP sequence/acknowledgment number analysis. Checks for patterns in ISN (Initial Sequence Numbers), unusual TCP options, and seq/ack number anomalies that could indicate covert channel usage.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to PCAP capture file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It accurately states the tool analyzes TCP headers for anomalies and covert channels, implying read-only behavior. However, it could mention any permissions 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 two sentences: first sentence states the primary function, second details specific checks. Every sentence earns its place with 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?
The description lacks information about output format or return values. Since no output schema exists, the description should hint at results. Otherwise, it adequately covers the tool's purpose and 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?
Schema coverage is 100% with a single parameter 'file_path' described as 'Path to PCAP capture file'. The description adds no extra meaning beyond this, so baseline score of 3 is appropriate.
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 performs TCP sequence/acknowledgment number analysis for covert channel detection. It specifies the verb (analysis/checks) and resource (TCP headers), distinguishing from sibling tools like net_ip_header or net_http_header.
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 TCP covert channel detection but does not provide explicit guidance on when to use this tool versus alternatives. No exclusions or when-not-to-use are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inter-packet timing analysis. Computes packet arrival intervals and analyzes them for binary encoding patterns (e.g., short interval = bit 0, long interval = bit 1). Detects timing-based covert channels.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to PCAP capture file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the analysis steps (computing intervals, detecting binary patterns) and the purpose (covert channel detection). Since no annotations are provided, the description sufficiently conveys the non-destructive analysis 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?
Three concise sentences with no wasted words. Front-loaded with key action and purpose.
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?
Completely covers what the tool does, the required input (PCAP file), and the output (timing analysis and covert channel detection) for a simple single-parameter 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?
Schema description coverage is 100% for the only parameter file_path. The tool description adds overall context but no additional parameter-specific details beyond the schema's description.
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?
Clearly states it performs inter-packet timing analysis, computes intervals, and detects binary encoding patterns and covert channels. Distinguishes from sibling network tools (e.g., net_dns_tunnel, net_http_header) by focusing on timing patterns.
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 usage for timing-based covert channel detection but lacks explicit guidance on when to use vs alternatives or when not to use. No comparison with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two QR code images for differences. Performs pixel-by-pixel comparison, identifies differing modules, and analyzes whether differences are in the data region or function patterns. Useful for detecting stego modifications between an original and modified QR code.
| Name | Required | Description | Default |
|---|---|---|---|
| threshold | No | Black/white threshold (0-255, default: 128) | |
| file_path_1 | Yes | Path to first QR code image (BMP) | |
| file_path_2 | Yes | Path to second QR code image (BMP) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. Discloses core behavior (pixel-by-pixel, module analysis, region classification). Missing details on side effects, output format, error handling, or performance implications. 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 efficiently convey purpose, method, and use case. No redundant information. Front-loaded with action 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?
Good for a focused tool, but lacks return format details, prerequisites (e.g., image size compatibility), and error conditions. Siblings like qr_data_extract have more contextual depth.
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?
All 3 parameters have schema descriptions (100% coverage). Description does not add significant value beyond schema, only hints at pixel-wise comparison. Baseline 3 is appropriate as schema already documents file paths and threshold.
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 'Compare' with specific resource 'two QR code images'. Description details pixel-by-pixel comparison, module identification, and region analysis (data vs function). Distinct from siblings like img_compare (general) and qr_detect (detection only).
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?
States usefulness for stego modification detection, implying use case. However, no explicit guidance on when to use vs alternatives (e.g., img_compare, qr_structure), nor any conditions to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract QR data region pixels from an image. Identifies the QR code grid, excludes function patterns (finder, timing, alignment), and returns the raw pixel values from the data/ECC modules. Useful for manual analysis of potentially modified data regions.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to QR code image file (BMP for best results) | |
| threshold | No | Black/white threshold (0-255, default: 128) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden. It explains the extraction process (grid identification, exclusion of function patterns) but does not detail output format, error handling, or side effects. It 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 three sentences, front-loaded with the primary action, and contains no filler. Every sentence adds value: purpose, process detail, and use case. It is concise and 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 lack of output schema, the description should clarify the return format (e.g., array of pixel values). It mentions 'raw pixel values' but is vague. For a specialized tool, this is somewhat incomplete for an AI agent to fully understand the output.
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 100% with descriptive parameter texts for file_path and threshold. The tool description adds no extra meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
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 QR data region pixels, identifies the grid, excludes function patterns, and returns raw pixel values. This specific verb-resource combination distinguishes it from sibling tools like qr_detect or qr_structure, which have different purposes.
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 manual analysis of modified data regions, but does not explicitly state when to use this tool over siblings. It provides a use case but lacks direct comparisons or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect steganography in QR code images. Analyzes the image for unusual pixel patterns around data modules, checks for sub-module color variations, and measures pixel value distributions that could indicate LSB embedding or other stego techniques applied to a QR code image.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to QR code image file | |
| threshold | No | Black/white threshold (0-255, default: 128) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the analysis techniques (pixel patterns, sub-module color variations, LSB detection) but does not explicitly state whether the tool is read-only or if it modifies the file. Without annotations, this is a moderate gap.
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, no redundancy. The first sentence states the core purpose, followed by specific methods. Concise and front-loaded without 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?
The description explains detection techniques but omits output behavior (e.g., returns a score, boolean, or report). No output schema exists, so the description should hint at the return format. This is a notable gap for a detection 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 covers both parameters with descriptions (100% coverage). The tool description adds no extra meaning beyond what the schema provides, meeting the baseline expectation.
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 detects steganography in QR code images, with specific analysis methods. It distinguishes from sibling tools like qr_data_extract or qr_structure by focusing on stego techniques rather than structure or data extraction.
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 vs alternatives. The description does not mention prerequisites, when to avoid, or context for using other QR-related tools among the many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Error correction capacity analysis for QR code images. Estimates the QR version and calculates the total, data, and ECC codewords for each error correction level (L/M/Q/H). Reports unused ECC capacity that could theoretically hold steganographic data without breaking the QR code.
| Name | Required | Description | Default |
|---|---|---|---|
| ecc_level | No | Assumed ECC level if known (default: estimate all levels) | |
| file_path | Yes | Path to QR code image file | |
| threshold | No | Black/white threshold (0-255, default: 128) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the analysis performed (version estimation, codeword calculation, unused capacity reporting) and the steganographic purpose. No annotations exist, so description adequately covers behavior; no mention of side effects, but likely read-only.
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 concise sentences, each adding value: function, what it calculates, and practical implication. 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?
The description covers the tool's purpose and output (unused capacity report) but could be more specific about the format (e.g., numbers per level). With 3 parameters and no output schema, it is fairly 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?
Schema coverage is 100%, so schema already documents parameters well. The description adds no extra parameter detail beyond the schema, but provides context on the overall analysis output. Baseline 3 is appropriate.
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?
Clearly states the tool performs error correction capacity analysis for QR codes, estimating version, calculating codewords per ECC level, and reporting unused capacity for steganography. This distinguishes it from siblings like qr_detect or qr_data_extract.
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 use for analyzing ECC capacity and steganographic potential, but does not explicitly state when to use this tool versus alternatives like qr_structure or qr_module_analysis. No exclusion criteria or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Module-level pixel analysis of QR code images. Examines individual modules (the black/white squares) for sub-pixel anomalies: color variation within a single module, non-uniform grayscale values, and deviations from expected pure black (0) or pure white (255). These anomalies can indicate LSB stego or watermarking.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to QR code image file (BMP for best results) | |
| threshold | No | Black/white threshold (0-255, default: 128) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full transparency burden. It details specific behavioral traits: examines modules for color variation, non-uniform grayscale, deviations from pure black/white, and links to LSB stego or watermarking. It does not cover return format or side effects, but the anomaly list is sufficiently informative.
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 zero wasted words. It leads with the action, lists specific anomalies, and ends with the purpose (stego/watermarking). Every sentence earns its place.
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 of module-level analysis and the absence of an output schema, the description covers the tool's input (QR image with threshold), detailed anomalies, and high-level purpose. It could be more complete by mentioning the output format (e.g., a report of anomalies), but it provides enough context for an agent to decide 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 100% with both parameters having descriptions (file_path and threshold). The tool description does not add new parameter information beyond the schema; it contextualizes the analysis but not the parameters themselves. Baseline 3 applies as the schema covers the parameters adequately.
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 uses specific verbs ('Examines individual modules') and clearly identifies the resource (QR code modules) and the anomalies sought (sub-pixel anomalies, color variation, LSB stego). It distinguishes from sibling tools like qr_detect and qr_compare by focusing on module-level pixel inspection.
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 stego/watermark detection but does not explicitly state when to use this tool versus alternatives (e.g., qr_compare, img_lsb_detect). No when-not or alternative guidance is provided, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
QR code structure analysis. Detects finder patterns (the 3 corner squares), estimates the QR version from the distance between patterns, reports the estimated module (pixel) size, and provides the image's dimensions relative to the expected QR grid.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to QR code image file | |
| threshold | No | Black/white threshold (0-255, default: 128) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral transparency. It covers key operations (detecting patterns, estimating version/module size) and output dimensions. However, it does not mention error handling, false positives, or behavior on non-QR images, which would enhance 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 a single sentence that effectively lists the tool's capabilities. It is concise and front-loaded with the main purpose. However, it could be slightly more structured (e.g., bullet points) for better readability.
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 moderate complexity and lack of output schema, the description adequately explains what the tool returns (finder patterns, version, module size, dimensions). It does not detail the return format or data types, but the listed items give sufficient context for an agent to understand the output.
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 covers 100% of parameters, so parameter semantics are already clear from the schema. The description adds no additional meaning beyond the schema—it does not explain the threshold parameter's role or provide examples.
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 that the tool analyzes QR code structure, listing exact outputs: finder patterns, version, module size, and image dimensions. This distinguishes it from sibling tools like qr_data_extract or qr_detect, which focus on data extraction or detection.
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 analysis of QR code structure but does not provide explicit guidance on when to use this tool versus alternatives like qr_detect or qr_ecc_analysis. No when-not-to-use or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Autocorrelation-based steganography detection. Computes the autocorrelation of pixel values to find periodic embedding patterns. Spread spectrum and watermarking methods often introduce periodic signals that appear as peaks in the autocorrelation function.
| Name | Required | Description | Default |
|---|---|---|---|
| channel | No | Color channel to analyze: 0=R, 1=G, 2=B (default: 0) | |
| max_lag | No | Maximum lag to compute (default: 512) | |
| file_path | Yes | Path to image file (PNG or JPEG) for autocorrelation analysis |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states the tool computes autocorrelation but does not confirm that it is read-only, nor does it describe output format, error handling, or limitations. The agent has little information about side effects or requirements.
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, concise and front-loaded with the core purpose. It avoids extraneous information, earning a high score for efficient communication.
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?
Without an output schema, the description should clarify what the tool returns, but it does not. It also lacks prerequisites, file size limits, or error conditions. For a detection tool, this gap in completeness is significant.
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 100% with descriptions for all three parameters. The description does not add significant detail beyond the schema, so it meets the baseline expectation but does not enhance parameter 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 states it computes autocorrelation of pixel values to find periodic embedding patterns, with a clear verb and resource. It distinguishes from siblings like spread_dft_analysis by focusing on autocorrelation, but could be more explicit about when to use this specific method.
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 use for detecting spread spectrum and watermarking methods, but offers no explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DFT magnitude spectrum analysis for spread spectrum steganography detection. Computes the Discrete Fourier Transform of pixel values and analyzes the frequency spectrum for hidden signals, unusual peaks, or spectral flatness anomalies that indicate spread spectrum embedding.
| Name | Required | Description | Default |
|---|---|---|---|
| channel | No | Color channel to analyze: 0=R, 1=G, 2=B (default: 0) | |
| file_path | Yes | Path to image file (PNG or JPEG) for DFT analysis |
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 mentions the analysis for hidden signals and anomalies but does not describe whether the tool modifies the file, its computational cost, required permissions, or output format. For a tool with no annotations, this is insufficient 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, consisting of two sentences that efficiently convey the tool's purpose and method. It is front-loaded with the main action and requires no extraneous 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 has two parameters, no output schema, and no annotations, the description explains the core operation but lacks details on output format, side effects, or specific requirements beyond file path. It is adequate but not fully comprehensive for an agent to rely on without additional structured 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?
Schema documentation coverage is 100%, meaning both parameters (file_path and channel) are described in the schema. The description adds context about DFT and steganography detection but does not enhance understanding of the parameters beyond the schema. Baseline score of 3 is appropriate.
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: DFT magnitude spectrum analysis for spread spectrum steganography detection. It specifies that it computes the Discrete Fourier Transform of pixel values and analyzes the frequency spectrum for hidden signals, unusual peaks, or spectral flatness anomalies. This is specific and distinct from sibling tools like spread_correlation or spread_noise_analysis.
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 the tool is used for detecting spread spectrum steganography in images, but it does not provide explicit guidance on when to use this tool versus alternatives. No mention of when not to use it or prerequisites, leaving the agent to infer context from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Noise floor embedding detection. Compares noise levels across image regions to detect spread spectrum or additive noise-based steganography. Embedded data adds noise to cover pixels, and uneven noise distribution between smooth and textured regions can reveal hidden content.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to image file (PNG or JPEG) for noise analysis | |
| block_size | No | Block size for noise estimation (default: 16) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. It explains the mechanism (uneven noise distribution detection) but does not disclose whether the tool is read-only, potential side effects, or behavior with non-image inputs. Lacks details on return format or error conditions.
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; first sentence identifies purpose, rest provides technical context. No wasted words, 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?
No output schema, and description does not hint at return values or result structure. Missing details on image format constraints (e.g., color vs grayscale) and how block size affects analysis. Adequate but incomplete for a detection 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 100% with clear parameter descriptions. The description does not add meaning beyond the schema, so baseline 3 applies.
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: 'Noise floor embedding detection' and explains the technique of comparing noise levels across image regions to detect spread spectrum or additive noise-based steganography. This is specific and distinguishes it from sibling tools like spread_correlation or spread_dft_analysis.
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 detecting noise-based steganography but does not explicitly state when to use this tool over other spread analysis siblings. No guidance on prerequisites or exclusion scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Patchwork watermark detection using the patchwork statistical test. Splits pixel values into two pseudo-random groups and tests whether the mean difference between groups is statistically significant. A significant difference indicates a patchwork watermark was embedded by adding/subtracting a small value from selected pixels.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | PRNG seed for group splitting (default: 42) | |
| channel | No | Color channel to test: 0=R, 1=G, 2=B (default: 0) | |
| file_path | Yes | Path to image file (PNG or JPEG) for patchwork detection |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explains the statistical test and what a significant difference indicates, but does not disclose limitations, required image properties, or potential failure modes.
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 efficient sentences: first states purpose, second explains method, third interprets results. No fluff, front-loaded, and easy to parse.
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 tool has no output schema and the description does not specify return format (e.g., p-value, boolean). It also omits prerequisites like file format requirements or performance considerations. Given the statistical nature, this is a significant gap.
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 100%, so parameters are documented. The description adds context about the test (seed for random splitting, channel selection) but does not augment the schema's descriptions beyond that. Baseline 3 is appropriate.
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 detects patchwork watermarks using a statistical test, with a specific verb ('detect') and resource ('patchwork watermark'). It distinguishes itself from sibling spread tools by naming the specific test.
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 what the tool does but provides no explicit guidance on when to use it versus alternatives like spread_correlation or spread_dft_analysis. Usage context is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Statistical watermark detection via variance comparison between image regions. Divides the image into blocks and compares pixel variance across regions. Watermarked regions tend to have altered variance patterns compared to natural image content, revealing the presence of additive watermarks.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to image file (PNG or JPEG) for watermark detection | |
| block_size | No | Block size for region analysis (default: 32) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It describes the analysis method but does not mention that the tool is read-only, lacks permission requirements, or what happens on non-image files. The method explanation is insufficient for behavioral 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 two sentences, directly stating the purpose and method without any extraneous information. It is concise and 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 no output schema, the description omits any info about return values or output format (e.g., boolean, confidence score). The tool's functionality is explained, but the lack of output details leaves ambiguity. Sibling context partially compensates by showing similar detection tools.
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 100%, so the parameters (file_path, block_size) are already described in the schema. The description adds no additional meaning or constraints beyond what the schema provides, earning a baseline score of 3.
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 the tool performs statistical watermark detection via variance comparison, describing the method (divides into blocks, compares variance). It distinguishes from sibling spread spectrum tools like spread_correlation by focusing on variance patterns.
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 the tool works but does not provide explicit guidance on when to use it vs other watermark detection tools (e.g., spread_correlation, spread_dft_analysis). Usage context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect first-letter, first-word, last-letter, last-word, or nth-character patterns (acrostic messages) hidden across lines of text.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | Position for nth_char mode | |
| mode | No | Detection mode (default: first_letter) | |
| text | Yes | Text to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It lists detectable patterns but lacks details on behavior like read-only nature, error handling, or output format. Basic transparency is present.
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 that is well-structured and to the point. 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 3 parameters, no output schema, and no annotations, the description adequately explains input and purpose. Lacks explicit return value description, but for a detection tool the output is implied.
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 100%, and the description reinforces the purpose of each parameter, especially linking 'n' to nth_char mode. Adds meaning beyond schema by explaining modes in context.
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 the tool detects acrostic patterns (first-letter, first-word, etc.) across lines of text. This distinguishes it from sibling tools like text_detect or text_homoglyph which handle different text steganography techniques.
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?
Description implies usage for acrostic detection but does not explicitly state when to use it vs. alternative tools. No exclusion or comparison with siblings is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Auto-detect text steganography. Checks for zero-width characters, whitespace encoding, invisible Unicode, homoglyphs, and unusual patterns.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lists what is checked but lacks information about output format (e.g., boolean, score, list of findings) or behavioral traits like handling of errors, performance, or limitations. Without annotations, the description carries the full burden and is only partially informative.
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, no filler, front-loaded with the main purpose and then listing checks. Every word 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 tool with a single string input and no output schema, the description is somewhat incomplete: it does not describe the return value, how results are presented, or what 'unusual patterns' entails. Given the many sibling tools, more context would help an agent decide whether to use this 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 coverage is 100% with one parameter 'text' described as 'Text to analyze'. The description adds context about what the tool does with the text, but no additional parameter 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 the tool's purpose with specific verb 'auto-detect' and lists multiple detection categories (zero-width characters, whitespace encoding, invisible Unicode, homoglyphs, unusual patterns). It distinguishes from sibling tools like text_zwc_detect or text_whitespace_detect which are narrower in scope.
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 vs. sibling tools. The description implies it's a comprehensive detector, but doesn't state scenarios where a more specific tool (e.g., text_homoglyph) would be better or how to interpret results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect Unicode homoglyph substitutions in text. Identifies non-ASCII characters that visually resemble ASCII letters (e.g., Cyrillic a vs Latin a, Greek o vs Latin o).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It explains detection of non-ASCII characters resembling ASCII letters, but does not describe the output format (e.g., list of found characters, locations) or any side effects. This leaves ambiguity about what the agent can expect after invocation.
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 concise sentences that front-load the core purpose and provide an example. Every word 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?
While the tool is simple with one parameter, the description omits what the output looks like (e.g., list, counts, or boolean). Given no output schema, this gap reduces completeness for an agent needing to handle results.
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 100% coverage with a single parameter 'text' described as 'Text to analyze'. The description adds no additional meaning beyond the schema; it only restates that the tool operates on text. Baseline 3 applies due to high 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 uses a specific verb 'Detect' and resource 'Unicode homoglyph substitutions in text', with clear examples (Cyrillic a vs Latin a). It distinguishes itself from siblings like text_detect or text_unicode_analysis by focusing on homoglyphs.
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 states what the tool does but gives no explicit guidance on when to use it versus alternatives, nor any exclude conditions. Usage is implied but not clearly demarcated against sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan text for ALL invisible Unicode characters. Checks every character against the full invisible character database and reports positions, names, and categories.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to scan |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It mentions the output (positions, names, categories) but does not disclose whether the tool is read-only, any potential side effects, or performance characteristics. It is adequate but could add that it is a safe scanning 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?
Two concise sentences with no redundant words. Front-loaded with the primary action and followed by a clear explanation of what it checks and reports.
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 simple one-parameter tool with no output schema, the description is fairly complete. It covers the what, how, and what is reported. Minor improvement could mention that it is a read-only operation, but overall sufficient.
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 100% with 'text' parameter described. The description adds meaning by specifying the scope (ALL invisible Unicode characters) and the output details (positions, names, categories), enhancing understanding 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 scans text for ALL invisible Unicode characters, checking against a full database and reporting positions, names, and categories. This specific verb+resource scope distinguishes it from siblings like text_whitespace_detect or text_zwc_detect.
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. For example, it does not mention that for specific invisible character types like whitespace or zero-width characters, there are dedicated sibling tools available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full Unicode character distribution analysis. Categorizes all characters by script block, performs entropy analysis, and detects suspicious script mixing.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It effectively discloses the tool's behavior (categorization, entropy analysis, script mixing detection). While it doesn't explicitly state non-destructiveness or requirements, the analysis nature is clear.
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?
A single, well-structured sentence that front-loads the core purpose ('Full Unicode character distribution analysis') and lists key features concisely. 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, the description should ideally mention the return format. It describes the analysis types but omits what the output looks like (e.g., a report, percentages). For a simple tool with one input, it's adequate 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?
Schema coverage is 100% with parameter 'text' described as 'Text to analyze'. The description adds context about the analysis but does not provide additional parameter-specific details beyond the schema, so baseline 3 is appropriate.
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 performs 'Full Unicode character distribution analysis' with specific actions: categorizes by script block, entropy analysis, and script mixing detection. It distinguishes itself from sibling text analysis tools like text_homoglyph or text_detect.
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 Unicode analysis but does not explicitly state when to use this tool vs alternatives like text_homoglyph or text_detect. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect whitespace encoding in text. Checks each line for trailing whitespace patterns where space=0 and tab=1 might encode binary data.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to analyze |
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 explains the encoding scheme (space=0, tab=1) and the per-line checking, but does not mention limitations, output format, or false positives.
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 that effectively front-load the purpose and method, with no extraneous 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?
The description covers the core purpose and detection mechanism well, but omits expected return value or result format. Given no output schema, this lack reduces completeness for a detection 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?
The only parameter 'text' has a minimal schema description ('Text to analyze'). The tool description adds significant meaning by specifying the expected content and detection logic, compensating for the schema's brevity.
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 detects whitespace encoding in text by checking for trailing whitespace patterns where spaces and tabs represent binary. It distinguishes from sibling tools like text_whitespace_extract and other text detection 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 implies use when suspicious of binary encoding in trailing whitespace but does not explicitly state when not to use it or compare to alternatives like text_whitespace_extract.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract a whitespace-encoded message from text. Reads trailing whitespace from each line and decodes space=0/tab=1 binary encoding.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text with whitespace encoding |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It describes the decoding process but does not specify output format, behavior when no encoding is present, or any edge cases. This is adequate but leaves some behavioral ambiguity.
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, front-loaded with the core action and immediately followed by encoding details. No redundant or unnecessary 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?
For a simple tool with one parameter and no output schema, the description covers input and algorithm but omits output format (e.g., is the extracted message returned as a string? Is the original text modified?). This gap reduces completeness.
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 one parameter 'text' has minimal schema description. The tool description adds significant detail: it reads trailing whitespace and decodes space/tab binary. This compensates well for the sparse 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 extracts a specific type of hidden message (whitespace-encoded) and details the encoding scheme (space=0, tab=1 binary from trailing whitespace). It is distinct from sibling tools like text_whitespace_detect or text_zwc_extract.
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 use when text may contain whitespace encoding but does not explicitly state when to use versus alternatives (e.g., text_whitespace_detect). The context of siblings provides some differentiation but the description itself lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect zero-width characters (ZWSP, ZWNJ, ZWJ, BOM) in text. Reports positions, counts, and potential encoded message length.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to analyze |
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 the tool reports positions, counts, and potential encoded message length, but does not mention whether it modifies input, requires permissions, or handles edge cases. The behavior is adequately described for a detection 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 a single, concise sentence that packs essential information: what is detected, specific characters, and output types. No unnecessary 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 (1 parameter, no output schema) and sibling context, the description covers detection, characters, and outputs. It does not mention input encoding or format, but for a detection tool this is sufficient.
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?
There is one parameter 'text' with description 'Text to analyze' in the schema. Schema coverage is 100%, so the description adds no additional meaning. Baseline score of 3 is appropriate.
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 verb 'Detect', the specific resource 'zero-width characters', lists the exact characters (ZWSP, ZWNJ, ZWJ, BOM), and specifies the outputs (positions, counts, potential encoded message length). It distinguishes from sibling tools like text_zwc_embed and text_zwc_extract.
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 (e.g., text_whitespace_detect, text_unicode_analysis). The description implies detection context but lacks when-not or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Embed a secret message into cover text using zero-width characters. Encodes the message to binary and maps bits to ZWSP(0)/ZWNJ(1), inserting them between characters of the cover text.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Cover text | |
| message | Yes | Secret message to embed |
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 the encoding process and insertion behavior but does not mention potential side effects (e.g., text length increase), error cases (e.g., message too long), or whether the input text is modified in place.
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 with no extraneous information. The first sentence states the purpose, the second explains the mechanism. Every word contributes.
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 explains the core mechanism but lacks details on output (the modified text is not mentioned), limits (max message length), and failure conditions. Given no output schema, some of this context would be helpful.
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 100% parameter description coverage. The description adds value by explaining how the message is encoded and inserted, providing context beyond the schema strings 'Cover text' and 'Secret message to embed'.
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 uses a specific verb 'embed' and clearly identifies the resource ('secret message into cover text') and method ('using zero-width characters'). It distinguishes from sibling tools like detect and extract by being the embedding variant.
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 the embedding works technically but does not provide explicit guidance on when to use this tool versus alternatives (e.g., detect/extract). Usage context is implied but not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode a zero-width character encoded message. Extracts ZWC chars and decodes binary: ZWSP=0, ZWNJ=1 (attempts both polarities).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text containing ZWC-encoded message |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool attempts both polarities (ZWSP=0, ZWNJ=1), which adds behavioral insight beyond the input schema. However, it does not explain behavior in cases of no ZWC characters, error handling, or return format, leaving some gaps.
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 very concise with two sentences, no redundant words, and the key action is front-loaded. 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 simple tool with one parameter and no output schema, the description sufficiently covers what the tool does. It explains the decoding mechanism (polarities) and the input. Missing output format details, but overall adequate.
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?
There is only one parameter ('text') with 100% schema description coverage. The description adds no further meaning beyond the schema's 'Text containing ZWC-encoded message'. Baseline of 3 is appropriate.
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 'Decode a zero-width character encoded message' with specific verb 'decode' and resource 'ZWC message'. It further details extraction and decoding of binary, distinguishing it from sibling tools like text_zwc_detect and text_zwc_embed.
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. While the purpose is clear, the description does not mention prerequisites, limitations, or cases where other tools (e.g., detect or embed) should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Auto-detect steganography in an AVI video. Runs LSB analysis on the first few frames, checks for appended data after the RIFF container, and analyzes frame size variance for anomalies.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to AVI video file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially covers behavior: it mentions running LSB analysis on 'first few frames' and checking for appended data. However, it does not disclose whether the tool modifies the file, or what the output format is. It is moderately transparent but could be more 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?
Two sentences with no extraneous words. First sentence states purpose, second details methods. Efficient and 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's multi-method approach and lack of output schema, the description should explain what results are returned (e.g., detection status, confidence). It only says 'auto-detect' without specifying output format. Also, no mention of prerequisites or limitations. Leaves 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 coverage is 100% for the single parameter 'file_path', described as 'Path to AVI video file'. The description adds no new semantic meaning beyond confirming it's an AVI video. Baseline score of 3 applies since schema already documents it.
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 explicitly states it auto-detects steganography in AVI video, listing specific techniques (LSB analysis, appended data, frame size variance). This clearly distinguishes it from sibling tools like video_eof_data or video_frame_lsb, which focus on individual aspects.
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 vs alternatives. For example, it doesn't mention that other video tools like video_frame_lsb or video_eof_data might be more appropriate for targeted analysis. The agent must infer usage from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect and analyze data appended after the AVI RIFF container EOF. Reports the offset, size, entropy, and hex dump of any trailing data that may contain hidden payloads.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to AVI video file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses what the tool reports (offset, size, entropy, hex dump) and mentions hidden payloads, providing good transparency without contradictions.
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 purpose, no extraneous 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 one required parameter, no output schema, and a simple detection/analysis tool, the description fully covers what the tool does and reports.
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 100%, so baseline is 3. The description does not add meaning beyond the schema parameter description 'Path to AVI video file'.
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 uses specific verb-detect/analyze-and explicitly states the resource-AVI RIFF container EOF. It reports offset, size, entropy, and hex dump, clearly distinguishing from sibling tools like video_structure or video_frame_compare.
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 use when suspecting hidden data after the AVI container EOF, but does not provide explicit when-to-use or when-not-to-use guidance, nor mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare adjacent video frames for pixel-level anomalies. Computes byte-level diff, Mean Squared Error (MSE), and PSNR between two frames to detect steganographic modifications.
| Name | Required | Description | Default |
|---|---|---|---|
| frame_a | No | First frame index (default: 0) | |
| frame_b | No | Second frame index (default: 1) | |
| file_path | Yes | Path to AVI video file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses computing three metrics and comparing two frames. However, it says 'adjacent' but parameters allow arbitrary indices, which is a minor inconsistency. Does not mention performance or error conditions.
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, no wasted words. First sentence states purpose, second lists metrics. Efficient and 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 no output schema, description does not explain return format. It adequately covers what the tool does and metrics computed. Missing details on error handling or edge cases, but sufficient for a simple comparison 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 coverage is 100%, but description adds context: explains frame indices, default values, and file_path type (AVI). The term 'adjacent' adds meaning but conflicts with flexible indices. Adds value beyond 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?
Description clearly states verb 'compare' and resource 'adjacent video frames', and specifies purpose of detecting pixel-level anomalies with specific metrics (byte diff, MSE, PSNR). It distinguishes from sibling tools like img_compare and video_inter_frame.
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?
Description implies usage for steganography detection in video frames but does not explicitly state when to use this tool vs alternatives like video_inter_frame or img_compare. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract LSB data from video frames as bytes. Collects the least significant bit from each byte of the specified frames and assembles them into a byte stream with hex dump and text preview.
| Name | Required | Description | Default |
|---|---|---|---|
| frames | No | Comma-separated frame indices to extract from (default: '0') | |
| file_path | Yes | Path to AVI video file | |
| max_bytes | No | Maximum bytes to extract (default: 4096) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full weight for behavioral disclosure. It describes the extraction process (collecting LSBs from each byte, assembling into a stream) and output format (hex dump, text preview). However, it omits details like error handling (e.g., out-of-bounds frames), performance implications, whether the file is modified (likely no), or any required codec support.
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 very concise (two sentences), front-loaded with the main action, and includes essential details about the output. 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?
There is no output schema, so the description should compensate by explaining the return structure. It mentions 'byte stream with hex dump and text preview' but does not specify how these are presented (e.g., JSON object keys, data types). This leaves the agent without clear guidance on consuming the tool's output. Given moderate tool complexity, more detail is needed.
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 100%, so the baseline is 3. The description mentions 'specified frames' but does not add new semantics beyond the schema's parameter descriptions (e.g., format of 'frames' as comma-separated, defaults). It does explain how parameters are used in the overall process, but that aligns with 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 action ('Extract LSB data from video frames as bytes') and the resource ('video frames'), with a specific technique (LSB). It explains the process and output (byte stream with hex dump and text preview). However, it does not distinguish from the sibling tool 'video_frame_lsb', which might be a detection variant, so not a perfect 5.
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 like 'video_frame_lsb' or 'video_detect'. There are no prerequisites, exclusions, or usage contexts mentioned. The description is purely functional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
LSB analysis of a specific video frame. Extracts the raw pixel data from the given frame index and checks LSB distribution, balance, and entropy.
| Name | Required | Description | Default |
|---|---|---|---|
| frame | No | Frame index to analyze (default: 0) | |
| file_path | Yes | Path to AVI video file |
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 describes the functional output (extracting data, checking statistics) but does not disclose whether the tool modifies files, requires permissions, 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 concise, consisting of two sentences that efficiently convey the tool's function without unnecessary details.
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 lacks details about return values or output format, and since there is no output schema, this is a gap. For a tool with two parameters, the description covers the main functionality but is incomplete regarding what the agent should expect in response.
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 100%, so both parameters are documented. The description adds value by explaining the 'frame' parameter context (given frame index) and the analysis outputs (LSB distribution, balance, entropy), which go 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 performs LSB analysis on a specific video frame, extracting raw pixel data and checking LSB distribution, balance, and entropy. This distinguishes it from sibling tools like video_frame_compare or video_frame_extract.
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 guidelines on when to use this tool versus alternatives, such as for steganography detection. The context implies usage for LSB-based steganalysis, but no exclusions or comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze frame types from the AVI idx1 index. Reports keyframe vs delta frame distribution, size statistics per type, and flag anomalies that may indicate steganographic manipulation.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to AVI video file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states what it reports but does not indicate whether the tool is read-only, requires special permissions, or has any side effects. The lack of explicit safety or non-destructive declaration is a gap.
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 that efficiently conveys the tool's purpose and outputs. It is front-loaded with the main action and followed by details. Slightly more structure could improve readability, but it is concise.
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 simple tool (one param, no output schema), the description covers the main outputs (distribution, size stats, anomalies) but does not specify the return format or how anomalies are flagged. More detail on what the tool returns would improve completeness.
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 100% coverage with a single parameter `file_path` described as 'Path to AVI video file'. The description does not add additional meaning beyond the schema, so a baseline of 3 is appropriate.
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 analyzes frame types from the AVI idx1 index, reports keyframe/delta distribution and size statistics, and flags anomalies for steganography. It distinguishes itself from sibling tools like video_frame_compare and video_structure by focusing specifically on the idx1 index.
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 steganographic analysis of AVI files but does not explicitly state when to use this tool over alternatives like video_frame_compare or video_structure. No exclusions or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract metadata from an AVI video file. Reports dimensions, FPS, codec, stream info, duration, and file-level properties.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to AVI video file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It correctly indicates a read-only operation ('extract metadata') but does not disclose potential side effects, file size limits, or permission requirements. The format constraint (AVI) is clear.
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 that efficiently conveys purpose and output categories without unnecessary words. It is front-loaded and concise.
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 lists essential metadata categories (dimensions, FPS, codec, stream info, duration, file-level properties) which gives a good sense of the return value, especially since no output schema exists. Missing details on edge cases but adequate for typical use.
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 one parameter 'file_path' exists, and both the schema and description describe it as 'Path to AVI video file'. Schema coverage is 100%, so the description adds no additional meaning beyond what the schema already provides.
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 metadata from AVI video files and lists specific outputs (dimensions, FPS, codec, stream info, duration, file-level properties). This distinguishes it from sibling tools that perform other operations like frame extraction or detection.
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 use when metadata from an AVI file is needed, but provides no explicit guidance on when not to use it or comparison to sibling tools (e.g., video_detect, video_frame_extract). No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Visualize the AVI/RIFF chunk structure as a tree. Shows all chunks, their FourCC codes, offsets, and sizes for forensic analysis of the container structure.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to AVI video file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the read-only visualization behavior and the types of data shown (chunks, FourCC, offsets, sizes). It does not mention performance or file size limits, but the core behavior is transparent.
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 brief sentences convey all necessary information without redundancy. Every word adds value, and the description is front-loaded with the key action and output.
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 simple input (one parameter) and no output schema, the description fully explains the tool's purpose, input, output format (tree with chunks, FourCC, offsets, sizes), and use case (forensic analysis).
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 100% for the single parameter file_path. The description adds context by specifying AVI/RIFF file type, which enhances understanding beyond the schema's 'Path to AVI video file'.
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 visualizes AVI/RIFF chunk structures as a tree, detailing chunks, FourCC codes, offsets, and sizes. This specific verb-resource pair distinguishes it from sibling video tools like video_metadata or video_detect.
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 forensic analysis of container structure, providing clear context. However, it does not explicitly state when to use this tool over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.0archive_commentarchive_detectarchive_extra_fieldsarchive_metadataarchive_polyglotarchive_slackarchive_structurebpcs_capacitybpcs_complexity_mapbpcs_detectbpcs_extractbpcs_thresholdcreate_commentcreate_eof_injectcreate_metadatacreate_null_ciphercreate_palettecreate_polyglotcreate_whitespacegif_appextgif_commentgif_detectgif_frame_analysisgif_lzw_analysisgif_palettegif_palette_lsbgif_structurejpegadv_calibrationjpegadv_chi_slidingjpegadv_compatibilityjpegadv_f5_detectjpegadv_jsteg_detectjpegadv_outguess_detectjpegadv_pvd_detectmp3_detectmp3_frame_analysismp3_id3_hiddenmp3_metadatamp3_paddingmp3_sample_analysismp3_structurenet_detectnet_dns_tunnelnet_http_headernet_icmp_payloadnet_ip_headernet_statsnet_tcp_headernet_timingqr_compareqr_data_extractqr_detectqr_ecc_analysisqr_module_analysisqr_structurespread_correlationspread_dft_analysisspread_noise_analysisspread_patchworkspread_watermark_detectvideo_detectvideo_eof_datavideo_frame_comparevideo_frame_extractvideo_frame_lsbvideo_inter_framevideo_metadatavideo_structurev0.1.0audio_detectaudio_echo_detectaudio_lsb_detectaudio_lsb_extractaudio_metadataaudio_silenceaudio_spectrumcrypto_decodecrypto_detectcrypto_entropycrypto_frequencycrypto_hash_idcrypto_patternscrypto_xordoc_html_hiddendoc_pdf_hiddendoc_pdf_metadatadoc_pdf_streamsdoc_xml_metadatafile_appendedfile_comparefile_embeddedfile_entropyfile_entropy_visualfile_headerfile_hexfile_identifyfile_polyglotfile_stringsimg_appended_dataimg_bitplaneimg_channel_analysisimg_chi_squareimg_compareimg_detectimg_entropy_mapimg_histogramimg_known_toolsimg_lsb_detectimg_lsb_embedimg_lsb_extractimg_metadataimg_rs_analysisjpeg_commentjpeg_dct_histogramjpeg_double_compressionjpeg_exif_deepjpeg_quantizationjpeg_structurejpeg_thumbnail_comparetext_acrostictext_detecttext_homoglyphtext_invisible_scantext_unicode_analysistext_whitespace_detecttext_whitespace_extracttext_zwc_detecttext_zwc_embedtext_zwc_extractMany tools overlap in purpose, such as multiple LSB detection tools (img_lsb_detect, img_chi_square, img_rs_analysis) and numerous JPEG analysis tools, making it difficult for an agent to distinguish between them. While some tools have distinct focuses, the sheer number and similarity of detection tools cause significant ambiguity.
Tool names follow a mostly consistent pattern: format prefix plus action (e.g., audio_lsb_detect, video_frame_extract). However, there are deviations like 'create_whitespace' without a format prefix and the 'jpegadv_' prefix for advanced JPEG tools, which slightly breaks the pattern. Overall, naming is clear and predictable.
128 tools is extremely high for a single MCP server, far exceeding typical scopes (3-15 tools). This overwhelms the agent's selection process and suggests the server should be split into multiple smaller, focused servers (e.g., image-stego, audio-stego, network-stego).
The toolset covers an impressively broad range of steganographic techniques across many file formats (images, audio, video, text, network, etc.), including detection, extraction, and embedding. Minor gaps exist (e.g., no MP4 video support), but overall the coverage is thorough and leaves few workflow dead-ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
49 free agent tools: WHOIS, PDF to text, email checks, FX rates, X12 EDI, JSON repair. No API key.
62 real-world tools for agents: search, scraping, social, enrichment, image, video, voice.
150+ vertical AI expert bots as agent tools. $1 bots run on YOUR machine - your data stays yours.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/badchars/steganography-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
