# Scienter (remote · scienter.xyz)

Crypto forensics with sources: deployer records, OFAC matches, exchange and bridge attribution.

- Trust score: 75/100 (medium)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-10-17

## Components

- remote · `scienter.xyz`: 75/100 (this document), [markdown](https://verifymcp.io/servers/xyz-scienter-scienter/scienter.md), [page](https://verifymcp.io/servers/xyz-scienter-scienter/scienter)

## Channel facts

- Endpoint: `https://scienter.xyz/mcp`
- Transports: `streamable-http`
- Auth: `required (not validated)`
- Version: `1.0.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-10-17.

- **Endpoint Security**: 89/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation is enforced on tool calls, but the challenge carries no valid RFC 9728 metadata, so a client cannot discover where to get a token.
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 61/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 2496 tokens (~312/item across 8 items; 8 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 13/100
  - Stability observed for 4 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 8 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 9 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 60/100
  - Spec-recency check failed: implements MCP spec 2025-06-18; the latest is 2026-07-28.

## Install

### How do I install the Scienter MCP server?

Scienter is a hosted endpoint at https://scienter.xyz/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add --transport http xyz-scienter-scienter 'https://scienter.xyz/mcp'
```

### Cursor

```json
{
  "mcpServers": {
    "xyz-scienter-scienter": {
      "url": "https://scienter.xyz/mcp"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "xyz-scienter-scienter": {
      "type": "http",
      "url": "https://scienter.xyz/mcp"
    }
  }
}
```

### Codex

```toml
[mcp_servers.xyz-scienter-scienter]
url = "https://scienter.xyz/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "xyz-scienter-scienter": {
      "type": "remote",
      "url": "https://scienter.xyz/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add xyz-scienter-scienter --url 'https://scienter.xyz/mcp' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  xyz-scienter-scienter:
    url: "https://scienter.xyz/mcp"
```

### Netclaw

```json
{
  "McpServers": {
    "xyz-scienter-scienter": {
      "Transport": "http",
      "Url": "https://scienter.xyz/mcp"
    }
  }
}
```

### Vellum

```bash
assistant mcp add xyz-scienter-scienter -t streamable-http -u 'https://scienter.xyz/mcp'
```

### Other

```json
{
  "mcpServers": {
    "xyz-scienter-scienter": {
      "type": "http",
      "url": "https://scienter.xyz/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-10-17 (score 75, +1)

No change was recorded against any check on this day. Stability & Change Management went from 10 to 13. That category is still filling its 30-day observation window: 3 days of observed history at the previous scan, 4 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-15 (score 74, +1)

No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-14 (score 73, 0)

- [functional improvement] Stability: unverified → 0.03

### 2026-10-13 (score 73)

First indexed and scored.

## MCP tools (8)

### `solana_token` (~447 tokens)

Who created a Solana token, and what that wallet's OTHER launches did. Takes a mint — the identifier a user actually has — and resolves the wallet that created it, which requires a census that watched Solana launches prospectively since 2026-09-08.

EVERY NUMBER IT RETURNS COUNTS LAUNCHES BY THAT WALLET, NOT EVENTS IN THIS TOKEN. Never write that the token had launches or has a death rate; the true statement is about its maker, and it is a reason to look harder at the token rather than a measurement of it.

Three outcomes, and they must not be collapsed:
  \- flagged: every settled launch by the creating wallet has died.
  \- not flagged: that wallet has a settled record and at least one launch survived. This is NOT a positive finding; it means the screen does not fire.
  \- no record: either the mint is not one the census publishes evidence for, or its wallet has no settled launch on record. This is the answer for most of the chain and it is NOT a clean result — it is a statement about coverage. Never report it as clear.

What the flag is worth, scored once on a later window: flagged launches were still listed a day later about 0.8% of the time against about 4.3% for the rest, non-overlapping 95% intervals.

It is a NEGATIVE screen. It does not identify anything worth buying, and over this same data every return bucket loses money after costs. Never restate it as a recommendation, a risk score, or a safety verdict.

Case is significant: a mis-cased mint is a different mint and will answer no record.

Call this when a user asks about a specific Solana token, who made it, or whether its creator has a history. Use solana_deployer instead when a deployer wallet is already known.

Args:
  \- mint (string): a base58 Solana mint address, exact case.

Input parameters:

- `mint` (string, required): A base58 Solana mint (token) address, exact case. Lowercasing it makes it a different mint and the answer will be no record.

### `solana_deployer` (~391 tokens)

What the wallet that deployed a Solana token has done before: how many of its launches settled, how many died, and whether every one of them did. Built from a census that has watched Solana launches prospectively since 2026-09-08, which is why it can answer a question about the deployer rather than about the token.

Three outcomes, and they must not be collapsed:
  \- flagged: every settled launch by this wallet has died.
  \- not flagged: a settled record exists and at least one launch survived. This is NOT a positive finding; it means the screen does not fire.
  \- no record: no settled launch by this wallet was ever recorded. This is the answer for most of the chain and it is NOT a clean record — it is a statement about coverage, never about conduct. Never report it as clear.

What the flag is worth, scored once on a later window: flagged launches were still listed a day later about 0.8% of the time against about 4.3% for the rest, non-overlapping 95% intervals.

It is a NEGATIVE screen. It does not identify anything worth buying, and over this same data every return bucket loses money after costs. Never restate it as a recommendation, a risk score, or a safety verdict.

Case is significant: Solana addresses are base58, and a mis-cased address is a different address that will answer no record.

Call this when a user asks who made a Solana token, whether a deployer has a history, or whether a launch's creator has ever had one survive.

Args:
  \- address (string): a base58 Solana wallet address, exact case.

Input parameters:

- `address` (string, required): A base58 Solana wallet address, exact case. Lowercasing it makes it a different address and the answer will be no record.

### `wallet_score` (~177 tokens)

Scienter's forensic read on one blockchain address: public block-explorer facts (age, activity, balance, bounded-window flows), the published exchange-wallet label when the address is one, the clustering engine's entity when it answers, and itemised findings with citations.

This does NOT return a risk score. Scienter publishes no calibrated wallet-risk model and this tool will never emit a number to grade an address by. It returns evidence, and it reports explicitly when a check did not run -- an empty findings list with findings_checked=false means the engine did not answer and must not be read as a clean result.

Args:
  \- address (string): an EVM 0x address or a base58 Solana address.

Input parameters:

- `address` (string, required): An EVM 0x address or a base58 Solana address. Case is preserved.

### `ofac_check` (~415 tokens)

Screen one blockchain address against the U.S. Treasury OFAC SDN (Specially Designated Nationals) list: a direct match on the address itself, plus the engine's two-hop proximity walk over the address's real transfer history. Two separate claims, reported separately.

Three direct-match outcomes, and they must not be collapsed:
  \- a match: the address is published on the SDN list. The designated entity, its type, its sanctions programs and the chain OFAC filed it under are returned.
  \- no match: the whole published list was searched and the address is not on it. That is a real finding about one list on one date.
  \- not screened: the list could not be read, so nothing was checked. Never report this as clear; point the user at https://sanctionssearch.ofac.treas.gov/ instead.

Proximity: when proximity_checked is true the engine walked up to two hops of transfer history (its warehouse or a live read) looking for a listed address, and reports found or not, the hop count, the path and how far it went. Being N hops from a listed address is a fact about the graph, never a designation. When proximity_checked is false nothing was walked and the result says so.

Limits to repeat whenever the result is restated: SDN list only (not the EU, UN or UK/OFSI lists, and not OFAC's non-SDN lists such as SSI, NS-MBS and CAPTA); as published on a stated date; a walk bounded by hops and a node budget. A miss is not a sanctions clearance.

Call this when a user asks about sanctions exposure, designation, or OFAC status for an address, so the answer is grounded in what was actually searched.

Args:
  \- address (string): an EVM 0x address or a base58 Solana address.

Input parameters:

- `address` (string, required): An EVM 0x address or a base58 Solana address. Case is preserved.

### `cex_attribution` (~244 tokens)

Look up whether an address is a labelled centralised-exchange wallet in Scienter's published exchange-wallet table, whether any address clustered with it is, and what the address's own exchange activity looks like: its deposits to labelled exchange wallets and any per-user deposit addresses inferred from its behaviour, read from real transfer history (activity.checked says whether that read ran).

The table is small (tens of addresses, from public block-explorer labels, activity-checked on chain) and a miss means no label is held -- not that the address is unaffiliated with an exchange.

Critical limit on what a hit means: an exchange hot or cold wallet is paid by millions of unrelated people. Two addresses that both funded the same exchange wallet are two customers of that exchange and nothing more. Each row carries a clusterable flag saying whether it can be used to link addresses at all; this must be repeated whenever the result is restated.

Args:
  \- address (string): an EVM 0x address or a base58 Solana address.

Input parameters:

- `address` (string, required): An EVM 0x address or a base58 Solana address. Case is preserved.

### `bridge_trace` (~251 tokens)

Trace an address's cross-chain bridge transfers: which transfers touched which bridge contracts, toward which chains, for how much, with the transaction hash of each.

Scienter matches the address's transfer history (its own warehouse first, a live provider inside a budget after that) against a registry of bridge contracts across seven protocols. The registry is partial by construction, so an empty result means none of the tracked contracts were touched -- never that the funds did not bridge. The coverage and the caveat come back in the same payload and must be repeated whenever the result is restated.

Three outcomes: transfers found (listed with amounts and hashes); none of the registry's contracts touched (a bounded negative); not traced (the engine did not answer, and nothing may be inferred). `truncated: true` means the provider's row cap was hit and every count is a lower bound. EVM addresses only; a Solana address is out of scope, which is a different fact from clear.

Args:
  \- address (string): an EVM 0x address (a base58 Solana address answers out of scope).

Input parameters:

- `address` (string, required): An EVM 0x address. Case is preserved.

### `leaderboard_query` (~218 tokens)

List the addresses Scienter's risk model has flagged most recently, highest score first, with each row's chain, score, model version, top evidence and timestamps.

Every row is a model output about a token contract's on-chain behaviour -- not a legal finding, not an audit, and not an allegation against any person. Widely held tokens are excluded by an allowlist and the suppressed count is reported, so this is a filtered view of the model's output.

An empty list is reported as one of three things and they must not be conflated: a quiet day (the scorer ran and nothing crossed the threshold; a finding), a flag table no scorer has ever written (a gap in coverage; ever_written is false), or an unconfirmed read. A producer that did not answer at all is a fourth, reported as not_deployed.

Args:
  \- limit (integer, optional): maximum rows to return, 1-100 (default 20).

Input parameters:

- `limit` (integer): Maximum rows to return, 1-100.

### `receipts_lookup` (~220 tokens)

Search Scienter's published forensic receipts -- written reconstructions of specific on-chain incidents -- by address or free text, and get back titles, dates, subjects and public URLs a human can open.

There are only tens of receipts in total, each written for one investigation, so most addresses have none. No match is the normal case and is NOT evidence that nothing happened to or around the address. Unverified drafts are withheld from results and counted separately.

Args:
  \- address (string, optional): match receipts whose subject or deployer contains this.
  \- q (string, optional): free-text match over title, description and tags.
  \- limit (integer, optional): maximum receipts to return, 1-50 (default 20).
Passing neither address nor q lists the most recent published receipts.

Input parameters:

- `address` (string): Match receipts whose subject or deployer address contains this string.
- `limit` (integer): Maximum receipts to return, 1-50.
- `q` (string): Free-text match over receipt title, description and tags.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/xyz-scienter-scienter/scienter#diagnostics

## Score history

- 2026-10-17: 75
- 2026-10-16: 74
- 2026-10-15: 74
- 2026-10-14: 73
- 2026-10-13: 73

## Common questions

### What is the Scienter MCP server?

Scienter is an MCP server listed in the public MCP registry as xyz.scienter/scienter. Crypto forensics with sources: deployer records, OFAC matches, exchange and bridge attribution. This page covers its hosted endpoint (https://scienter.xyz/mcp).

### Is the Scienter MCP server safe to use?

Scienter scores 75 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Scienter MCP server expose?

Scienter exposes 8 tools: solana_token, solana_deployer, wallet_score, ofac_check, cex_attribution, and 3 more. Their descriptions and schemas cost roughly 2,363 tokens of context every time the server is loaded.

### Does the Scienter MCP server require authentication?

Yes. Scienter asked us for credentials when we connected, so you will need to authorise it in your MCP client before it can do anything.

### Is the Scienter MCP server still maintained?

Scienter is still listed as active in the MCP registry. We last reached this channel on 17 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

## Links

- Remote endpoint: https://scienter.xyz/mcp
- Authorisation metadata: https://scienter.xyz/.well-known/oauth-protected-resource/mcp
- Website: https://scienter.xyz/mcp
- Changelog RSS feed: https://verifymcp.io/servers/xyz-scienter-scienter/scienter.xml
- Changelog JSON feed: https://verifymcp.io/servers/xyz-scienter-scienter/scienter.json
- HTML version of this page: https://verifymcp.io/servers/xyz-scienter-scienter/scienter