LedgerProof LAIN — Verified Evidence for Agents

request_capability

Buy a capability - LIVE, real money, by default. Provide a capability id (receipt.agent-run: pass action plus at least one of inputs_hash/outputs_hash/state_hash as 64-hex sha256; evidence.verify: pass content or content_hash; answer.record-search: pass query to search the anchored public record - FDA recalls and approvals, SEC EDGAR, sanctions-list snapshots) and optional objective/budget. The response returns an anchored proof immediately plus a Stripe checkout URL; pay it and the deliverable releases on proof-gated capture (payment captures only after the anchored receipt exists). Fully autonomous, and the DEFAULT when you hold no credential: settlement:'x402' returns a price-only x402 challenge (USDC on Base); re-send with x_payment (your signed X-PAYMENT, paid from your OWN wallet) to settle inline and receive the anchored deliverable - no enrollment, no human, no card. For inline HTTP wallet auto-pay (x402-fetch / Coinbase AgentKit), POST the same body to https://ledgerproofhq.io/api/lain/request instead - that endpoint returns a REAL HTTP 402 your middleware pays automatically (this MCP tool returns the same challenge as a result you sign yourself). Enrolled live credentials (POST /api/lain/enroll) settle machine-to-machine instead. Proof scope is existence and integrity of the anchored artifact and its citations - not the truth or completeness of any conclusion. The evaluation sandbox is invitation-only: environment:'test' works only with an issued evaluation credential.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No
`model`	No
`query`	No	answer.record-search: entity, product, or filing name (2-80 chars) - returns a cited answer from the anchored public record (FDA recalls/approvals, SEC EDGAR, sanctions-list snapshots) with hash-anchored citations; proof scope is the existence + integrity of the citations, not the truth of a conclusion
`since`	No	YYYY-MM-DD
`action`	No
`budget`	No
`run_id`	No
`content`	No
`sources`	No
`agent_id`	No
`framework`	No
`objective`	No
`x_payment`	No	settlement:'x402' step 2 — your signed X-PAYMENT (base64 x402 v1 payload). Call once WITHOUT it to get the 402 challenge (price + payTo + asset on Base), then re-send with x_payment set to settle inline from your own wallet.
`capability`	Yes
`settlement`	No	x402 = pay autonomously in USDC on Base from your OWN wallet (no enrollment, no human); checkout = returned Stripe URL; m2m = enrolled/test machine settlement
`started_at`	No
`state_hash`	No
`environment`	No	live (default, real money); 'test' is the invitation-only evaluation sandbox - requires an issued credential	live
`finished_at`	No
`inputs_hash`	No
`content_hash`	No
`outputs_hash`	No
`parent_receipt`	No
`payment_method`	No	test env only: your own Stripe payment_method token
`idempotency_key`	No

Schema Changelog

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

Changed3 schema fields changedAug 2, 2026

addedInput schema / properties / settlement / description

Added value: +"x402 = pay autonomously in USDC on Base from your OWN wallet (no enrollment, no human); checkout = returned Stripe URL; m2m = enrolled/test machine settlement"

changedInput schema / properties / settlement / enum

Previous value: -[
-  "checkout",
-  "m2m"
-]New value: +[
+  "x402",
+  "checkout",
+  "m2m"
+]

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 402 challenge (price + payTo + asset on Base), then re-send with x_payment set to settle inline from your own wallet.",
+  "type": "string"
+}

Changed1 schema field changedAug 2, 2026

changedInput schema / properties / query / description

Previous value: -"answer.record-search: entity, product, or filing name (2-80 chars) - returns a PROVEN answer from the anchored public record (FDA recalls/approvals, SEC EDGAR, sanctions-list snapshots) with hash-anchored citations"New value: +"answer.record-search: entity, product, or filing name (2-80 chars) - returns a cited answer from the anchored public record (FDA recalls/approvals, SEC EDGAR, sanctions-list snapshots) with hash-anchored citations; proof scope is the existence + integrity of the citations, not the truth of a conclusion"

Changed8 schema fields changedJul 24, 2026

changedInput schema / properties / capability / enum

Previous value: -[
-  "receipt.agent-run",
-  "evidence.verify"
-]New value: +[
+  "receipt.agent-run",
+  "evidence.verify",
+  "answer.record-search"
+]

changedInput schema / properties / environment / default
```
Previous value: -"test"New value: +"live"
```

addedInput schema / properties / environment / description

Added value: +"live (default, real money); 'test' is the invitation-only evaluation sandbox - requires an issued credential"

changedInput schema / properties / environment / enum

Previous value: -[
-  "test",
-  "live"
-]New value: +[
+  "live",
+  "test"
+]

addedInput schema / properties / limit

Added value: +{
+  "maximum": 10,
+  "type": "integer"
+}

addedInput schema / properties / query

Added value: +{
+  "description": "answer.record-search: entity, product, or filing name (2-80 chars) - returns a PROVEN answer from the anchored public record (FDA recalls/approvals, SEC EDGAR, sanctions-list snapshots) with hash-anchored citations",
+  "type": "string"
+}

addedInput schema / properties / since

Added value: +{
+  "description": "YYYY-MM-DD",
+  "type": "string"
+}

addedInput schema / properties / sources

Added value: +{
+  "items": {
+    "enum": [
+      "us-sec-edgar",
+      "fda-drug-recalls",
+      "fda-drugsfda",
+      "fda-device-510k",
+      "fda-device-pma",
+      "un-sanctions",
+      "eu-sanctions"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}

First observedJul 22, 2026

TDQS

A3.8/5.0

Behavior5/5

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

With no annotations provided, the description fully carries the transparency burden and does an excellent job. It discloses that the tool spends real money by default, returns a Stripe checkout URL, releases deliverables only after payment captures, and requires a signed X-PAYMENT for inline settlement. It also discloses the proof scope limitation ('not the truth or completeness of any conclusion') and the invitation-only test environment. This covers side effects, payment mechanics, and limitations thoroughly.

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

Conciseness2/5

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

The description is a single, dense wall of text with multiple parentheticals and semicolon-separated clauses. It mixes high-level purpose with low-level protocol details (e.g., 'X-PAYMENT, base64 x402 v1 payload') and alternative endpoint URLs. While every sentence carries some information, the lack of paragraph breaks and logical segmentation makes it hard to scan. It is not appropriately sized for an MCP tool description.

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

Completeness4/5

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

Given the complexity (25 parameters, 3 capability types, 3 settlement modes, no output schema), the description covers most essential aspects: the three capability payload requirements, settlement flows (checkout, x402, m2m), environment restrictions, and proof scope. It does not document return values or error conditions, but no output schema exists, so the description must carry that load. It is reasonably complete for a tool of this complexity, though a structured breakdown would improve it.

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 only 24%, so the description must compensate. It explains the key conditional parameters: for receipt.agent-run it requires 'action plus at least one of inputs_hash/outputs_hash/state_hash as 64-hex sha256'; for evidence.verify it specifies 'content or content_hash'; and for answer.record-search it explains the query parameter and proof scope. It also details settlement and x_payment semantics. However, many optional parameters (limit, model, since, sources, agent_id, etc.) remain unexplained, leaving a gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Buy a capability - LIVE, real money, by default,' which clearly states the action (buy/request) and resource (capability). It further enumerates three specific capability types (receipt.agent-run, evidence.verify, answer.record-search), giving concrete scope. However, it does not explicitly differentiate from sibling tools like discover_capabilities or verify, so it falls short of a 5.

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

Usage Guidelines3/5

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

The description provides strong context on when to use this tool versus alternatives: it states this is the 'DEFAULT when you hold no credential' and mentions that enrolled credentials settle machine-to-machine via POST /api/lain/enroll. It also gives alternative endpoints for HTTP wallet auto-pay. However, it never explicitly says 'use discover_capabilities to see available capabilities' or names any tool as a substitute, so the when-to-use guidance is implicit rather than directly compared.

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?