matrixscroll
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MATRIXSCROLL_HOME | No | Override the path for the device.json key store (default: ~/.matrixscroll). | |
| MATRIXSCROLL_MODE | No | Mode of the identity provider: 'emulated' (software key) or 'hardware' (SE050 preview). | emulated |
| MATRIXSCROLL_TOOL | No | Tool name to record in the commit envelope (e.g., 'agent-runner'). | |
| MATRIXSCROLL_ACTOR_TYPE | No | Actor type to record in the commit envelope (e.g., 'agent', 'human'). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_envelopeA | Create a signed Git commit envelope with Ed25519 provenance metadata. |
| verify_envelopeA | Verify one signed commit envelope offline against RFC 8032 Ed25519 rules. |
| verify_pr_rangeA | Scroll Gate: verify signed/unsigned commits across a PR commit range. |
| publish_notesA | Publish local signed envelopes to git notes for CI Scroll Gate verification. |
| statusA | Report hook install state, local envelope count, and Matrix Scroll config. |
| sign_actionA | Sign a universal provenance action envelope with the active Ed25519 identity. |
| audit_exportA | Export a compliance or procurement audit bundle with optional verification proofs. |
| list_envelopesA | List commit envelopes stored on ssx360.com for the authenticated organization. |
| scan_mcp_serverA | Fingerprint an MCP server's tool surface into an unsigned ssx360.mcp-manifest.v1. |
| sign_mcp_manifestA | Ed25519-sign an MCP tool-surface manifest for offline install verification. |
| verify_mcp_manifestA | Verify a signed MCP manifest and optionally diff against an install-time baseline. |
| sign_agent_traceA | Sign a browser-agent JSONL trace with the active Ed25519 identity. |
| verify_agent_traceA | Verify a signed agent trace envelope offline; optional trace byte check. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| provenance_report | Guide an agent to produce a provenance audit report for a Git repository. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| commit_envelope_schema | Public JSON Schema for Matrix Scroll commit envelopes (v1). |
| action_envelope_schema | Public JSON Schema for universal provenance action envelopes (v1). |
| mcp_manifest_schema | Public JSON Schema for MCP tool-surface manifests (ssx360.mcp-manifest.v1, CC0). |
| specification | Matrix Scroll byte contract and verification rules (SPEC.md). |
TDQS
Scored across 13 tools
Each tool targets a distinct artifact type (PR range, commit envelope, action, MCP manifest, agent trace), and the descriptions include helpful cross-references like 'prefer verify_envelope' and 'prefer audit_export.' However, the multiple sign/verify/create tools share similar shapes and require careful reading of the object noun to avoid misselection.
Most tool names follow a clear verb_noun snake_case pattern, with consistent sign_/verify_ pairs across mcp_manifest and agent_trace. The pattern is weakened slightly by 'status' (a bare noun) and 'audit_export' (noun_noun), though these are still readable and do not cause much confusion.
Thirteen tools is within a reasonable range and each tool maps to a distinct workflow step. The count feels slightly heavy because the server covers several domains at once—Git commit provenance, action signing, MCP manifest security, agent trace verification, and hosted audit export—rather than focusing on one narrow purpose.
The core lifecycle is well covered: create/verify/publish for Git envelopes, sign/verify for actions, manifests, and traces, plus status, listing, and audit export. Minor gaps exist around identity/key management and there is no explicit revocation or deletion workflow, but these are not critical for the primary signing and verification use cases.