get_market_statsTotals for the Roblox Limiteds market as RBX Invest tracks it: how many Limiteds are followed, and the copies and Robux held across tracked portfolios. The holdings figures cover RBX Invest users who linked a Roblox account, not all of Roblox.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does meaningful work: it explicitly discloses that holdings figures only cover RBX Invest users who linked a Roblox account, not all of Roblox. It does not describe output format, rate limits, or auth, but introduces no contradictions.
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 with no wasted words. The primary totals are front-loaded, and the important population-scope caveat is cleanly separated in the second sentence.
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 parameterless, low-complexity tool, the description covers what is returned and who is included in the holdings figures. It does not specify exact field names or response structure, but that is a minor gap given no output schema and no parameters.
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 tool has zero parameters, so the baseline is 4. The description appropriately focuses on what the returned totals represent rather than input details, since there is nothing for the agent to configure.
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 states a clear resource ('Roblox Limiteds market as RBX Invest tracks it') and enumerates the specific totals returned: number of Limiteds followed, copies held, and Robux held. This distinguishes it from sibling tools like get_market_cap or per-player holdings tools.
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 use for market-wide aggregate statistics, but it never explicitly contrasts this with siblings such as get_market_cap, get_community_holdings, or get_player_holdings. The caveat about account-linking gives useful context but not explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools map to a distinct resource/action, and descriptions explicitly disambiguate rank_creators from get_creator and player rankings from player holdings. The only notable overlaps are find_deals as a specialized filter of search_items and get_market_cap vs get_market_stats, though the descriptions clarify the differences.
All tools follow a consistent snake_case verb_noun pattern (find_*, get_*, rank_*, search_*). No mixed conventions or vague names like 'process' or 'execute' appear.
12 tools cover a read-only market data domain without bloat. Each tool addresses a distinct query type: search, detail, rankings, aggregates, deals, recent items, and articles.
The surface covers core workflows: search/screen the catalog, drill into items, evaluate creators and players, check market aggregates, find deals, and retrieve guides. Minor gaps like item-level historical price series and filtering a creator's full catalog are not explicitly exposed, but agents can work around them with search_items and get_item_details.