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., "@Check AI Free MCP Server is this image AI-generated? https://example.com/suspect.png"
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.
Official MCP adapter for Check AI Free. It uploads a selected image for source/header inspection and returns editable metadata observations with limitations. It does not verify C2PA signatures, authenticate an origin or identify an exact generator.
{
"mcpServers": {
"checkaifree": {
"command": "npx",
"args": ["-y", "checkaifree-mcp"]
}
}
}Use this stdio configuration in an MCP client that supports local commands. No service API key or account is required; rate limits and availability apply.
Related MCP server: img-convert MCP Server
detect_ai_image: accepts one of image_url, file_path, or image_base64. Read source observations; metadata-only readings do not display a model percentage.
inspect_c2pa_provenance: accepts image_url or file_path. The historical tool name is retained for compatibility. It observes source markers and camera fields; signatures, asset binding and certificate trust are not verified.
Supported inputs: JPEG, PNG and WebP up to 10 MiB. A supplied URL is fetched by this Node process; the selected image bytes and filename are then sent to the Check AI Free backend. Local files and base64 input are also uploaded. This adapter is not an in-browser/local-only checker. Do not supply sensitive images without reviewing image handling.
The current adapter calls the source/header endpoint. It does not run the website's separate image re-encoding/pixel-model fallback. Missing metadata can therefore remain inconclusive. Use the website for the full user-facing flow. Source text is editable; no metadata observation or model estimate is proof of authenticity or account identity.
An illustrative source-only response might say:
Source text suggests AI generation. No completed model score; source clues alone do not establish a probability. Source fields are editable. C2PA signatures are not verified.
This is an explanation of output semantics, not an accuracy benchmark. The method page documents the product's capabilities and limits.
npm ci
npm test
npm pack --dry-runThe default tests are offline: output semantics, protocol initialization/tool discovery and missing-input rejection. test:live retains the legacy integration runner and requires explicit review of its fixtures and network requests before use. Release checks do not need paid provider calls.
Source: hyai-dev/checkaifree-mcp. MIT license; see LICENSE.
Uploads a selected image for header/source-clue inspection. Returns editable source observations and limitations, not authenticated origin or exact model attribution. This adapter does not run the website's pixel-model fallback.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | No | Absolute or relative local file path to an image file (JPEG, PNG, WebP) | |
| image_url | No | Direct public HTTP/HTTPS URL of the image to analyze | |
| image_base64 | No | Base64 encoded image data string (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does real work: it discloses the result class ('editable source observations and limitations'), explicitly bounds reliability (not authenticated origin or exact model attribution), and flags a capability gap (no pixel-model fallback). It still says nothing about auth, upload persistence, file-size limits, or processing cost.
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 tight sentences, front-loaded with the action and scope before the caveats. Every clause adds a constraint, though the middle sentence packs result semantics and disclaimers densely.
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 no annotations, so the description must cover both behavior and results; it partially does by characterizing the return as source observations and limitations. Still missing are upload/retention behavior, auth or rate-limit expectations, and any sense of how 'editable source observations' are shaped.
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 all three input paths (local path, direct URL, base64) are already documented in the schema. The description adds no parameter-level guidance, so the 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?
States a specific verb+resource (upload an image) and the actual analysis performed (header/source-clue inspection), and explicitly disclaims what it does NOT return (authenticated origin, exact model attribution). It doesn't name the sibling inspect_c2pa_provenance, so the routing distinction is only implicit.
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 scope statement ('header/source-clue inspection') and the negative caveats rule out some intents, but no explicit when-to-use, when-not-to-use, or alternative tool is named. The agent must infer that provenance questions belong to the sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Observes source strings and camera metadata. Does not verify C2PA signatures, certificate trust or authenticity.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | No | Local file path to the image on disk | |
| image_url | No | Direct public URL of the image to inspect for C2PA credentials |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose one important limitation: signature/trust/authenticity are not verified. It says nothing about read-only behavior, error handling when no C2PA data is present, or the shape of the observation result, so the disclosure is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero filler, with the core function stated first and the critical scope limitation immediately after. Nothing is redundant or padded.
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 two-optional-parameter, no-annotation, no-output-schema inspection tool, the description covers scope but not the expected return content or the relationship between the mutually substitutable file_path/image_url inputs. Adequate but leaves gaps an agent must resolve by trial.
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 both file_path and image_url are already documented in the schema and the baseline is 3. The description adds no parameter-level meaning, such as which parameter takes precedence or whether the two are mutually exclusive alternatives.
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 (observes) and the resource it reads (source strings and camera metadata), which is concrete enough that an agent knows what data comes back. It does not, however, reference the tool's sibling detect_ai_image or distinguish itself from it, which keeps it out of 5 territory.
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 negative clause ('Does not verify C2PA signatures, certificate trust or authenticity') implies when this tool is and is not the right choice, which is useful implicit guidance. There is no explicit when-to-use statement and no alternative tool named, so the routing burden is still on the agent.
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.
v1.0.1detect_ai_imageinspect_c2pa_provenanceScored across 2 tools
detect_ai_image and inspect_c2pa_provenance both inspect image source/metadata clues, creating some conceptual overlap. However, the descriptions distinguish them: one targets AI-generation signals, the other targets C2PA/camera provenance specifically.
Both tools follow a clean snake_case verb_noun pattern (detect_ai_image, inspect_c2pa_provenance). No stylistic deviations.
Two tools is thin even for a narrowly scoped image-forensics adapter. A couple of complementary operations (e.g. raw metadata extraction) could reasonably round it out.
The surface covers AI-signal detection and provenance inspection but is explicitly read-only with acknowledged limitations (no signature verification, no pixel-model fallback). Notable capabilities in the domain are missing, though the stated scope is narrow.
Verify photos are real camera captures, not AI: C2PA and RAW+JPEG forensics. OAuth or API key.
Inspect and remove C2PA content credentials from AI-generated images, video and audio. Free, no key.
Detect whether an image is AI-generated or real, with an AI-probability score and confidence.
Check whether a video was generated by AI (Sora, Veo, Kling, HeyGen and others).
