An MCP server that lets AI agents mark the images and audio they generate for the EU AI Act's Article 50, using Markproof: an invisible watermark plus a signed C2PA manifest (Content Credentials), and verification of any file.
Is your AI output Article 50-ready? Drop a file into the free checker (no signup) to see whether it carries a watermark and signed Content Credentials.
Tool | What it does |
| Watermarks and C2PA-signs a local image (PNG, JPEG, WebP) or audio file (WAV, MP3). Writes the marked copy beside the original as |
| Checks a file for a Markproof watermark and a C2PA manifest, whether the signature is valid, and whether it matches your account's records. |
| Looks up a file you marked by its |
mark_file and verify_file each count as one API call against your plan. get_asset is free.
Related MCP server: chronoverify-mcp
Create an API key on your Markproof dashboard (250 free calls a month).
Add the server to your MCP client.
Claude Desktop — claude_desktop_config.json:
{
"mcpServers": {
"markproof": {
"command": "npx",
"args": ["-y", "markproof-mcp"],
"env": { "MARKPROOF_API_KEY": "lt_live_..." }
}
}
}Claude Code:
claude mcp add markproof --env MARKPROOF_API_KEY=lt_live_... -- npx -y markproof-mcpCursor — .cursor/mcp.json: the same mcpServers block as Claude Desktop.
Then ask your agent something like "Generate a product image and mark it with Markproof before saving it."
Variable | |
| Required. |
| Optional, for testing against another deployment. Default |
Keep your key out of shared config files and version control.
Files are sent to Markproof's API, which processes them in the EU and doesn't keep them.
Direct uploads are limited to about 4.5 MB per file. For bigger files, give verify_file a public url instead of a path (up to 25 MB). Marked audio comes back as WAV, so this matters for clips over about 25 seconds.
If a result includes watermark_robust: false, the image was too smooth or featureless for a robust watermark. It's still marked and signed; rely on the C2PA manifest for that file.
Each release has a markproof-mcp.mcpb bundle: double-click it to install in Claude Desktop, which asks for your API key and keeps it in the OS keychain.
npm install
npm test # tools against a fake client, no network
npm run build # dist/ for npm
npm run bundle # markproof-mcp.mcpb (one-file server + manifest in mcpb/)
npm run bundle:smithery # same plus tool input schemas, which Smithery needs and the MCPB spec rejectsThe server is a thin layer over the markproof SDK. Issues and PRs welcome.
MIT
Fetches the record for a file this account marked, by the asset_id that mark_file returned. Doesn't count toward the quota.
| Name | Required | Description | Default |
|---|---|---|---|
| asset_id | Yes | The asset_id returned by mark_file. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the bar is lower. The description adds a genuinely useful behavioral fact not in the annotations — that calls don't count toward the quota — though it says nothing about what happens when the asset_id is unknown.
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 tight sentences with no filler; the retrieval action and its provenance constraint are front-loaded, and the quota note is a compact second sentence.
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 read-only lookup with no output schema, the definition gives the agent everything needed to act. The only gap is behavior on a missing or invalid asset_id, which would be helpful but is not essential.
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 schema already describes asset_id as coming from mark_file, so the description's mention of the same origin adds no new meaning. Baseline 3 applies when the schema carries full parameter documentation.
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 verb and resource ('fetches the record for a file this account marked') and scopes it to a single asset. It ties the input to the mark_file sibling, though it does not explicitly contrast with verify_file.
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?
It states the prerequisite context clearly: call this with the asset_id that mark_file returned. There is no explicit when-not-to-use guidance or mention of verify_file as an alternative, leaving the agent to infer the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Adds an invisible watermark and a signed C2PA manifest (Content Credentials) to an AI-generated image (PNG, JPEG, WebP) or audio file (WAV, MP3), marking it as AI-generated for EU AI Act Article 50. Writes the marked copy next to the original (images as PNG, audio as WAV) and returns its watermark code and public verification URL. Use this on every image or audio file you generate before handing it to a user. Counts as one API call.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the local image or audio file to mark. | |
| overwrite | No | Allow replacing an existing file at output_path. Defaults to false. | |
| model_name | No | Name of the model that generated the file. | |
| output_path | No | Where to write the marked copy. Defaults to <name>.marked.<ext> beside the original. | |
| visible_label | No | Images only. Also draw a visible label on the image (EU AI Act Art. 50(4), e.g. for deepfakes): true for "AI-generated", or custom text up to 40 characters. | |
| generator_name | No | Name of the app or system that generated the file; recorded in the C2PA manifest. | |
| label_position | No | Corner for visible_label. Defaults to bottom-right. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description discloses key side effects and outputs: it writes a marked copy next to the original, converts images to PNG and audio to WAV, returns a watermark code and public verification URL, and counts as one API call. These details substantially clarify behavior for a non-read-only, open-world 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 front-loaded with the core action, followed by usage, output behavior, and cost context. It is dense but every sentence contributes useful information 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?
Given moderate complexity and no output schema, the description supplies the essential missing context: supported formats, output location and format conversion, return values, legal purpose, and API cost. An agent has enough information 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 description coverage is 100%, so every parameter is already documented in the schema. The description adds high-level context about supported file types and output behavior but does not explain individual parameter semantics beyond what the schema provides, 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 states a specific verb and resource: adding an invisible watermark and signed C2PA manifest to AI-generated image or audio files. It is clear what the tool does, but it does not explicitly differentiate itself from siblings like verify_file or get_asset.
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?
It gives a clear usage directive: use this on every generated image or audio file before handing it to a user. It does not explicitly name alternatives or when not to use it, but the intended context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks an image or audio file for a Markproof watermark and a C2PA manifest, and reports whether its signature is valid and whether it matches a record in this Markproof account. Use it to confirm a file is marked before publishing, or to inspect a file of unknown origin. Counts as one API call.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Public https URL of the file, instead of path. Use it for files over 4.5 MB (up to 25 MB), e.g. marked audio, which is WAV. | |
| path | No | Path to the local image or audio file to check. Uploads are limited to about 4.5 MB. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds genuinely new context: the call consumes API quota ('Counts as one API call') and the result includes both signature validity and a match against the account's records. It doesn't cover limits like per-account quotas or failure modes for unmarked files, but what it adds is substantive.
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 what is inspected, followed by when to use it, then the cost note. Nothing is redundant and no sentence could be dropped 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?
With no output schema, the description does the right thing by naming the reported fields (signature validity, record match). Read-only and open-world behavior are covered by annotations. It is slightly thin on what an unmarked or unmatched file returns versus an error, but it is largely complete for a two-parameter check 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% and both parameters are documented with size limits and the 4.5 MB vs 25 MB URL/path split. The description only restates 'image or audio file' and adds no format, precedence, or mutual-exclusivity guidance (e.g. what happens if both url and path are supplied). Baseline 3 applies where the schema carries the weight.
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 ('Checks an image or audio file') and enumerates exactly what it inspects: Markproof watermark, C2PA manifest, signature validity, and account record match. That scope is inherently distinct from the sibling mark_file (which writes a mark) and get_asset, so an agent can pick correctly without opening either 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?
Gives two concrete usage conditions: confirming a file is marked before publishing, and inspecting a file of unknown origin. It stops short of naming mark_file as the alternative for the 'file is not yet marked' case, so the routing is clear but not fully explicit.
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.1.0get_assetmark_fileverify_fileScored across 3 tools
Each tool targets a distinct action on a distinct input: mark_file writes a watermark to a file, verify_file inspects an arbitrary file for marks, and get_asset retrieves a stored record by asset_id. The descriptions make the file-path vs asset_id boundary explicit, so misselection is unlikely despite the shared 'record lookup' element in verify_file.
All three tools follow a clean verb_noun pattern (mark_file, verify_file, get_asset) with consistent snake_case. The conventions are predictable enough that a caller can guess naming for any future tool.
Three tools map exactly onto the narrow workflow of write-mark, check-mark, and fetch-record; nothing feels redundant or padded. This sits at the low end of the ideal 3-15 range but is well-matched to a single-purpose watermarking service.
The core lifecycle (mark, verify, retrieve by id) is fully covered with no dead ends for the primary use case. The main gap is the absence of a list/enumerate operation for assets marked by the account, so an agent must persist asset_ids itself; revocation or quota-checking is also absent but less critical.
Mark: stamp files with a signed, timestamped provenance record. Hash locally; verify free.
Agent Content Watermark MCP — dedicated EU AI Act Article 50(2) GenAI watermarking. Visible +
Inspect and remove C2PA content credentials from AI-generated images, video and audio. Free, no key.
Tamper-evident proof creation and verification for AI agents via MCP, A2A, and REST.