Check how many years of verifiable history a person has behind accounts they already own.
MCP Server: io.github.ramakrishnanhulk20/patina
This MCP server helps check how many years of verifiable history a person has behind accounts they already own. It is exposed under the slug io-github-ramakrishnanhulk20-patina, with the description focused specifically on verifying the duration of history tied to existing accounts.
π οΈ Key Features
Evaluates βyears of verifiable historyβ for a person
Uses context from accounts the person already owns
π Use Cases
Determining how long a personβs accounts have verifiable history
Supporting checks that rely on prior account history
β οΈ Limitations
The available description does not specify data sources, verification methods, privacy controls, or output format
β‘ Developer Benefits
Provides a focused capability: verify historical tenure behind owned accounts
Captured live from the server via tools/list.
get_patina_score
Look up a person's full Patina score by their Patina username. Patina reads the age and activity of accounts somebody already owns (YouTube, GitHub, Instagram, LinkedIn, Spotify and others) through the Vana data portability protocol, and turns that into a 0-100 score plus a signed attestation. Patina scores 0-100 for how much provable history an account holder has, not for how popular or how real-time-verified they are. 80+ (Deeply worn in) means a long, multi-year record corroborated across independent platforms. 60-79 (Well established) is a solid multi-year record. 40-59 (Some real history) is genuine but shorter or thinner. 20-39 (Thin, but genuine so far) is an early account with a little history. Under 20 (Not much to go on yet) looks freshly created, or has almost nothing connected. Age is the heaviest single input: 12 years of provable history earns full marks on it. Patina proves TENURE: that whoever holds these accounts has a long, corroborated, verifiable history. It does NOT prove uniqueness or liveness, and it is not a proof-of-personhood check. If you need 'exactly one human, present right now', Patina is the wrong signal and you should say so. Call this when you want the whole picture: the score, the per-component breakdown, how many years of history are provable, which platforms corroborate each other, and an attestation you can verify offline. If you only need a yes or no about whether somebody clears a bar, call check_threshold instead. An unknown username comes back with found: false, which is a normal answer meaning no public Patina profile exists under that name. It is not an error, and it is not evidence against the person.
Parameters1
username
string
required
The person's Patina username, as it appears at patinadata.xyz/u/<username>.
Raw schema
{
"type": "object",
"properties": {
"username": {
"type": "string",
"description": "The person's Patina username, as it appears at patinadata.xyz/u/<username>."
}
},
"required": [
"username"
],
"$schema": "https://json-schema.org/draft/2020-12/schema"
}
check_threshold
Decide whether somebody clears a trust bar, as a plain true or false. Give a Patina username plus min_score, min_years, or both. At least one is required. Returns `pass`, plus a one-sentence `reason` written to be quoted straight back to a user. This is the right tool for gating decisions: 'has this person been verifiably around for at least five years', 'is this account above 70'. Patina scores 0-100 for how much provable history an account holder has, not for how popular or how real-time-verified they are. 80+ (Deeply worn in) means a long, multi-year record corroborated across independent platforms. 60-79 (Well established) is a solid multi-year record. 40-59 (Some real history) is genuine but shorter or thinner. 20-39 (Thin, but genuine so far) is an early account with a little history. Under 20 (Not much to go on yet) looks freshly created, or has almost nothing connected. Age is the heaviest single input: 12 years of provable history earns full marks on it. Patina proves TENURE: that whoever holds these accounts has a long, corroborated, verifiable history. It does NOT prove uniqueness or liveness, and it is not a proof-of-personhood check. If you need 'exactly one human, present right now', Patina is the wrong signal and you should say so. When no profile exists, `pass` is false and `found` is false: treat that as UNKNOWN rather than as a failed check, because most people have never heard of Patina and absence proves nothing about them.
Lowest acceptable years of provable history. Passing requires the oldest provable signal to be at least this many years old.
Raw schema
{
"type": "object",
"properties": {
"username": {
"type": "string",
"description": "The person's Patina username."
},
"min_score": {
"description": "Lowest acceptable Patina score, 0-100. Passing requires score >= this.",
"type": "number",
"minimum": 0,
"maximum": 100
},
"min_years": {
"description": "Lowest acceptable years of provable history. Passing requires the oldest provable signal to be at least this many years old.",
"type": "number",
"minimum": 0
}
},
"required": [
"username"
],
"$schema": "https://json-schema.org/draft/2020-12/schema"
}
verify_attestation
Check whether a Patina attestation really was signed by Patina. Every Patina score ships with an EIP-191 signed message; hand this tool that `message` and `signature` and it returns the address it recovered, the address Patina publishes, and whether the two match. IMPORTANT, AND THE WHOLE POINT: you do not need this tool, and where you can, you should not use it. A signature is worth something precisely because ANYONE can check it offline, with no call to Patina, using viem's recoverMessageAddress or ethers' verifyMessage. If you ask Patina's own server whether Patina's own signature is good, you are trusting Patina again and the signature has bought you nothing. That is why this returns the recovered address rather than a bare yes: compare it yourself.
Parameters2
message
string
required
The exact `message` string from the attestation, newlines and all.
signature
string
required
The `signature` from the attestation, 0x-prefixed.
Raw schema
{
"type": "object",
"properties": {
"message": {
"type": "string",
"description": "The exact `message` string from the attestation, newlines and all."
},
"signature": {
"type": "string",
"description": "The `signature` from the attestation, 0x-prefixed."
}
},
"required": [
"message",
"signature"
],
"$schema": "https://json-schema.org/draft/2020-12/schema"
}
resolve_identity
Find out whether the person behind a platform handle has a Patina score, WITHOUT learning who they are. Supported sources: github, instagram, linkedin. Accepts a bare handle, an @handle, or a full profile URL. Returns only three things: whether a public Patina profile is linked to that account, its score, and its years of history. It deliberately never returns the Patina username, and never returns which other platforms that person has connected, because doing so would turn this into a cross-platform de-anonymisation tool. Do not ask it for those; it cannot provide them. Other platforms (youtube, spotify, steam, amazon, uber) are NOT supported here, because for those Patina stores an internal platform id rather than a handle a person could type. Those platforms still count fully toward the score itself; only this lookup is limited. Email addresses are refused outright. Patina scores 0-100 for how much provable history an account holder has, not for how popular or how real-time-verified they are. 80+ (Deeply worn in) means a long, multi-year record corroborated across independent platforms. 60-79 (Well established) is a solid multi-year record. 40-59 (Some real history) is genuine but shorter or thinner. 20-39 (Thin, but genuine so far) is an early account with a little history. Under 20 (Not much to go on yet) looks freshly created, or has almost nothing connected. Age is the heaviest single input: 12 years of provable history earns full marks on it.
Parameters2
source
string
required
Which platform the handle belongs to. Supported for lookup: github, instagram, linkedin. Anything else returns an explanation rather than a result.
handle
string
required
The handle on that platform. 'torvalds', '@torvalds' and 'https://github.com/torvalds' are all accepted.
Raw schema
{
"type": "object",
"properties": {
"source": {
"type": "string",
"description": "Which platform the handle belongs to. Supported for lookup: github, instagram, linkedin. Anything else returns an explanation rather than a result."
},
"handle": {
"type": "string",
"description": "The handle on that platform. 'torvalds', '@torvalds' and 'https://github.com/torvalds' are all accepted."
}
},
"required": [
"source",
"handle"
],
"$schema": "https://json-schema.org/draft/2020-12/schema"
}
Patina reads the history in accounts somebody already owns and turns it into portable, verifiable evidence that a real human has been there for years. It is built on Vana, the data portability protocol: the data lives in the user's own Personal Server, is read once under a grant they can revoke, and never passes through an OAuth handoff that keeps it.
Sybil resistance is unsolved and expensive. An airdrop, a quadratic funding round, a DAO vote or a free trial all need to know whether they are talking to a thousand people or to one person with a thousand wallets. The usual answers are poor: biometrics are invasive, KYC destroys privacy, and most behavioural signals can simply be bought.
Somebody running an account farm can buy followers, bulk-upload posts and fill in a convincing profile. What they cannot buy is a decade.
Why Patina?
KYC
World ID / proof of personhood
Patina
Proves years of history
No
No
Yes
Proves you are one unique person
Partly
Yes
No
Works without a wallet
Yes
No
Yes
Works without biometrics
Yes
No
Yes
User can revoke access afterwards
No
No
Yes
Another app can reuse the proof
No
Yes
Yes
Patina answers tenure, not uniqueness. A freshly verified unique human can be produced today; sixteen years of corroborated activity cannot. The two are complementary, and the tool descriptions say so rather than implying otherwise.
Features
Ownership proved, not assumed
Collection is meant to run through Vana Desktop, which opens a browser on the user's own machine and asks them to sign in. Credentials never leave the device and Patina never sees a password.
But Vana has two collection paths and does not report which one it used. The other reads a public page from a profile URL, which proves an account exists and nothing about who holds it. So "desktop only" cannot be asked for; it has to be forced.
Every source therefore requires one scope a public page cannot serve, and the read is refused if it does not come back. LinkedIn must produce connection dates, Spotify saved tracks, YouTube its Watch Later list. A request containing something private cannot be answered from a public profile, so the person ends up on Desktop and has to log in. sources.test.ts fails if a source is ever added without one.
Steam was withdrawn for the same reason. Its connector never signs anybody in: it takes a Steam Web API key and a Steam ID, and a Steam ID is public. Anyone could have handed Patina a stranger's account age and friend dates as their own, and unlike YouTube there was no private scope to require instead.
Nine sources, nineteen scopes
GitHub, LinkedIn, Spotify, Instagram, YouTube, Amazon, Uber, DoorDash and Shop. All of a source's scopes go in one approval, so the whole manifest is nine approval trips rather than nineteen.
Timestamps in, content out
Every scope is requested for its dates. Captions, addresses, emails, track names, game titles and other people's names are discarded before anything is stored, and a test fails if any of them reach the store.
Signed, portable, and dated
Every non-provisional score carries an EIP-191 attestation anyone can verify offline against Patina's published address. No key, no OAuth, CORS open.
Attestations expire after thirty days, and the expiry sits inside the signed message rather than beside it, so checking freshness stays offline too. A revocation list would have fixed the same problem by making every verifier call Patina, which is exactly the dependency people integrate to avoid. Scores are signed with a key separate from the one holding the escrow balance, so a leak of one is not a leak of both.
Answerable about itself
/api/health does a real write-and-read against the database and a live read of the escrow balance, and returns 503 when the deployment cannot serve the next person, so ordinary uptime monitoring catches an outage without being taught what to look for. A password-gated /admin shows the funnel, the user numbers and how many more connections the balance will fund. Funnel counting is done server-side: no third-party script, no cookie banner, nothing that contradicts the privacy page.
Readable by agents
An MCP server exposes the score to AI agents mid-conversation, with a handle resolver that returns tenure without revealing identity.
The Score
Six components, weighted by how expensive each one is in time rather than in money.
Component
Max
What it measures
Age
30
The oldest date provable across every connected source. Full marks at twelve years.
Continuity
25
Distinct months the person was actually present for, as absolute count times coverage.
Corroboration
15
Independent sources agreeing on the date, each weighted by its own age.
Vouches
12
When other people chose to connect, not how many. Weighted by how long ago.
Depth
10
Things actually made, discounted when the volume arrived in one burst.
Breadth
8
Independent accounts backing each other up.
Age and the two time components are earned outright. Depth, Vouches and Breadth are gated behind them: an attacker can manufacture volume, friends and breadth in an afternoon, so those only count to the extent that real elapsed history backs them up. A floor of 15% stops a genuinely young person being flattened to zero for the crime of being nineteen.
Scored against reference profiles, asserted in score.test.ts:
Profile
Score
Eleven active years across four accounts
95
Ordinary: eleven years, two accounts, real gaps
71
Genuinely young: three years, two accounts, real
26
Account farm: 3,900 bought followers, 120 posts in one week
2
The gap between an ordinary person and a farm is 69 points. That gap is the product.
Honest limits
Stated on the site itself, not buried here:
It cannot prove personhood. It reports how much real history it can see. That is evidence, not a certificate.
A low score is not an accusation. Young, private or quiet accounts score low and are doing nothing wrong.
Aged accounts can be bought. That turns a free attack into an expensive one whose price climbs with age. It does not make it impossible.
Desktop proves session control, not ownership. A bought account arrives with its password. The bar moves from "knows a username" to "holds the credentials", which is a large jump and not the same word.
The proof scope is a floor, not a guarantee. Requiring something private forces a real sign-in, and a real sign-in is still only a sign-in. What it rules out is somebody scoring a stranger's public profile, which is the failure that would make the whole number meaningless.
What is read, and what is kept
Every scope below is requested for its timestamps. This table is the trust argument, so it is on the privacy page in roughly this form too.
Scope
Kept
Discarded on arrival
linkedin.connections
dateConnected[], count
names, headlines, profile URLs
instagram.posts
taken_at[], count
captions, images, likes, the entire who_liked[] array
spotify.savedTracks
added_at[], total
track names, artists, albums
github.history
createdAt[], hashed repo, summed engagement
PR and issue titles and bodies
linkedin.experience / education
parsed date ranges
companies, job titles, schools, grades
uber.trips
requestTime[], count
pickup and dropoff addresses, fares, cities
amazon / doordash / shop orders
dates, count
items, merchants, totals, delivery addresses
youtube.profile
joinedDate, counts
email address
youtube.watchLater
nothing at all
everything; it is requested only as proof of a signed-in session
Timestamps collapse to month buckets before storage. The scorer only ever asks about months, so holding anything finer would be holding it for no reason.
Architecture
Connect flow
graph LR
U[User] -->|1 Connect| P[Patina]
P -->|2 createAccessRequest<br/>all scopes for one source| V[Vana Account API]
V -->|3 approval URL| U
U -->|4 Open in Vana Desktop| D[Vana Desktop]
D -->|5 Playwright signs in<br/>on the user's machine| S[Source]
S -->|6 import| PS[Personal Server]
P -->|7 read every scope<br/>one grant| PS
P -->|8 settle 402| E[Escrow Gateway]
P -->|9 normalise, discard, score| R[(Redis)]
Read and settle
sequenceDiagram
participant App as Patina
participant PS as Personal Server
participant GW as Escrow Gateway
App->>PS: GET /v1/data/{scope}
PS-->>App: 402 with accessRecord
App->>GW: authorizeGrantPayment(accessRecord)
GW-->>App: receipt
App->>PS: GET /v1/data/{scope}
PS-->>App: 200 payload
Note over App: repeat per scope, same grant
App->>PS: acknowledgeRead (once, at the end)
acknowledgeRead moves the request to completed, which is terminal and not read-ready. Firing it after the first scope would strand the rest behind a Personal Server no longer serving them, after the user had paid.
Scoring pipeline
graph LR
RAW[Raw payload] -->|readScope| F[Fragment<br/>months + counts]
F -->|stored by scope| DB[(Redis)]
DB -->|evidenceFrom| EV[Evidence]
EV -->|scorePatina| SC[Score]
EV -->|buildStory| ST[Story]
SC -->|buildAttestation| AT[Signed attestation]
Fragments are keyed by scope and merged at scoring time. A retried read overwrites its fragment rather than adding its months a second time, so a stuttering connection cannot inflate a score.
Upstash Redis credentials (optional locally; falls back to an in-memory store)
Installation
bash
git clone https://github.com/ramakrishnanhulk20/Patina.git
cd Patina
npm install
cp .env.example .env.local
Fill in VANA_APP_PRIVATE_KEY and VANA_APP_URL, then register the app and fund its escrow:
bash
npm run register:moksha
Development
bash
npm run dev # development server
npm test# 118 tests
npm run typecheck # types, ignoring generated route types
npm run verify # typecheck + tests + production build
The ownership invariant: no source may be answerable from a public page
ratelimit.test.ts
4
Escrow abuse limits
altcha.test.ts
2
Proof-of-work bot check
The one worth knowing about: nothing sensitive survives normalisation feeds in a payload stuffed with a real-looking email address, two home addresses, a caption, a colleague's full name and LinkedIn URL, a game title, an employer, a song, a product and a restaurant, then asserts that none of the thirteen appear anywhere in what gets saved.
Project Structure
code
src/
βββ app/
β βββ api/
β β βββ vana/ request + data: the connect spine
β β βββ patina/ me, username, data, restore, delete
β β βββ admin/ session, index rebuild
β β βββ verify/ public score lookup
β β βββ badge/ embeddable SVG badge
β β βββ mcp/ MCP server
β βββ connect/ the evidence board, and the phone handoff
β βββ my-data/ see it, download it, remove any of it
β βββ admin/ the funnel, the numbers, the money left
β βββ u/[username]/ public page and story
β βββ verify/ verifier, including an offline checker
β βββ docs/ integration reference
βββ lib/
βββ score.ts the whole argument, weight by weight
βββ normalize.ts 18 scopes in, timestamps out
βββ sources.ts the manifest, and the proof scope each source must return
βββ device.ts whether this device can finish a connection at all
βββ vana.ts app identity, one controller per source
βββ vana-settle-read.ts paid reads, escrow settlement
βββ escrow-balance.ts how many more connections the balance will fund
βββ metrics.ts the funnel, counted server-side and nowhere else
βββ store.ts profiles keyed on Personal Server identity
βββ admin.ts one operator, one password, fails closed
βββ story.ts evidence as a narrative, and exhibits
βββ attest.ts signed attestations, expiring, on their own key
βββ mcp-lookup.ts what an agent is allowed to learn
src/lib/score.ts is the whole argument. Every weight carries a comment explaining why it is what it is.
Tech Stack
Layer
Choice
Framework
Next.js 16, React 19, App Router
Language
TypeScript
Styling
Tailwind CSS 4, custom token layer
Data
Vana Data Portability Protocol (@opendatalabs/vana-sdk)