Click on "Deploy 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., "@image-forensics-mcp Analyze this image for AI generation: /path/to/image.jpg"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server that gives AI assistants forensic analysis capabilities to help detect AI-generated images. Uses noise maps, Error Level Analysis, FFT frequency analysis, spectral decay analysis, color channel analysis, and metadata inspection.
One command — requires uv:
claude mcp add -s user image-forensics -- uvx --from git+https://github.com/surewht/image-forensics-mcp image-forensics-mcpThat's it. Restart Claude Code and the tools are available.
git clone https://github.com/surewht/image-forensics-mcp.git
cd image-forensics-mcp
claude mcp add -s user image-forensics -- uvx --from . image-forensics-mcpAdd to ~/.claude.json:
{
"mcpServers": {
"image-forensics": {
"type": "stdio",
"command": "uvx",
"args": ["--from", "git+https://github.com/surewht/image-forensics-mcp", "image-forensics-mcp"]
}
}
}Related MCP server: Image MCP Server
Tool | What it does |
| Extracts the noise pattern by subtracting a blurred version. AI images have unnaturally uniform noise. Returns visualization + statistics. |
| Multi-scale ELA — resaves at multiple JPEG qualities and analyzes error patterns. Detects splicing and compression inconsistencies. |
| 2D FFT spectrum analysis. Detects GAN grid artifacts and unusual frequency distributions. |
| Power spectral density curve fitting (1/f^β). Based on CVPR 2025 research. Natural images follow characteristic decay; AI images may deviate. |
| RGB channel correlation, gradient correlation, entropy, and saturation analysis. Based on CVPR 2025 "Secret Lies in Color" research. |
| EXIF/metadata inspection for AI tool signatures (Stable Diffusion, DALL-E, Midjourney, etc.) + AI resolution fingerprinting. |
| Runs all 6 analyses, saves visualizations to |
In Claude Code, just ask:
Analyze this image for AI generation: /path/to/image.jpgOr use individual tools:
Run a noise map analysis on /path/to/image.png
Check the metadata of /path/to/image.webpThe full_forensic_report categorizes findings into three tiers:
Tier | What triggers it | Example |
Definitive | AI tool signatures in metadata (SD parameters, generation prompts) | Stable Diffusion PNG with |
Strong | Forensic anomalies rarely seen in real photos (uniform noise, GAN artifacts, spectral anomalies, extreme saturation) | GAN periodic patterns in FFT spectrum |
Weak/Ambiguous | Indicators also caused by social media processing (no EXIF, AI-typical resolution, uniform ELA) | Facebook-resized 768x768 JPEG with stripped metadata |
AI-GENERATED — Definitive metadata proof found
LIKELY AI-GENERATED — 3+ strong forensic anomalies
POSSIBLY AI-GENERATED — 1-2 strong anomalies
INCONCLUSIVE — Only weak/ambiguous indicators
LIKELY AUTHENTIC — Minimal indicators, consistent with normal processing
NO INDICATORS — Clean across all analyses
Modern AI generators (Flux, DALL-E 3, Midjourney v6+) produce images that are nearly indistinguishable from real photos at the pixel level. This tool works best when:
Metadata is intact — SD parameters, generation prompts = definitive proof
Images show GAN artifacts — periodic patterns in FFT = strong signal
Images haven't been re-compressed — social media platforms strip metadata and resize to AI-typical dimensions, creating ambiguity
For ambiguous cases, visual inspection (teeth, hands, text, reflections, lighting inconsistencies) combined with these forensic tools gives the best results.
Python >= 3.10
uv (for uvx install method)
Dependencies (installed automatically): mcp[cli], Pillow, numpy, scipy
MIT
Analyze color channel correlations, saturation, and entropy for AI detection.
Based on CVPR 2025 "Secret Lies in Color" — AI-generated images show unusual RGB channel correlations, gradient patterns, and saturation distributions compared to natural photographs.
Args: image_path: Absolute path to the image file.
| Name | Required | Description | Default |
|---|---|---|---|
| image_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It discloses the analytical method and its theoretical basis, but says nothing about cost, determinism, supported formats, or failure behavior for unreadable paths. Since the tool is an analysis operation, the method disclosure is real value, but operational traits 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?
Two short blocks, front-loaded with what gets analyzed before the research citation and the argument note. Slightly more prose than strictly necessary in the citation sentence, but every part maps to purpose or parameter guidance.
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?
An output schema exists, so return values need not be explained, and the single required parameter is documented with its absolute-path constraint. What remains missing is routing guidance relative to the six sibling forensic tools, which matters given how many overlapping analyses are offered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema only names the parameter as 'Image Path'. The description compensates meaningfully by specifying it must be an absolute path to the image file, which is exactly the kind of constraint the schema omits. It stops short of listing supported extensions or size limits.
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 names a specific analytical action (channel correlations, saturation, entropy) on a specific resource (the image at image_path) and frames it against a named use case (AI detection). Against siblings like noise_map, frequency_analysis, and spectral_decay_analysis, the color-domain scope makes it immediately distinguishable without opening any schema.
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 a purpose ('for AI detection') and cites the underlying CVPR 2025 research, which implies when it's useful, but it never states when to prefer this over noise_map, error_level_analysis, or frequency_analysis, nor any precondition such as image format. Usage is inferred rather than prescribed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform multi-scale Error Level Analysis (ELA) on an image.
Resaves at multiple JPEG quality levels and analyzes the error patterns. Includes consistency analysis across scales for better AI detection.
Args: image_path: Absolute path to the image file. quality: Primary JPEG quality for visualization (1-100). Default 90.
| Name | Required | Description | Default |
|---|---|---|---|
| quality | No | ||
| image_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 describes the method (resaving, analyzing error patterns) but does not state whether the original image is modified, whether temporary files are created, permission requirements, 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?
The description is front-loaded with the purpose and method, then lists arguments efficiently. It avoids redundancy, though the Args section partially repeats schema 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?
Output schema exists, so return values need not be explained. However, with no annotations and no usage guidance relative to siblings, the description leaves gaps about when to choose this forensic method and whether it has side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It documents both parameters: image_path as an absolute path and quality as the primary JPEG quality (1-100, default 90), adding meaning beyond the schema's bare titles and default.
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 a specific verb and resource: 'Perform multi-scale Error Level Analysis (ELA) on an image.' It further specifies resaving at multiple JPEG quality levels and consistency analysis, clearly distinguishing this technique from sibling forensic 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 mentions 'for better AI detection' but does not state when to use this tool versus alternatives like noise_map or frequency_analysis. No explicit when-to-use, exclusions, or routing guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform FFT frequency analysis on an image.
Analyzes the frequency spectrum for artifacts common in AI-generated images, including grid patterns, spectral peaks, and unusual energy distribution.
Args: image_path: Absolute path to the image file.
| Name | Required | Description | Default |
|---|---|---|---|
| image_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It usefully discloses what the analysis looks for (grid patterns, spectral peaks, energy distribution), but does not state that it is a read-only operation, whether it modifies or caches anything, or how heavy the computation is on large images.
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?
Front-loaded purpose sentence followed by a tight explanation of the detected artifacts and a compact Args block. No filler, though the Args restatement overlaps with the schema.
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?
Output schema exists, so return-value documentation is not required, and the description covers purpose, target artifacts, and the single parameter's expected form. It would be stronger with a hint about when to choose this tool versus the sibling analyses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the schema only carries a bare 'Image Path' title, so the description's 'Absolute path to the image file' adds genuinely useful semantics (absolute requirement, points at a file, not a directory or URL). One trivial parameter means little more is needed.
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?
States a specific verb+resource ('Perform FFT frequency analysis on an image') and goes further by naming what it detects (grid patterns, spectral peaks, unusual energy distribution). An agent can distinguish it from siblings like spectral_decay_analysis or noise_map by the FFT/spectral-artifact focus.
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 by noting the technique targets artifacts common in AI-generated images, so an agent can infer the forensic context. However it never states when to prefer this over spectral_decay_analysis or the full_forensic_report, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run all forensic analyses and produce a comprehensive report with overall verdict.
Combines noise map, ELA, frequency analysis, spectral decay, color analysis, and metadata check. Saves visualization images to /tmp/image-forensics/ and returns text-only results to avoid output overflow.
Args: image_path: Absolute path to the image file.
| Name | Required | Description | Default |
|---|---|---|---|
| image_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does add real behavioral context: it writes visualization images to /tmp/image-forensics/ and deliberately returns text-only results 'to avoid output overflow.' That side-effect and output-format disclosure is valuable. It still omits permission/error behavior and runtime cost of running all six analyses.
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?
Front-loaded with the core purpose, then side effects, then the arg. The Args block slightly repeats the schema but adds the 'absolute path' qualifier so it mostly earns its place. No filler, but not maximally tight.
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?
Output schema exists so return-value detail needn't be explained, and the description correctly states the shape (text-only, images saved to a path). With one required param and no nested objects, the description covers what an agent needs. It could note failure behavior when an analysis errors, but overall it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does: 'image_path: Absolute path to the image file' adds a constraint (absolute, not relative) beyond the bare schema type. Minor gap is that it doesn't clarify supported formats, but for a single path arg this is solid.
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?
Specific verb+resource: 'Run all forensic analyses and produce a comprehensive report with overall verdict.' It explicitly enumerates the six analyses it combines (noise map, ELA, frequency, spectral decay, color, metadata), so an agent can immediately distinguish it from the sibling tools that each do one 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?
'Run all forensic analyses' clearly signals this is the aggregate tool versus the individual sibling tools, so usage context is well implied. However, it never explicitly says when to prefer this over the individual analyses (e.g., 'use when you need everything at once, otherwise call the specific analysis').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check image metadata/EXIF for AI generation signatures and resolution fingerprints.
Looks for known AI tool signatures, unusual metadata patterns, missing camera information, and AI-typical output resolutions.
Args: image_path: Absolute path to the image file.
| Name | Required | Description | Default |
|---|---|---|---|
| image_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, and it does disclose the internal checks performed (known AI tool signatures, unusual metadata patterns, missing camera info, AI-typical resolutions), which is useful. However it never states that the operation is read-only/non-destructive, nor any failure behavior for unreadable or stripped-metadata images, leaving key behavioral traits to inference.
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?
Front-loads the purpose in the first sentence, then lists the detection targets, then the argument. Well ordered with no filler, though the four detection bullets could be tightened into one sentence without losing 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?
For a single-parameter read-only analysis tool with an output schema present, the definition covers what it does and the one required argument. The remaining gap is the absence of any annotation or statement about safety/read-only behavior and error handling for images lacking metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the schema property carries only the title 'Image Path', so the description's Args block is the sole source of meaning — it specifies the path must be absolute. That is a meaningful constraint beyond the schema, though no format/extension examples are given.
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?
States a specific verb (check) and a specific resource (image metadata/EXIF), plus the two things it looks for: AI generation signatures and resolution fingerprints. This inherently distinguishes it from siblings like noise_map, frequency_analysis, and color_analysis, which operate on different image characteristics.
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?
Usage is implied by the forensic framing (use to detect AI-generated images), but the description never states when this tool is preferable to siblings such as full_forensic_report or error_level_analysis, nor any prerequisites or exclusions. The agent must infer placement in the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract the noise pattern from an image to help detect AI generation.
Subtracts a Gaussian-blurred version from the original to isolate noise. AI-generated images tend to have unnaturally uniform or structured noise.
Args: image_path: Absolute path to the image file. blur_sigma: Gaussian blur sigma (higher = more smoothing). Default 3.0.
| Name | Required | Description | Default |
|---|---|---|---|
| blur_sigma | No | ||
| image_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the underlying algorithm (subtracting a Gaussian-blurred version) and interpretation guidance ('AI-generated images tend to have unnaturally uniform or structured noise'). It omits file-format support, failure behavior, and permission needs, but the algorithmic and interpretive disclosure is substantial.
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?
Front-loads the purpose in the first sentence, then adds mechanism and interpretation. The Args block is efficient; slight redundancy between the opening line and the third sentence, but no significant 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?
An output schema exists, so return values need not be explained, and both parameters are documented. For a two-parameter analysis tool the description is nearly complete; only the routing against sibling analyses 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 description coverage is 0%, so the description must compensate, and it does: image_path is specified as an absolute path, and blur_sigma is explained as a smoothing strength with a stated default of 3.0, matching the schema default.
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?
States a specific verb and resource ('Extract the noise pattern from an image') plus the intended goal ('help detect AI generation'). It is clearly distinguishable from siblings like error_level_analysis, frequency_analysis, and spectral_decay_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 stated goal (AI-generation detection) implies when the tool is relevant, but there is no explicit guidance on when to prefer this over the six sibling forensic tools, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze the power spectral density decay curve of an image.
Natural images follow a characteristic 1/f^beta power law. AI-generated images (especially from diffusion models) often show different decay slopes and anomalies in specific frequency bands. Based on CVPR 2025 research.
Args: image_path: Absolute path to the image file.
| Name | Required | Description | Default |
|---|---|---|---|
| image_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It usefully explains the analytical basis (1/f^beta power law, anomalous decay slopes, CVPR 2025 research), which helps interpret results, but says nothing about cost, permissions, determinism, or limits of the analysis. A moderate score reflects domain context without operational 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?
Front-loaded with the core action, followed by brief domain motivation and a compact Args block. Every sentence is relevant, though the research citation is decorative rather than actionable.
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?
An output schema exists, so return values need not be described, and the single parameter plus its format are covered. For a one-parameter analysis tool with no annotations, the description supplies adequate context, though sibling routing remains absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and there is a single parameter, so the description must compensate. It does, stating that image_path is an 'Absolute path to the image file', which conveys the required path format beyond the bare schema title.
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?
States a specific verb and resource ('analyze the power spectral density decay curve of an image') plus the detection rationale, so the agent knows exactly what operation runs. It does not, however, distinguish itself from the sibling frequency_analysis, which plausibly covers overlapping frequency-domain ground.
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?
Usage is only implied via the AI-generated-image detection framing ('AI-generated images often show different decay slopes'); there is no explicit when-to-use, when-not, or named alternative among the six siblings. The agent must infer that this is for diffusion-model forensics rather than, say, generic frequency inspection.
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.
v0.2.0color_analysiserror_level_analysisfrequency_analysisfull_forensic_reportmetadata_checknoise_mapspectral_decay_analysisScored across 7 tools
Each tool targets a distinct forensic method (noise, ELA, FFT, spectral decay, color, metadata). However, frequency_analysis and spectral_decay_analysis both operate in the frequency domain and could be confused by an agent unfamiliar with the specific techniques. The descriptions clarify the differences, so overlap is limited.
Six of seven tools follow a consistent noun_analysis or noun_check pattern (e.g., noise_map, frequency_analysis, metadata_check). The outlier is full_forensic_report, which is a different type (aggregate report) but its name is still descriptive. Minor deviation from a strict pattern.
Seven tools is well-scoped for an image forensics server. Each tool provides a distinct analysis technique, and the inclusion of a full report tool adds convenience without redundancy. No tool feels unnecessary or missing.
The surface covers multiple orthogonal forensic techniques: noise, compression artifacts, frequency domain, spectral decay, color, metadata, and a comprehensive aggregator. This is complete for the stated purpose of AI image detection; no obvious gaps exist.
MCP server for NanoBanana AI image generation and editing
MCP server for Flux AI image generation
MCP server for Qwen Image 3 AI image generation
MCP server for Midjourney AI image generation and editing