Skip to main content
Glama

Patina

by io.github.ramakrishnanhulk20
OverviewDiscussionsAdmin

Resolve a platform handle to a Patina score

resolve_identity
Read-onlyIdempotent

Find out whether the person behind a platform handle has a Patina score, WITHOUT learning who they are. Supported sources: github, 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, 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. Instagram lookups are paused, because Patina cannot yet prove an Instagram account belongs to the person who connected it. 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. The inputs, heaviest first: Age (30, full marks at 12 years), Continuity (25, how many separate months the person was actually present for), Corroboration (15, independent sources agreeing on the date), Vouches (12, WHEN other people connected to them rather than how many), Depth (10, things made) and Breadth (8, independent accounts). Follower counts are deliberately worth almost nothing, because they are purchasable.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
handleYesThe handle on that platform. 'torvalds', '@torvalds' and 'https://github.com/torvalds' are all accepted.
sourceYesWhich platform the handle belongs to. Supported for lookup: github, linkedin. Anything else returns an explanation rather than a result.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / source / description
      Previous value: -"Which platform the handle belongs to. Supported for lookup: github, instagram, linkedin. Anything else returns an explanation rather than a result."New value: +"Which platform the handle belongs to. Supported for lookup: github, linkedin. Anything else returns an explanation rather than a result."
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses critical behavioral limits: it returns only three values, never reveals the Patina username, never exposes connected platforms, and refuses unsupported inputs. This is exactly the kind of context annotations alone cannot convey.

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?

The description is long but well structured: core behavior, privacy constraints, exclusions, then score meaning. It is front-loaded and dense, though the score-band and weighting details go beyond what is strictly required to invoke the tool correctly.

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?

With no output schema, the description fully specifies the return surface, accepted input formats, unsupported sources, privacy boundaries, and score semantics. An agent has all the information needed to decide whether and how to call this tool correctly.

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 already documents accepted handle formats and supported sources. The description adds useful interpretation context around scores and exclusions, but most of that is behavioral rather than parameter-specific, so the fully covered schema carries the load.

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 uses a specific verb and resource: 'Find out whether the person behind a platform handle has a Patina score' and immediately adds the privacy qualifier 'WITHOUT learning who they are.' It also separates itself from sibling tools by naming supported sources and what it deliberately never returns.

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?

The description gives explicit when-to-use context (github, linkedin) and clear when-not-to-use exclusions (youtube, spotify, amazon, uber, Instagram, email) with reasons. It does not name sibling alternatives such as get_patina_score or check_threshold, so it stops short of the top routing bar.

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

All Patina toolsInspect
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