Skip to main content
Glama
Sign In

robinx-mcp

by io.github.jamhimself
OverviewDiscussionsAdmin

Caller call log

robinx_caller_calls
Read-only

The receipts behind the free Caller Report Card: the most recent 100 Robinhood Chain calls by one X handle, each with its post id and URL, capture time, attribution basis, pool, the three prices its grade is made of (at the call, 30 min before, 1 h after), the pre-run and one-hour move, the grade (early / momentum / neither) or why there is none (pending, ungradeable, artifact, unmarked, not_admitted, repeat = a later post on the same token inside the 24 hours after the first, counted as no call, spam_account = an account whose spam-tagged posts are half or more of its tagged posts and admitted calls, so none of its calls is counted), plus token outcome (real or dead, current FDV); true total and truncation flag. Calls preserved as captured — deleting the post does not scrub the record. Costs $0.02 USDC on Base. (paid $0.02, or included in a RobinX plan key — see instructions)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "handle": "<handle>"
    },
    "name": "robinx_caller_calls"
  }
}

Input Schema

NameRequiredDescriptionDefault
handleYesX handle, with or without @

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior5/5

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

Beyond the supplied readOnly/openWorld annotations, the description discloses several behaviors an agent could not otherwise know: a $0.02 USDC on Base charge with plan-key alternatives, that records are immutable snapshots ('deleting the post does not scrub the record'), and that results are capped at 100 with a true-total and truncation flag. This is exactly the kind of cost, retention, and truncation context annotations do not carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and cost are front-loaded well, but the middle collapses into a single run-on parenthesis enumerating six no-grade reasons plus two long inline definitions (repeat, spam_account), which is hard to scan. The content is valuable but the structure works against quick parsing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/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 carries the return-shape burden and does so thoroughly: field list, grade taxonomy, token outcome, totals, truncation, persistence, and payment. The main remaining gap is failure behavior for an invalid or unknown handle, and it never states whether pagination beyond the 100-cap exists.

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?

There is a single required parameter with 100% schema description coverage, so the schema already documents the handle and its optional @ prefix. The description only restates 'by one X handle' and adds no syntax, casing, or validation detail beyond that, which is the baseline for fully covered schemas.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete resource and scope: 'the most recent 100 Robinhood Chain calls by one X handle,' and enumerates the returned fields, so an agent knows exactly what it gets. The framing 'the receipts behind the free Caller Report Card' implicitly separates it from the sibling report-card tool without naming it, which keeps this just short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied through the 'receipts behind the free Caller Report Card' framing, which suggests this is the evidence layer under a graded score. There is no explicit when-to-use, when-not-to-use, or named alternative such as robinx_caller or robinx_callers, so the agent must infer routing from context.

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

All robinx-mcp 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