ASPERN: counterparty checks for agents

Identify the party behind an identifier

identify

Read-onlyIdempotent

Call this FIRST whenever you hold something other than a wallet address. Give it a transaction hash, an http(s) URL, a hostname or an ERC-8004 registration number and it says which party that is, with the evidence for the link, so the other tools here can then be called with the address. It never picks between candidates: where a hostname or id matches several parties, address comes back null and every candidate is listed, because choosing one would be an identification the evidence does not support. A link through a hostname or a declared endpoint is the subject’s own claim, never proof that they control it. An identifier it cannot resolve is not evidence of anything wrong — read says, which distinguishes "no such thing" from "we do not read that chain". Free.

Input Schema

Name	Required	Description	Default
`q`	Yes	What you have: an address (returned as given), a transaction hash (the payee is read from the transfer inside it), a URL or hostname (matched against the x402 catalogue and declared agent endpoints), or an ERC-8004 registration number, optionally as `chain:id`.

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.
`says`	Yes	The answer in words, including the difference between "no such thing" and "we do not read that chain".
`check`	No	The free check to call next with the address.
`given`	No	What you sent, as sent.
`kinds`	No	What each reading would have meant, so an unrecognised identifier is not a dead end.
`format`	No	What kind of address it is and what we read for it.
`address`	No	The party, or null where the evidence names more than one. Never a guess between candidates.
`evidence`	No	Why each link is claimed, and whether it is the subject’s own claim or something we read.
`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.
`looksLike`	No	What the identifier was read as: address, transaction, endpoint, host, agent-id or unrecognised.
`candidates`	No	Every party the identifier could be, where it is not one.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 15, 2026

addedOutput schema / properties / meta

Added value: +{
+  "description": "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.",
+  "type": "object"
+}

addedOutput schema / properties / warnings

Added value: +{
+  "description": "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.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

Changed6 schema fields changedSep 26, 2026

addedOutput schema / properties / check

Added value: +{
+  "description": "The free check to call next with the address.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / format

Added value: +{
+  "description": "What kind of address it is and what we read for it.",
+  "type": "object"
+}

addedOutput schema / properties / given

Added value: +{
+  "description": "What you sent, as sent.",
+  "type": "string"
+}

removedOutput schema / properties / kind

Removed value: -{
-  "description": "What the identifier was read as: address, transaction, url, hostname or registration.",
-  "type": "string"
-}

addedOutput schema / properties / kinds

Added value: +{
+  "description": "What each reading would have meant, so an unrecognised identifier is not a dead end.",
+  "type": "object"
+}

addedOutput schema / properties / looksLike

Added value: +{
+  "description": "What the identifier was read as: address, transaction, endpoint, host, agent-id or unrecognised.",
+  "type": "string"
+}

Changed1 schema field changedSep 26, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "address": {
+      "description": "The party, or null where the evidence names more than one. Never a guess between candidates.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "candidates": {
+      "description": "Every party the identifier could be, where it is not one.",
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "evidence": {
+      "description": "Why each link is claimed, and whether it is the subject’s own claim or something we read.",
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "kind": {
+      "description": "What the identifier was read as: address, transaction, url, hostname or registration.",
+      "type": "string"
+    },
+    "says": {
+      "description": "The answer in words, including the difference between \"no such thing\" and \"we do not read that chain\".",
+      "type": "string"
+    }
+  },
+  "required": [
+    "says"
+  ],
+  "type": "object"
+}

AddedSep 25, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, and the description adds genuinely new behavior: it never disambiguates (address returns null with all candidates), hostname/endpoint links are the subject's own claim and not proof of control, unresolvable identifiers are not evidence of wrongdoing, and `says` distinguishes unknown subjects from unsupported chains. This is rich disclosure far beyond the structured fields.

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?

Front-loaded with the call-first directive, then the identifier types, then the failure semantics. Dense and every sentence carries information, though the run-on sentence about candidates and the self-claim/evidence distinction could be tightened.

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?

An output schema exists, so return shapes need not be re-explained, and the description still covers the non-obvious output behavior (null address, candidate list, `says` field) that an agent needs to interpret results. Nothing material is missing for a single-parameter resolver.

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?

Schema coverage is 100% and the schema's own description of `q` already enumerates the accepted input forms, so the description's restatement of transaction hash / URL / hostname / registration number adds little. Baseline 3 is appropriate when the schema carries the parameter burden.

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 specific verb and resource ('says which party that is') and precisely enumerates the accepted identifier types alongside a wallet address. It positions itself against siblings by declaring it is the entry point whose output feeds 'the other tools here', so an agent knows this is the resolving step, not the analysis step.

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?

'Call this FIRST whenever you hold something other than a wallet address' gives an explicit trigger condition and an implicit exclusion (already holding an address). It does not name a specific competing sibling, but the input-type routing rule largely obviates the need.

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.

Resources

Need Help?