Skip to main content
Glama
delimit-ai

delimit

Official
by delimit-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Delimit Seal Verify

delimit_seal_verify
Read-onlyIdempotent

Verify a signed governed-output receipt against the Layer-0 constitution: checks content-pin, Ed25519 signature, and structure for tampering.

Instructions

Verify a Delimit Seal receipt against the bundled Layer-0 constitution (Free).

When to use: to check that a signed governed-output receipt has not been tampered with — content-pin to the published constitution, a valid Ed25519 signature, and a well-formed structure. Free tier. Pass mode='a1' to verify a hardened offline A1 bundle (schema_version >= 0.3) with subject binding + key-manifest crosscheck. When NOT to use: to verify an evidence bundle (use delimit_evidence_verify) or to query the ledger (delimit_ledger).

Sibling contrast: delimit_evidence_verify checks an evidence bundle's hash chain; this checks an open-core Seal receipt's signature + content-pin with no access to the engine or the signing key.

Side effects: read-only. Calls backends.repo_bridge.seal_verify. The 'cryptography' dependency is optional + lazy-imported: if absent, it returns verification_unavailable rather than failing. No license gate.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoVerification mode. 'receipt' (default) = legacy/v0.2 receipt path, unchanged. 'a1' = hardened offline A1 bundle path (schema_version >= 0.3): tar-safety, version floor, crypto-suite allowlist, subject binding, key-manifest crosscheck.receipt
expect_repoNoA1 only: the canonical repo URL the relying party expects. When given, sha256(subject_salt || url) must equal subject.repo or verification hard-fails.
receipt_pathYesPath to a Delimit Seal receipt JSON file, OR (mode='a1') an A1 bundle (.a1.tar.gz). Required.
expect_merge_commitNoA1 only: the git merge-commit SHA the relying party expects. When given, verification hard-fails unless subject.merge_commit matches (anti-replay binding, spec §2.2 step 11).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv4.13.2
    • addedInput schema / properties / expect_merge_commit
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "A1 only: the git merge-commit SHA the relying party expects. When given, verification hard-fails unless subject.merge_commit matches (anti-replay binding, spec §2.2 step 11)."
+}
    • addedInput schema / properties / expect_repo
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "A1 only: the canonical repo URL the relying party expects. When given, sha256(subject_salt || url) must equal subject.repo or verification hard-fails."
+}
    • addedInput schema / properties / mode
      Added value: +{
+  "default": "receipt",
+  "description": "Verification mode. 'receipt' (default) = legacy/v0.2 receipt path, unchanged. 'a1' = hardened offline A1 bundle path (schema_version >= 0.3): tar-safety, version floor, crypto-suite allowlist, subject binding, key-manifest crosscheck.",
+  "type": "string"
+}
    • changedInput schema / properties / receipt_path / description
      Previous value: -"Path to a Delimit Seal receipt JSON file. Required."New value: +"Path to a Delimit Seal receipt JSON file, OR (mode='a1') an A1 bundle (.a1.tar.gz). Required."
  2. Addedv4.7.9

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/non-destructive annotations, the description states read-only side effects, calls an internal backend, discloses the lazy-import behavior ('returns verification_unavailable' if cryptography is absent), and notes there is no license gate. 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.

Conciseness4/5

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

The description is well organized and front-loaded with purpose, but it is slightly repetitive: 'Free tier' and 'No license gate' say similar things, and the signature/content-pin checks are described twice. Still, each major section earns its place.

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?

For a tool with schemas and annotations carrying the structured details, the description adds the necessary selection context, side-effect and failure-mode transparency, sibling differentiation, and mode guidance. Nothing critical is missing for correct invocation.

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 100%, so the schema already documents all four parameters thoroughly. The description reinforces mode='a1' context but does not add significant parameter-level meaning beyond what the schema provides; baseline 3 applies.

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 uses a specific verb and resource: verifying a Delimit Seal receipt against the bundled Layer-0 constitution, with concrete checks (content-pin, Ed25519 signature, structure). It distinguishes itself from delimit_evidence_verify by naming what this tool checks versus what the sibling checks.

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?

Explicit 'When to use' and 'When NOT to use' sections name alternatives: delimit_evidence_verify for evidence bundles and delimit_ledger for ledger queries. The mode='a1' path is also scoped with a condition, leaving no ambiguity about when this tool should be selected.

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