LedgerProof LAIN — Verified Evidence for Agents

resolve_confidence

THE CORE LOOP: an autonomous system should not advance to a higher-confidence state without independently verifiable evidence - so buy it. Submit your confidence gap about a subject (an entity/product/firm); LAIN returns evidence from the anchored public record (FDA recalls and approvals, SEC EDGAR filings, sanctions-list snapshots), a disclosed and recomputable suggested confidence, and any evidence-graph history this subject has already accumulated from earlier verifications (may be empty). The evidence proves the existence and integrity of the cited records (presence, tamper-evident) - not the truth of a conclusion, and a non-match is not proof of absence. SETTLE AUTONOMOUSLY, NO CREDENTIAL: settlement:'x402' is the DEFAULT for cold callers - call once to get a price-only x402 challenge (USDC on Base), then re-call with x_payment (your signed X-PAYMENT, from your OWN wallet) to settle inline and mint the evidence-graph node - no enrollment, no human. Or preview free with dry_run:true (evidence + quote, no charge). Enrolled credentials (POST https://ledgerproofhq.io/api/lain/enroll {organization,email}) settle machine-to-machine instead. Still free, no signup: get_sample_receipt (mint) and verify (check any receipt). Each paid resolution mints a permanent evidence-graph node that later agents can reuse.

Input Schema

TableJSON Schema

Name	Required	Description
`need`	No	what you are trying to establish, e.g. 'counterparty has no sanctions or recalls'
`dry_run`	No	true = free preview: evidence + quote, no charge
`sources`	No
`subject`	Yes	entity, product, or firm name (2-120 chars)
`x_payment`	No	settlement:'x402' step 2 — your signed X-PAYMENT (base64 x402 v1 payload). Call once WITHOUT it to get the price-only 402 challenge (price + payTo + asset on Base), then re-send with x_payment to settle inline from your own wallet.
`settlement`	No	x402 = settle autonomously in USDC on Base from your OWN wallet (no credential) - the DEFAULT for cold callers; m2m = enrolled machine-to-machine
`budget_cents`	No	max you will spend
`current_confidence`	No	0..1, your confidence now
`required_confidence`	No	0..1, your policy threshold

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed2 schema fields changedAug 3, 2026

addedInput schema / properties / settlement

Added value: +{
+  "description": "x402 = settle autonomously in USDC on Base from your OWN wallet (no credential) - the DEFAULT for cold callers; m2m = enrolled machine-to-machine",
+  "enum": [
+    "x402",
+    "m2m"
+  ],
+  "type": "string"
+}

addedInput schema / properties / x_payment

Added value: +{
+  "description": "settlement:'x402' step 2 — your signed X-PAYMENT (base64 x402 v1 payload). Call once WITHOUT it to get the price-only 402 challenge (price + payTo + asset on Base), then re-send with x_payment to settle inline from your own wallet.",
+  "type": "string"
+}

AddedJul 24, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and discloses essential behaviors: it's a paid operation, returns evidence of record existence/integrity but not truth, non-matches are not proof of absence, and each paid resolution mints a permanent evidence-graph node. It also states settlement details and the free dry_run preview, making side effects and limitations transparent.

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

Conciseness3/5

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

The description is quite long and uses marketing-style phrasing ('so buy it', 'SETTLE AUTONOMOUSLY, NO CREDENTIAL'), but every major point is relevant. It is front-loaded with the core loop and flows logically, yet could be tightened to reduce verbosity while preserving essential details.

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 the tool's complexity (9 params, payment workflow, no output schema), the description is remarkably complete. It covers the full workflow, return values (evidence, suggested confidence, graph history), limitations, payment options, free preview, and references sibling tools. There is no missing context that an agent would need to invoke the tool correctly.

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 high (>80%), so baseline is 3, but the description adds meaningful context beyond schema: it explains the x402 two-step flow for x_payment, clarifies settlement enum (x402 default for cold callers vs m2m), and positions sources as 'anchored public record'. It also adds the core loop rationale for current_confidence and required_confidence, enhancing parameter understanding.

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 that resolve_confidence submits a confidence gap about a subject and returns evidence from the public record, a suggested confidence, and evidence-graph history. It distinguishes itself from sibling tools by mentioning get_sample_receipt and verify as free alternatives for minting/checking receipts, and implies subject_evidence_graph is separate since the tool includes history but is primarily for resolution.

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?

It explicitly says the tool should be used when an autonomous system needs to advance to a higher-confidence state with verifiable evidence. It provides clear usage flow for x402 settlement (call once for a price challenge, then re-call with x_payment), and mentions dry_run for free preview and get_sample_receipt/verify as free alternatives, giving both when-to-use and alternatives.

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

All LedgerProof LAIN — Verified Evidence for Agents tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0

Disambiguation5/5

Each tool targets a distinct operation—discovery, funding, job polling, receipt minting, capability purchase, confidence resolution, graph reading, and verification. No two tools overlap in purpose, and the detailed descriptions make selection unambiguous.

Naming Consistency4/5

Most tools follow a verb_noun pattern (discover_*, fund_opportunity, get_job, get_sample_receipt, request_capability, resolve_confidence), but subject_evidence_graph is a noun phrase and verify is a bare verb, creating minor inconsistency.

Tool Count5/5

With 9 tools, the server is well-scoped, covering discovery, funding, execution, and verification without redundancy or bloat.

Completeness5/5

The tool surface covers the full evidence lifecycle: discover opportunities, fund them, poll jobs, mint receipts, request capabilities, resolve confidence gaps, read evidence graphs, and verify receipts. No obvious operational gaps.

Resources

Need Help?