Cryptographically anchored evidence for agents: verified run receipts, proof-gated settlement.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.2/5 across 9 of 9 tools scored. Lowest: 3.5/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.
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.
With 9 tools, the server is well-scoped, covering discovery, funding, execution, and verification without redundancy or bloat.
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.
discover_capabilitiesAInspectList everything the LedgerProof Autonomous Network (LAIN) offers: capability ids (receipt.agent-run, evidence.verify, answer.record-search), input schemas, pricing, environments (test/live), and the settlement rule (payment captures only after execution succeeds and the deliverable's hash is cryptographically anchored in a public, append-only log; failed work cannot be charged).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It goes beyond a simple list by explaining the settlement rule: payment is captured only after successful execution and cryptographic anchoring, and failed work cannot be charged. This is valuable context about the tool's behavior, though it does not explicitly state that the tool itself is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence with a colon leading into a list of items. Every component adds value, but it could be broken into smaller sentences for improved readability. It is sufficiently front-loaded with the verb 'List' and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, this description is the sole source of context. It thoroughly covers what the tool returns (capability ids, schemas, pricing, environments) and includes the crucial settlement rule, making it comprehensive for an agent to understand the tool's purpose and expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the schema is trivially covered. The description adds no parameter details because there are none; the baseline for 0 parameters is 4, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'everything the LedgerProof Autonomous Network (LAIN) offers', enumerating specific items such as capability ids, input schemas, pricing, and environments. It distinguishes this tool from siblings like discover_opportunities by focusing on capabilities rather than opportunities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: to learn about LAIN's offerings, one should use this tool. However, there is no explicit statement of when to use it versus alternatives like discover_opportunities, nor any exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discover_opportunitiesAInspectFREE: machine-generated demand. LAIN continuously scans the anchored public record (FDA drug recalls, CPSC product recalls, and CVE/NVD revisions) for events that could invalidate warranted confidence in a subject, and mints each as an open Opportunity - an unresolved decision nobody has funded yet. Returns ranked opportunities with value estimates, confidence-gap estimates, and suggested prices (which fall when prior anchored evidence for that subject can be reused). If an opportunity's subject matters to your operator (a supplier, a product in inventory, a dependency), fund it with fund_opportunity. The customer is the confidence gap, not the agent.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | default 10 | |
| status | No | default open; resolved = anchored house resolutions; funded = agent-funded missions | |
| subject | No | filter to one subject |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the free nature, the sources scanned, the output contents (ranked opportunities with estimates), and the pricing behavior (prices fall when prior evidence can be reused). It doesn't mention side effects, but this is inherently a read-only discovery tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but well-structured: it opens with a striking 'FREE: machine-generated demand,' then explains the source, the output, and a usage scenario. Each sentence adds value, though it could be tightened slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no required parameters and no output schema. The description explains what it returns (ranked opportunities with value estimates, confidence-gap estimates, suggested prices), the source of opportunities, and a concrete use case, making it complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 100% of parameters with descriptions. The description adds meaning by explaining that 'subject' refers to an entity of interest (supplier, product, dependency) and that prices vary based on prior evidence for that subject, which enriches the subject parameter's semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool discovers opportunities from public record events (FDA recalls, CPSC recalls, CVE/NVD revisions) and returns ranked opportunities with value estimates, confidence-gap estimates, and suggested prices. It also distinguishes itself from the sibling fund_opportunity by explicitly pointing to that tool for funding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (to find machine-generated demand/opportunities) and gives an explicit follow-up action: fund with fund_opportunity if the subject matters. However, it does not explicitly mention when NOT to use it or contrast with discover_capabilities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fund_opportunityAInspectFund a discovered Opportunity into a real, authority-backed, proof-gated economic event. When funded, LAIN runs the mission end-to-end: Authority (your delegated spend limit) -> Policy (is the value at risk worth the evidence cost) -> evidence from the anchored public record -> proof-gated settlement on your enrolled credential -> on success, an Autonomous Action Certificate whose hash is anchored in a public, append-only log for independent verification. Requires an enrolled credential (your Authority Receipt). Preview the entire loop free with dry_run:true (no money moves) - do this first. Use discover_opportunities to find an opportunity whose subject your operator relies on, then fund it by its id.
| Name | Required | Description | Default |
|---|---|---|---|
| dry_run | No | true = free preview of the whole loop, no charge | |
| risk_value | No | dollars at stake if the decision is wrong - drives the policy SHOULD-gate | |
| budget_cents | No | max you will spend (defaults to your per-transaction authority) | |
| opportunity_id | Yes | the Opportunity id from discover_opportunities, e.g. opp_us-cpsc:10351 | |
| current_confidence | No | 0..1, your confidence now (default derived from the opportunity's gap) | |
| required_confidence | No | 0..1, your policy threshold (default 0.99) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the multi-step process, prerequisites (enrolled credential), the nature of the economic event, and the dry-run preview. It does not explicitly state irreversibility or failure modes, but the high-level side effects are well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but structured, front-loaded with the primary verb, and each sentence contributes a distinct piece of information (process, prerequisite, preview, workflow). It is perhaps longer than minimal, but all content is relevant and no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description still indicates the output (Autonomous Action Certificate with anchored hash). It covers prerequisites, safety preview, and the discovery→fund workflow, making it comprehensive for a tool with 6 parameters and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 value by explaining the role of dry_run ('no money moves', 'do this first'), the meaning of risk_value ('drives the policy SHOULD-gate'), and the reference to opportunity_id ('by its id'). This goes beyond the schema's field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fund a discovered Opportunity') with a specific resource and purpose ('real, authority-backed, proof-gated economic event'). It distinguishes itself from siblings by explicitly contrasting with discover_opportunities and outlining the end-to-end flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit workflow guidance: 'Use discover_opportunities to find... then fund it by its id' and 'Preview the entire loop free with dry_run:true - do this first.' It lacks explicit when-not-to-use statements, but the contextual workflow is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_jobAInspectPoll a job by id. For paid checkout jobs this is also the settlement trigger: once the buyer has paid, polling captures the charge strictly against the anchored proof and returns the deliverable.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It reveals that for paid checkout jobs, polling acts as a settlement trigger that captures the charge and returns the deliverable. This is a significant behavioral trait beyond basic polling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence clearly states the core action, and the second provides critical context without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and one parameter, the description covers the basic purpose and a key behavioral aspect. However, it does not explain return value format, error conditions, or behavior for non-paid-checkout jobs, leaving some gaps for a poll tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0% and the description only says 'by id' for the single parameter job_id. It does not explain the format, constraints, or usage of job_id beyond being an identifier. The description adds minimal value over the schema for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'poll' and resource 'job by id'. It also provides a specific use case (settlement trigger for paid checkout jobs), distinguishing it from sibling tools like fund_opportunity and request_capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context for when the tool is used (e.g., for paid checkout jobs it triggers settlement), but it does not explicitly state when not to use it or suggest alternatives. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_sample_receiptAInspectFREE (one per caller per day): mint a REAL receipt for your current task's output, cryptographically anchored in a public, append-only log - pass content_hash (sha256 of your output) or task_summary (short text, hashed for you). Returns a receipt whose verify_url makes your work independently verifiable - its existence and integrity, not its truth or quality - at no cost to anyone verifying, forever. No payment, no account. If your task involves compliance, due diligence, records, or actions your operator must later defend, this is the difference between a claim and evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| content_hash | No | sha256 hex of your output/state | |
| task_summary | No | or a short text description; it will be hashed for you |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does excellently: explains cost (FREE), rate limit (one per caller per day), immutability (append-only log), verifiability scope (existence/integrity not truth/quality), and no account/payment required. This is rich, accurate context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense and well-structured. It front-loads the most crucial facts (free, daily limit), then gives inputs, output, and use-case guidance in a logical flow. Every sentence earns its place, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set and lack of output schema, the description is complete: it covers what the tool does, how to invoke it, what it returns (verify_url), and when to use it. It also mentions important behavioral caveats (verifies existence not truth), making it sufficient for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds explicit 'or' semantics between content_hash and task_summary, clarifying they are alternative inputs. It also frames them within the task-output context, which supplements the schema descriptions without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'mint[s] a REAL receipt' for the current task's output, cryptographically anchored in a public, append-only log. This specific verb+resource (mint receipt) distinguishes it from all sibling tools, which deal with capabilities, opportunities, and jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit context on when to use: 'If your task involves compliance, due diligence, records, or actions your operator must later defend, this is the difference between a claim and evidence.' It also notes the free tier and rate limit. It does not explicitly name alternatives or exclusions, but that's acceptable given the unique purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_capabilityAInspectBuy 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.
| 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 |
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.
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.
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.
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.
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.
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.
resolve_confidenceAInspectTHE 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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
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.
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.
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.
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.
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.
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.
subject_evidence_graphAInspectRead a subject's evidence graph (free): how many times it has been verified through LAIN, when it was last checked, and rolling findings. The graph is built one paid resolution at a time, so it may be empty for a subject nobody has checked yet.
| Name | Required | Description | Default |
|---|---|---|---|
| subject | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses that the operation is read-only ('Read'), free, and that the graph may be empty because it is built incrementally via paid resolutions. This adds meaningful context about the tool's behavior and limitations, though it doesn't cover error states or authentication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first clearly states the action and data returned, the second adds a relevant caveat about empty graphs. It is concise, well-structured, and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the description lacks critical parameter semantics and the absence of an output schema means the agent cannot infer the return format beyond the listed data points. The note about empty graphs helps but is insufficient for confident invocation without knowing what 'subject' should be.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines one required string parameter 'subject' with no description, and the description does not explain what constitutes a valid subject (e.g., ID, name, or format). With 0% schema description coverage and no param info in the description, the agent has no guidance on how to populate this parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a subject's evidence graph and specifies the exact data it returns (verification count, last checked, rolling findings). It also distinguishes it as a free read operation, which contrasts with sibling tools that involve funding or requesting capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need a subject's verification status, and mentions 'free' and the possibility of an empty graph for unchecked subjects. However, it does not explicitly say when to use this tool over alternatives like resolve_confidence or discover_capabilities, and offers no exclusions or comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verifyAInspectFREE, no auth, no account: independently verify ANY LedgerProof/LAIN receipt. Pass content_hash (the sha256 that any receipt carries) or seq. Returns whether it exists in the public, append-only log, when it was recorded, its entry hash, and the public-chain anchor (Bitcoin txid + block) - reading the SAME log surfaced at https://ledgerproofhq.io/record/network. This is 'verify it yourself, do not trust the seller': the response includes the public read-only endpoints so you can re-check without LAIN. A non-existent or altered hash returns found:false. Proof scope: existence + integrity only, never truth or quality.
| Name | Required | Description | Default |
|---|---|---|---|
| seq | No | or the receipt's sequence number | |
| content_hash | No | sha256 hex from a receipt (64 hex chars) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and excels: it discloses the public append-only log source, return behavior for non-existent/altered hashes (found:false), and explicitly limits scope to existence/integrity, not truth. It also notes the response includes read-only endpoints for independent re-checking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The opening sentence is front-loaded and punchy: 'FREE, no auth, no account: independently verify ANY LedgerProof/LAIN receipt.' Although the description is lengthy, every sentence contributes essential information about inputs, outputs, data source, or scope, making it dense but not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema or annotations, the description thoroughly covers purpose, input parameters, output semantics, limitations, and the verification philosophy. It is complete enough for an agent to correctly select and invoke this tool without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying the two parameters are alternatives ('Pass content_hash ... or seq') and that content_hash is the sha256 hex from a receipt, supplementing the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool verifies LedgerProof/LAIN receipts, with specific inputs (content_hash or seq) and outputs (existence, record time, entry hash, anchor). It is distinct from siblings by its verification focus, which none of the other tools explicitly address.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly frames when to use it ('verify it yourself, do not trust the seller') and notes it is free and requires no auth. However, it does not explicitly name alternatives or define when-not-to-use, so it falls short of a 5 but provides solid contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
