GravityPort

asset_provenance_export

Read-only

Export a portable provenance bundle and unsigned C2PA assertion payload for a GravityPort asset, excluding prompts by default and never local paths or usernames; sign separately.

Instructions

Export a portable GravityPort provenance bundle plus an unsigned C2PA assertion payload. Prompts and user messages are excluded by default; pass includePrompts: true only when the user explicitly asks to include prompts. Local filesystem paths and usernames are never exported under any circumstances. This does not create a signed Content Credential; a C2PA signer must bind and sign the assertion separately.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "assetId": "<assetId>"
    },
    "name": "asset_provenance_export"
  }
}

Input Schema

Name	Required	Description	Default
`assetId`	Yes
`includePrompts`	No	Whether to include prompts and user messages. Defaults to false; pass true only when the user explicitly requests prompts. Local filesystem paths and usernames are never exported under any circumstances.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.11Nov 11, 2026

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint/openWorldHint=false, and the description adds real behavioral context on top: default prompt exclusion, an absolute rule that local paths and usernames are never exported, and the fact that the C2PA assertion is unsigned and must be bound by a separate signer. It stops short of saying where the bundle is delivered (inline payload vs. file write) or its size, which matters for a read-only export.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, front-loaded with the output artifacts, then the privacy rules, then the signing caveat. Efficient, though the 'local filesystem paths and usernames are never exported' sentence duplicates the schema's includePrompts description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and no description of the return shape (bundle returned inline, written to a path, or as separate files), which an agent needs to consume the result. Privacy and signing semantics are well covered, so the remaining gap is the delivery mechanism.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%; includePrompts is fully documented in both schema and description, but assetId is undocumented in either place and the description does not clarify its expected form or scope. The added-value language for includePrompts largely restates the schema, so this sits at the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb and two concrete artifacts: a GravityPort provenance bundle and an unsigned C2PA assertion payload. No sibling tool (asset_get, generation_lineage, asset_version_history) produces a portable provenance export, so the resource is distinguishable without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear conditional rule for the optional flag ('pass includePrompts: true only when the user explicitly asks') and a scope exclusion ('this does not create a signed Content Credential'). It does not name an alternative when an agent merely wants lineage or asset metadata, so routing is clear on when-not-to-expect-signing but not on sibling selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.