deployer-reputation-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| deployer_reputationA | Score funding-association groups in supplied Solana launch records with explainable 0-1 heuristic components and label-coverage evidence. Use after your pipeline resolves deployer, pre-launch funder and mint; choose cluster_launches for membership only. Not for wallet/token lookup, prediction, ownership attribution or safety decisions; scores are not probabilities and low does not mean safe. Supply 1-1000 distinct-mint edges. Keep connected groups together: splitting batches changes results. A funder_is_cex flag anywhere prevents that funder joining distinct deployers; it does not separate the same deployer's launches. lamports and block_time are validated but do not affect scores; cadence measures launch count, not time. Stateless local computation: no network/RPC, label verification, storage writes, credentials or external side effects. Each full stdio request line is limited to 512000 bytes. Returns score-sorted clusters, membership, components, evidence, counts and versions. Check labelCoverage and notes: rug-rate evidence is null without labels, not zero. Invalid input rejects the whole batch with isError=true; correct it and retry. |
| cluster_launchesA | Group supplied launches by transitive non-exchange funding associations. Use when you need membership and launch counts only; choose deployer_reputation for heuristic scores and label evidence. Requires 1-1000 distinct-mint edges with caller-resolved deployer, pre-launch funder and mint; token-only rows are insufficient. A funder_is_cex flag anywhere prevents that funder joining distinct deployers, while same-deployer launches remain grouped. outcome, lamports and block_time are validated but do not affect grouping. Stateless local computation, no network/RPC, label verification, credentials, storage writes or external side effects. Returns cluster IDs, sorted member identifiers, launch counts, group count and ID version; no scores or safety/ownership claims. Keep connected groups in one batch; separate calls are never joined. Full stdio request lines are limited to 512000 bytes. Invalid input rejects the whole batch with isError=true; correct it and retry. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools are closely related but clearly differentiated by purpose: cluster_launches provides membership and counts, while deployer_reputation produces heuristic scores and evidence. The descriptions explicitly tell the agent which tool to use based on whether scores are needed, minimizing misselection risk.
Both names are compound nouns with underscore separation, following a similar pattern. 'cluster_launches' could be misread as an imperative verb, but 'deployer_reputation' is clearly a noun, and the overall naming style is consistent and legible.
With only two tools, the server sits on the thin side of the acceptable range. However, both tools serve distinct and necessary steps in the same workflow, so each earns its place, even though the count feels minimal.
The server covers the two core operations of the domain: grouping launches into clusters and scoring those clusters with evidence. Minor gaps exist—such as no tool for single-deployer lookup or label verification—but the descriptions explicitly scope those responsibilities to the caller's upstream pipeline.