OMENZ agent tools

evidence_bundle

Machine Evidence Bundle: package receipts, ledger heads, attestation tokens, claims and sources into one signed, hash-listed bundle (merkle-style root) that any agent can verify offline. For disputes, audits, refunds and handoffs. By OMENZ. (MCP calls run in AYNE, the free playzone; production: POST https://www.omenz.org/api/tollbooth/v1/evidence/bundle, $0.002 via x402.)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "items": "<items>"
    },
    "name": "evidence_bundle"
  }
}

Input Schema

Name	Required	Description	Default
`items`	Yes
`label`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 14, 2026

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations present, the description shoulders the behavioral burden and does so well: it discloses that output is signed and merkle-rooted, that verification is offline, that this is a paid production endpoint ($0.002 via x402), and that the current MCP surface runs in a free playzone. It omits failure behavior for malformed items and whether bundles are persisted or retrievable later.

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?

Purpose is front-loaded in the first clause, followed by use cases and then operational metadata. The vendor string and the playzone-versus-production/pricing parenthetical are somewhat promotional and lengthy, but they carry real routing and cost information rather than pure filler.

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

Completeness3/5

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

For a two-parameter packaging tool with no output schema and no annotations, the description covers purpose, use cases, output nature and cost. It stops short of stating what the returned bundle reference looks like (ID, URL, raw JSON) and leaves the required 'items' payload contract vague, which an agent needs before calling correctly.

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

Parameters2/5

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

Schema description coverage is 0% for both parameters. The description hints at what belongs in 'items' (receipts, ledger heads, attestation tokens, claims, sources) but not the element shape, required identifiers, or ordering implications. The 'label' parameter is never mentioned anywhere, leaving one of two params entirely unexplained.

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?

States a concrete verb and resource: packages receipts, ledger heads, attestation tokens, claims and sources into a signed, hash-listed bundle with a merkle-style root. An agent can immediately tell this is a sealing/attestation tool rather than a read or lookup, so it is distinguishable from generic evidence lookups.

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?

Gives explicit use contexts: disputes, audits, refunds and handoffs, which is clear guidance about when the tool applies. However, it never names an alternative or exclusion (e.g., when to use claim_evidence or handoff_pack instead), so the agent must still infer the boundary.

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

All OMENZ agent tools tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?