robinx-mcp
Server Details
Robinhood Chain deployer reputation, insider detection & token buy-risk verdicts. x402-paid.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.6/5 across 6 of 6 tools scored.
Each tool targets a unique aspect: paper tracking (basket), deployer reputation (deployer), new token feed (feed), coverage stats (stats), on-chain token stats (token), and buy-risk verdict (verdict). No overlaps.
All tools use the robinx_ prefix and snake_case, but they follow a noun_noun pattern (e.g., robinx_basket) rather than verb_noun. The pattern is consistent and predictable.
With 6 tools, the server is well-scoped for analyzing Robinhood Chain memecoins. Each tool contributes a distinct value without being excessive or insufficient.
The tool set covers key areas: deployer reputation, token on-chain stats, live feed, verdict logic, and a paper basket. Minor gaps exist (e.g., no historical basket data), but the core workflow is supported.
Available Tools
6 toolsrobinx_basketBInspect
Free live forward paper-basket: every launch from a proven deployer, entered +30min, held. The lookahead-free public track record of the RobinX signal.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. It mentions 'lookahead-free' and 'public track record' but does not disclose update frequency, authentication needs, or whether the basket is mutable or static. Lacks behavioral details beyond content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with key information: live, forward, paper-basket, selection criteria, lookahead-free. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, description should clarify return format. It describes content but not structure (e.g., list, data fields). Adequate for a simple tool but leaves ambiguity about what the agent will receive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0 parameters with 100% coverage (empty). Baseline 3 applies. Description adds meaning by explaining the basket's content (launches, timing, holding), but does not compensate for parameter details since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool provides a 'free live forward paper-basket' tracking launches from a proven deployer, entered after +30min and held. It distinguishes from siblings like robinx_deployer or robinx_feed by focusing on a track record of signals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., robinx_stats or robinx_verdict). The description is self-contained but lacks context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
robinx_deployerBInspect
Deployer reputation rap sheet: tokens launched, real vs dead, best-token volume, insider-distribution flag, 0-100 score. (paid $0.01 — see instructions)
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Deployer wallet 0x… |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does not disclose behavioral traits such as read-only nature, permission requirements, or rate limits. The only behavioral hint is the cost, but it does not clarify if the tool is idempotent or has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys key information (what the tool returns) and includes a cost note. No wasted words; well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description adequately covers purpose and key return fields. Missing details on response format or pagination, but not critical for a basic reputation lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the 'address' parameter as 'Deployer wallet 0x…' (100% coverage). The description confirms this by referring to 'deployer wallet' but adds no new syntactic or semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a 'deployer reputation rap sheet' with specific metrics (tokens launched, real vs dead, volume, insider flag, score). This distinguishes it from sibling tools like robinx_token or robinx_feed, which focus on tokens or feed data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The mention of a $0.01 cost and 'see instructions' provides a minor hint but no contextual comparison with siblings or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
robinx_feedAInspect
Newest Robinhood Chain launches, each scored by deployer reputation. min_score=70 = proven deployers only; since=; limit=N (max 100). Designed to be polled. (paid $0.01 — see instructions)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| since | No | ||
| min_score | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions payment ($0.01) and polling design, but lacks details on security, rate limits, or output format. The description adds value beyond schema but incomplete for a pollable feed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences with front-loaded purpose and parameter hints. Parenthetical on payment is brief. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple feed tool with 3 parameters and no output schema, description covers purpose, parameters, and usage. Lacks example output or error handling, but is functional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds meaning: explains min_score cutoffs, since as cursor, limit max of 100. This compensates well for the bare schema, though format of `since` is unspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists 'newest Robinhood Chain launches' and mentions scoring by deployer reputation. It is distinct from sibling tools like robinx_deployer or robinx_token, though not explicitly contrasted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates polling as intended use ('Designed to be polled') and explains parameter defaults like min_score. However, it does not specify when to use this tool over siblings like robinx_basket or robinx_stats, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
robinx_statsAInspect
Free coverage stats for RobinX: deployers scored, tokens indexed, real tokens, insider wallets flagged, and serial-spam factories on Robinhood Chain (chain 4663).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as return format, rate limits, or side effects. It only lists the topics of stats without explaining behavior beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with purpose, lists specifics concisely. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description adequately covers what the tool returns (list of stats). It is sufficient for an agent to decide to call it for high-level statistics, though output format is unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description does not need to add parameter meaning beyond the empty schema; the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides 'free coverage stats' for RobinX and lists specific metrics (deployers scored, tokens indexed, real tokens, etc.), distinguishing it from sibling tools like robinx_basket or robinx_deployer. It also specifies the blockchain (Robinhood Chain 4663).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs. siblings; usage is implied as a high-level stats overview. No alternatives or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
robinx_tokenAInspect
On-chain stats for a Robinhood Chain token: swaps, WETH volume, unique traders, real-activity flag, deployer score. (paid $0.01 — see instructions)
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Token contract address 0x… |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. It adds value by noting the fee and the return metrics, but does not cover auth needs, rate limits, or any side effects beyond cost.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a parenthetical, front-loading the main purpose and key outputs. No wasted words; every part is meaningful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description adequately lists what is returned (stats) and notes the cost. Output format is not described, but the complexity is low. Slightly improved with explicit return field naming.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear param description ('Token contract address 0x…'). The description adds no additional semantic meaning beyond what the schema already provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns on-chain stats for a Robinhood Chain token, listing specific metrics (swaps, WETH volume, unique traders, real-activity flag, deployer score). This distinguishes it from sibling tools like robinx_basket or robinx_deployer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a fee ($0.01) and references instructions, giving a hint about cost, but does not explicitly state when to use this tool versus alternatives like robinx_stats. No when-not or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
robinx_verdictAInspect
Composite BUY-RISK verdict for a Robinhood Chain memecoin: deployer reputation + insider-distribution flags + on-chain activity → signal (trusted/mixed/avoid/serial_spammer/new_deployer) with reasons. Works on a token that launched seconds ago (scores WHO deployed it). (paid $0.02 — see instructions)
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Token contract address 0x… |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it works on tokens launched seconds ago, costs $0.02, and scores deployer reputation. It is transparent about its capabilities and limitations, though it does not explicitly state if the operation is read-only or destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and output, followed by contextual details. Every sentence adds value without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers input, output (signal types and reasons), and special condition of new tokens. It lacks explicit details on output format or error handling, but given the simplicity, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter described as 'Token contract address 0x…'. The description adds context about the token's applicability to new launches and the verdict, but does not add new semantic meaning beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a composite BUY-RISK verdict for a memecoin, specifying the inputs (deployer reputation, insider-distribution flags, on-chain activity) and output (signal with reasons). It distinguishes itself from sibling tools by being a composite verdict.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for assessing risk of memecoins, especially new ones, but does not explicitly state when to use this tool versus alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!