ASPERN: counterparty checks for agents

Due-diligence report for agents (paid)

vault_due_diligence

Idempotent

The due-diligence report on one vault, cut to what an agent acts on: overallAssessment (published, conditional or withheld; publishedBand is null when withheld and partialBand is never the verdict), findings above the band, each risk dimension, capital and withdrawal bounds, metricStatus (each input current, indicative, stale, unavailable or not-read, with its times and expiry), completeness, warnings and agentRules. Follow agentRules when you answer: they say what must be quoted and what must not be said. PAID ($5 over x402, or inside a plan with due diligence). The digest names the whole issued document; verify it at /v1/reports/{digest}.

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": {
      "slug": "<slug>"
    },
    "name": "vault_due_diligence"
  }
}

Input Schema

Name	Required	Description	Default
`slug`	Yes	Vault slug or contract address.

Output Schema

Name	Required	Description
`meta`	No	How current this answer is and what it was read from: `freshness` and the ages behind it. Present on every answer from this server, whatever the tool.
`digest`	Yes	SHA-256 of the whole issued document.
`warnings`	No	Anything the server wants a caller to know about THIS answer before acting on it. Empty is the normal case and is not a guarantee.
`agentRules`	Yes	What your answer must and must not say. Follow them.
`dimensions`	No	Each risk dimension with its level and what set it.
`notAssessed`	No	Risk areas this report did not assess, each with status not assessed, not tested or not established. Say them; the score’s input share does not cover them.
`completeness`	No	Coverage by area, missing fields, currentDecisionStatus, nextCurrentInputExpiryAt, snapshot.
`metricStatus`	No	Per input: status, times, expiry, whether the result used it.
`highestFinding`	No	The worst single risk read, level and label. The weighted result never cancels it.
`overallAssessment`	Yes	status, publishedBand, publishedScore, partialBand, partialScore, reasonCode, reason, findingsAboveBand, inputsNotCurrent, judgedAt.
`unattributedCapital`	No	value (null unless measured), unit, status (measured, not_established or unreconciled_residual), differenceUsd, asOf. Never report null as zero.
`changesSincePrevious`	No	Standard figures before and after against the previous report, each changed, below_threshold (moved, under the 1% materiality threshold), unchanged (within a dollar) or not_comparable, with a note that says the move, with both times and models.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 8, 2026

changedOutput schema / properties / changesSincePrevious / description

Previous value: -"Standard figures before and after against the previous report, each changed, unchanged or not_comparable, with both times and models."New value: +"Standard figures before and after against the previous report, each changed, below_threshold (moved, under the 1% materiality threshold), unchanged (within a dollar) or not_comparable, with a note that says the move, with both times and models."

Changed4 schema fields changedNov 8, 2026

addedOutput schema / properties / changesSincePrevious

Added value: +{
+  "description": "Standard figures before and after against the previous report, each changed, unchanged or not_comparable, with both times and models.",
+  "type": "object"
+}

addedOutput schema / properties / highestFinding

Added value: +{
+  "description": "The worst single risk read, level and label. The weighted result never cancels it.",
+  "type": "object"
+}

addedOutput schema / properties / notAssessed

Added value: +{
+  "description": "Risk areas this report did not assess, each with status not assessed, not tested or not established. Say them; the score’s input share does not cover them.",
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / unattributedCapital

Added value: +{
+  "description": "value (null unless measured), unit, status (measured, not_established or unreconciled_residual), differenceUsd, asOf. Never report null as zero.",
+  "type": "object"
+}

Changed1 schema field changedNov 6, 2026

changedOutput schema / required

Previous value: -[]New value: +[
+  "digest",
+  "overallAssessment",
+  "agentRules"
+]

AddedNov 6, 2026

TDQS

A4/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=false, openWorldHint=true, idempotentHint=true and destructiveHint=false; the description adds what they cannot — that the call is paid ($5 via x402 or plan entitlement), that the digest names the whole issued document, and that it can be verified at /v1/reports/{digest}. It also discloses output semantics that matter behaviourally, such as publishedBand being null when withheld and partialBand never being the verdict. That is substantive disclosure well beyond the annotation set.

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 and the agent-facing framing are front-loaded, and the payment and digest facts are short and actionable. The long enumeration of return fields is partly redundant given an output schema exists, and the run-on parentheticals make it denser than necessary. Still, most sentences carry non-obvious information rather than filler.

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 single-parameter tool with a full input schema, an output schema, and annotations, the description supplies the missing pieces an agent needs: cost and payment path, digest verification route, verdict edge cases, and the obligation to obey agentRules. Nothing material about invoking it correctly is absent.

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?

Only one parameter (slug) and the schema already documents it at 100% coverage as 'Vault slug or contract address.' The description adds no further meaning about slug format, resolution rules, or error behaviour for an unknown slug. With the schema fully carrying the parameter, baseline 3 is appropriate.

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?

States a specific resource and scope: 'the due-diligence report on one vault,' then enumerates the payload (overallAssessment, findings, risk dimensions, capital/withdrawal bounds, metricStatus, completeness, warnings, agentRules). An agent can tell this is the full issued report rather than a screening call. It never names a sibling such as vault_assessment or vault_risk_dimensions to sharpen the boundary, so it stops 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?

It gives a strong in-report instruction ('Follow agentRules when you answer') and a payment condition ($5 over x402 or inside a plan), which is real routing context. However, there is no explicit statement of when to pick this over the many neighbouring assessment tools, or when not to call it. Usage is implied by the word 'due-diligence' rather than spelled out.

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

All ASPERN: counterparty checks for agents 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.