Skip to main content
Glama

Leibniz Layer Crypto Commit

dcl_commit

Commit a final decision to the hash-chained audit ledger, returning a Merkle-proof receipt with chain depth for tamper-evident review.

Instructions

FINAL-STEP Leibniz Layer Crypto Commit ($0.01). Writes a trading/agent decision to the append-only Leibniz Layer audit chain and returns a Merkle-proof-style receipt: tx_hash (proof of this specific commit), chain_hash (the previous commit's hash, linking this one into the chain), and chain_depth (this commit's position in the chain). Unlike the evaluate_* tools, this call has no pass/fail verdict of its own — it always succeeds and simply seals the decision. Passing prior_checks is optional but recommended: it records which earlier pipeline steps (firewall/wallet/trade/MEV) this specific commit is downstream of, in one auditable record. Always run this LAST, after every other crypto-suite check has passed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
agent_idYesIdentifier of the agent whose decision is being committed.
decisionYesThe final trading/agent decision text to commit to the audit chain.
payment_idNoOptional payment identifier returned by a previous call when payment is required
prior_checksNoOptional dict of tx_hashes from earlier pipeline steps (e.g. {'prompt_firewall_tx_hash': ..., 'trade_verifier_tx_hash': ..., 'mev_compliance_tx_hash': ...}), linking this commit to the specific checks that passed before it.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
tx_hashYesTamper-evident proof of this specific commit.
timestampYesUnix timestamp when this record was sealed.
chain_hashYesHash of the previous commit in the append-only chain that this one links to.
input_hashYesHash of the committed decision text (raw content is never stored).
chain_depthYesThis commit's position (index) in the chain.
Behavior5/5

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

Beyond annotations, the description discloses that the tool 'always succeeds', is append-only, costs $0.01, and returns a specific receipt format. It also explains the chain-linking behavior, which is not covered by annotations. No contradiction with 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?

While fairly long, every sentence adds value: purpose, return fields, comparison to evaluate_*, prior_checks explanation, and usage ordering. It is front-loaded with 'FINAL-STEP' and efficiently structured 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?

The description covers purpose, return values, parameter semantics, and usage, making it complete for a commit tool. Output schema exists, so it doesn't need to explain returns, but it does anyway, and it addresses the tool's role in the pipeline. No significant gaps.

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%, so baseline is 3. The description adds extra meaning to prior_checks by explaining it records downstream pipeline steps with examples, which goes beyond the schema. It doesn't add much for agent_id/decision, but the extra prior_checks detail justifies a 4.

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 starts with 'FINAL-STEP' and clearly states the tool 'Writes a trading/agent decision to the append-only Leibniz Layer audit chain' and returns a Merkle-proof-style receipt. It explicitly differentiates from evaluate_* tools by noting it has no pass/fail verdict, distinguishing it from siblings.

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

Usage Guidelines5/5

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

Explicitly says 'Always run this LAST, after every other crypto-suite check has passed', providing clear when-to-use guidance. Also contrasts with evaluate_* tools, and recommends passing prior_checks, giving a clear usage pattern.

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/Fronesis-Labs/dcl-webhook'

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