aspern

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

TableJSON 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

TableJSON Schema

Name	Required	Description
`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.
`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.

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.7/5.0

Behavior5/5

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

Beyond the readOnly/openWorld/idempotent annotations, the description reveals critical behavior: it never chooses among multiple candidates, returns null for ambiguous matches while listing all candidates, and clarifies that hostname/endpoint links are claims, not proof. This is exactly the kind of context annotations cannot carry.

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

Conciseness5/5

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

The description is dense but every sentence contributes: usage order, accepted inputs, ambiguity behavior, epistemic limits, and error interpretation. It is front-loaded with the most important instruction and has no 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?

Given the output schema exists for return values, the description covers everything needed to call the tool correctly: accepted identifier formats, ambiguous-candidate behavior, what constitutes evidence/non-evidence, and how to read failure via `says`. It is complete for an identifier-resolution tool.

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?

The schema already documents the single `q` parameter at 100% coverage, including the address, transaction hash, URL/hostname, and ERC-8004 forms. The description repeats those forms but does not materially add new parameter-level meaning beyond what the schema states.

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 begins with a specific action—'Call this FIRST'—and states it resolves transaction hashes, URLs, hostnames, and ERC-8004 registrations to a party with evidence. This clearly distinguishes it from sibling tools that operate on wallet addresses.

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 to use this tool first whenever you have something other than a wallet address, and that other tools can then be called with the resulting address. It also warns that an unresolvable identifier is not evidence of wrongdoing, setting expectations for follow-up.

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

All aspern 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?