Skip to main content
Glama

create_envelope

Create a signed Git commit envelope with Ed25519 provenance metadata. Records commit producer, signing tool, and optional agent scope for auditability.

Instructions

Create a signed Git commit envelope with Ed25519 provenance metadata.

Records who produced a commit (human, agent, or CI), which tool signed it,
and optional bounded agent scope. Use after staging changes and before or
after ``git commit``. Side effects: may write ``.matrixscroll/envelopes/<sha>.json``
when ``save`` is true. Returns ``{ok, sha, envelope, path}`` on success.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
saveNoWhen true (default), persist the envelope under .matrixscroll/envelopes/.
signNoWhen true (default), Ed25519-sign the envelope with the active key store.
toolNoProducing tool name recorded in provenance, e.g. cursor or claude-code.
workspaceNoAbsolute or relative path to the Git repository root. Leave empty to auto-detect from the current working directory.
actor_typeNoProvenance actor label recorded in the envelope, e.g. agent, human, or ci.
commit_shaNoExisting commit to envelope (full or short SHA). Empty uses the staged commit or HEAD depending on hook context.
agent_scopeNoOptional path or glob limiting what an agent commit claims to touch.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations provided, the description fully discloses behavioral traits: it may write a file (side effect), returns a specific tuple, and involves signing. It also describes the provenance metadata recorded. No contradictions with any hypothetical annotations.

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

Conciseness5/5

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

The description is concise (three sentences) and well-structured: purpose first, then usage, side effects, and return. Every sentence provides essential information without redundancy.

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

Completeness5/5

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

Given 7 optional parameters with 100% schema coverage and an explicit output schema in the description, the description is complete enough. It covers purpose, timing, side effects, and return format, requiring no additional context.

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

Parameters4/5

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

Schema description coverage is 100%, baseline 3. The description adds context beyond the schema by explaining the overall purpose (provenance metadata, actor types) and that 'tool' records the producing tool name. It does not fully compensate for all parameters but adds meaningful extra information.

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?

The description clearly states it creates a signed Git commit envelope with Ed25519 provenance metadata, specifying the resource (envelope) and action (create). It distinguishes itself from sibling tools like verify_envelope and list_envelopes by being the creation tool and by mentioning usage context (after staging).

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?

The description provides explicit timing guidance ('Use after staging changes and before or after git commit') and mentions side effects. However, it does not explicitly state when not to use this tool or provide alternatives from the sibling list.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SSX360/matrixscroll'

If you have feedback or need assistance with the MCP directory API, please join our Discord server