Skip to main content
Glama

Create Artifact Provenance

create_artifact_provenance
Read-onlyIdempotent

Tag agent-generated artifacts with provenance metadata, including content hash, risk class, and authoring agent, to enable traceability and policy compliance.

Instructions

Tag an agent-generated artifact with provenance metadata (content hash, risk class, authoring agent).

Input Schema

NameRequiredDescriptionDefault
contentYesThe artifact content (used for hash, not stored)
risk_classYes
trust_epochNo
valid_untilYes
intended_useYes
artifact_typeYese.g. email_draft, code_script, database_query
delegation_refYes
requires_human_executionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv4.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Addedv2.8.0

TDQS

C2.7/5.0
Behavior1/5

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

The annotations declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, yet the description frames the operation as creating/tagging an artifact with provenance metadata — a state-changing write. This directly conflicts with the read-only annotation, mirroring the calibration's create_record contradiction. No compensating behavioral context (where the tag is persisted, whether a receipt is returned) is given.

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?

A single front-loaded sentence with no filler; the core purpose is stated immediately. It is terse to the point of under-specification for an 8-parameter tool, but the structure itself is efficient.

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

Completeness2/5

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

With 8 parameters, 6 required, 25% schema coverage, and no output schema, this tool demands more explanation than one sentence. Critical concepts — delegation_ref scoping, trust_epoch semantics, valid_until expiry, and the requires_human_execution gate — are not addressed, and the write/read ambiguity is left unresolved.

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 description coverage is only 25% (8 params, 6 required). The description adds meaning for a few fields — content hash maps to content, 'risk class' maps to risk_class, and 'authoring agent' loosely points at delegation_ref — but leaves intended_use, valid_until, trust_epoch, and requires_human_execution entirely unexplained, so it only partially compensates for the coverage gap.

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

Purpose4/5

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

States a specific verb (tag) and resource (agent-generated artifact) and enumerates the metadata being attached (content hash, risk class, authoring agent), so the agent knows what the call accomplishes. It does not differentiate itself from provenance-adjacent siblings such as create_derivation_receipt, create_decision_lineage_receipt, or aps_create_attribution_receipt.

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

Usage Guidelines2/5

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

The description gives no when-to-use, when-not-to-use, prerequisites, or alternative tool. An agent cannot infer from this text why it would call create_artifact_provenance rather than one of the many other receipt/attestation-creating siblings.

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

Deploy Server

Other Tools