Read-only Roblox Limiteds market data: RAP, resale prices, deals below RAP, creators, portfolios.
Search RBX Invest's published guides. They cover the market — how Roblox taxes resales, how RAP is calculated, valuing and flipping Limiteds, converting Robux to USD, histories of individual item series — and the site itself, in the "site" section: linking a Roblox account and what that grants, inventory syncing, privacy, what each page does. Returns titles, summaries and links — read the article itself for the detail. One search returning nothing is a vocabulary miss more often than a gap; try the words the site would use before concluding it is not there.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | Topic to search for, e.g. "devex", "how RAP works". Omit for the most recent articles. | |
| category | No | Restrict to one section of /articles, the same six a visitor can browse. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the return format (titles, summaries, links), warns that detail lives in the actual article, and exposes a non-obvious behavioral trait: a single empty result is usually a vocabulary mismatch, not an absence of content. This is exactly the kind of context an agent needs beyond the schema.
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 dense but every clause earns its place: scope, topical coverage, category guidance, return format, and a search heuristic. It front-loads the resource and purpose, so an agent quickly understands what the tool does before reading the detail.
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?
Despite having no output schema, the description adequately explains what the tool returns and how to interpret failures. The main parameters are covered, return behavior is clear, and the tool's scope is thoroughly bounded. Nothing critical is missing for an agent to select and invoke it correctly.
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 documents query and category with descriptions and limit with constraints, covering 67% of parameters. The description adds that omitting query returns recent articles and that category values correspond to browseable site sections, which is helpful. However, it does not elaborate on the limit parameter, and the coverage gap is only partially compensated.
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 opens with a specific verb and resource ('Search RBX Invest's published guides') and then enumerates the exact topical coverage. This clearly distinguishes it from siblings like search_items or find_deals, which target item/deal data rather than written guides.
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 provides clear context for when to use the tool — when the user wants educational or explanatory content about Roblox economics, item histories, or the site itself. It also gives practical guidance on interpreting empty results ('try the words the site would use'). It does not explicitly name alternative tools or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Roblox Limiteds whose lowest resale listing is currently below their RAP, with the discount and the absolute saving. This is the live resale market, refreshed continuously. Use it for what is underpriced right now.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | deal = biggest discount, savings = biggest absolute saving, recent = newest; rap and price rank by those. | deal |
| type | No | ugc_limited or regular_limited (classic). | ugc_limited |
| limit | No | ||
| min_rap | No | Ignore items whose RAP is below this. | |
| max_price | No | Highest resale price to consider, in Robux. | |
| min_price | No | Lowest resale price to consider, in Robux. | |
| min_discount_pct | No | Only items at least this far below RAP. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, and it does disclose a meaningful behavioral trait: results reflect the live resale market and are refreshed continuously. This goes well beyond the schema and helps an agent understand that data is current and time-sensitive. It does not discuss read-only safety or rate limits, but for a plain query tool the key behavior is covered.
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?
Three short sentences with no filler: the first defines the tool's purpose precisely, the second adds the live/refresh behavior, and the third states when to use it. The most important information is 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?
For a 7-parameter tool with no output schema, the description provides the core output semantics (discount and absolute saving), the real-time nature of the data, and a clear use case. The remaining parameters are already well covered in the schema. It could have included a concrete output example, but nothing critical is missing for an agent to call it correctly.
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 description coverage is 86%, so the structured schema already documents most parameters and the baseline is 3. The description adds little parameter-level semantic detail, though 'discount and absolute saving' indirectly clarifies the meaning of some sort options. It does not compensate further, but given the high schema coverage, 3 is appropriate.
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 identifies the resource (Roblox Limiteds), the selection condition (lowest resale listing below RAP), and the key result fields (discount and absolute saving). The 'live' and 'currently' wording further differentiates it from siblings like get_new_limiteds or search_items, even though it does not name them explicitly.
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 final sentence, 'Use it for what is underpriced right now,' provides an explicit intended use case, and the 'live resale market, refreshed continuously' framing tells an agent this is the right tool for current price anomalies. It does not name alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The Limiteds and creators most held across the portfolios RBX Invest tracks. A different signal from price or sales volume: RAP says what a thing trades at, this says what people chose to keep. Ranked by total copies held or by how many different people hold it — one item can be 33 copies in a single collection and another one copy each across 400 people.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | items = individual Limiteds, creators = whose work is held. | items |
| sort | No | total_copies = most copies held, unique_owners = held by the most different people. | total_copies |
| limit | No | ||
| query | No | Part of an item or creator name. | |
| offset | No | ||
| direction | No | desc |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden, and it delivers useful semantic detail: it explains the two ranking dimensions and illustrates the difference between total copies and unique owners with a concrete example. It does not cover operational behavior like response shape or defaults, but the key aggregation behavior is transparent.
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?
Three purposeful sentences: the first states the scope, the second positions the tool against price/sales signals, and the third clarifies ranking semantics with a memorable example. There is no filler or repetition of schema details.
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 explains the core concept well enough to choose and call the tool, but it omits what the response contains structurally and does not mention filtering or pagination behavior. Since there is no output schema and no annotations, the absence of a clearer result contract leaves an agent with some uncertainty.
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 description adds meaning to the kind and sort parameters by explaining what 'items'/'creators' and 'total_copies'/'unique_owners' represent, and the example maps directly to the sort enum. However, schema coverage is only 50%, and limit, offset, and direction receive no added context beyond their bare schema definitions, so the compensation is incomplete.
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 names the exact resource—Limiteds and creators held across the portfolios RBX Invest tracks—and defines a clear scope. It also distinguishes this tool from price or sales-volume signals, which separates it from sibling tools like get_market_stats or get_item_details without being tautological.
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 gives a clear usage context: use this when you care about what people chose to keep rather than what a thing trades at. It does not explicitly name alternative tools or state when not to use it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A Roblox UGC creator: how often their releases have ended up profitable, how long that typically took, and their biggest items. Creators with too few releases come back unrated rather than scored — treat that as unknown, not as bad.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Creator name. Omit if giving creator_id. | |
| creator_id | No | Numeric creator id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure, and it does disclose an important edge case: creators with too few releases come back unrated rather than scored, and that should be treated as unknown, not negative. It also communicates the output theme, though it does not detail error behavior or return structure.
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 tight sentences that front-load the core value and then add the critical unrated caveat. Every sentence contributes meaningful information without redundancy.
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 read-only lookup with two optional parameters and no output schema, the description covers the main output categories and the key edge case. It is slightly incomplete in not addressing what happens when both parameters are omitted or conflicting, but overall it gives an agent enough to invoke the tool sensibly.
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 description coverage is 100%, so the schema already documents the name and creator_id parameters. The description adds no additional parameter-level meaning, such as precedence or mutual exclusivity, so the baseline of 3 is appropriate.
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 identifies the resource (a Roblox UGC creator) and the kind of data returned: profitability frequency, time to profitability, and biggest items. It is distinct enough from siblings by being a per-creator lookup, though it does not explicitly differentiate itself from rank_creators or other comparison 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?
There is no guidance on when to use this tool versus alternatives like rank_creators or get_item_details. The description implies it is for individual creator track records, but it never states the selection criteria or when a different sibling would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything tracked about one Roblox Limited: a plain-language summary paragraph, RAP and how it has moved over a window, the resale book (how many copies are listed and at what prices, not just the cheapest), stock left, sales in the last 30 days, whether the creator is still selling new copies, the creator, the item score with its predicted profit per day, and a summary of its price trend. Needs a numeric Roblox asset id — get one from search_items first. Read creator_still_selling rather than copies_remaining to answer "can I buy one at the original price": stock left does not mean it is on sale.
| Name | Required | Description | Default |
|---|---|---|---|
| asset_id | Yes | Numeric Roblox asset id, e.g. "1365767". | |
| trend_days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It goes well beyond a generic 'get details' by warning that stock left does not mean the item is on sale, and by clarifying the resale book includes all listed prices, not just the cheapest. This meaningfully reduces misuse.
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 paragraph is long but every clause earns its place: the field list, the prerequisite, and the interpretation warning. It is dense but not padded. It could be broken into cleaner sentences, but there is no wasted information.
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 no output schema and no annotations, the description does a strong job of telling the agent what will be returned and includes a useful caveat. The main gap is that trend_days is never mentioned, so the agent cannot tell that the RAP window and 30-day sales figure are configurable.
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 only 50%, so the description must compensate. It reinforces asset_id semantics by requiring a numeric id and sourcing it from search_items, but it never explains trend_days. The phrase 'over a window' is ambiguous because it does not connect to the trend_days parameter or its default of 30.
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 opens with 'Everything tracked about one Roblox Limited' and enumerates the exact data fields returned, making the resource and scope unmistakable. It also differentiates itself from search_items by explicitly saying to get the asset id from that tool first.
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 prerequisite workflow is explicit: 'Needs a numeric Roblox asset id — get one from search_items first.' It also provides a field-interpretation rule for answering 'can I buy one at the original price' using creator_still_selling. However, it does not name alternative sibling tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How big the Roblox Limited market is over any date range, split between Classic and UGC Limiteds: market cap, items, copies in circulation, and the marketplace sales volume and Robux spent on the latest measured day, plus a sampled daily series carrying all of them. Market cap is the RAP of each item times the copies of it that exist. Use it for how big the market is, whether it is growing, how marketplace sales compare, and how the two halves differ. Item-for-item trades are excluded.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Length of the range in days; 9999 for the whole series, which reaches 2021 on two items and 2022-11-24 for the rest. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses key behavioral details: the daily series is 'sampled,' sales volume and Robux are for 'the latest measured day,' the market cap formula is given, and 'Item-for-item trades are excluded.' This is a solid disclosure of what the tool does and excludes, though it does not cover auth, rate limits, or output format.
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?
Three sentences deliver a complete picture: what is returned, how the core metric is computed, and when to use it. There is no filler or repetition; every clause earns its place, and the most important scope ('over any date range, split between Classic and UGC') is 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?
For a single-parameter tool with no output schema, the description covers the returned fields, the sampling behavior, the formula, and an explicit exclusion. The only minor gap is not describing the exact structure or granularity of the returned series, but the listed metrics and 'sampled daily series' give an agent enough to reason about the output.
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 description coverage is 100% for the single 'days' parameter, with a detailed enum explanation including 9999 semantics. The description adds no additional meaning beyond the schema's own documentation, so the baseline score of 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 opens with a specific verb and resource: 'How big the Roblox Limited market is over any date range, split between Classic and UGC Limiteds.' It enumerates the exact metrics returned (market cap, items, copies, sales volume, Robux) and defines market cap as 'RAP of each item times the copies of it that exist.' This clearly distinguishes it from broad siblings like get_market_stats by focusing on the Classic vs UGC split and time-series aspect.
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?
Provides explicit use cases: 'Use it for how big the market is, whether it is growing, how marketplace sales compare, and how the two halves differ.' This tells an agent when to call this tool, though it does not explicitly mention alternatives or when not to use it, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Totals 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 parameters | |||
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.
UGC Limiteds released recently, with demand level, stock left and the predicted profit numbers RBX Invest scores them with.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | newest | |
| limit | No | ||
| query | No | Part of an item name, to search within recent releases. | |
| hide_free | No | Drop items the creator released at 0 R$. | |
| availability | No | all | |
| max_age_days | No | ||
| resellable_only | No | Only items whose resale window has opened. | |
| all_experiences_only | No | Only items sold in any experience — the ones a buyer can list in their own game and keep the 40% affiliate commission on. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does disclose that the output contains demand, remaining stock, and predicted profit figures, which is useful. However, it does not mention filtering behavior, default recency windows, pagination, or whether results can be customized via the provided parameters.
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 one concise, front-loaded sentence. It names the resource first and then adds the most decision-relevant data qualities without unnecessary detail.
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?
This tool has 8 parameters, no output schema, and no annotations, which makes the description the primary source of context. The current description explains the general output but omits available filters, sort options, defaults, and recency limits, so it is not complete enough for correct invocation in varied scenarios.
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 description coverage is only 50%, and the description adds no meaning to any parameter. It mentions output fields but does not help an agent understand sort, limit, query, availability, max_age_days, or the boolean filters. The description does not compensate for the undocumented half of 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 identifies the resource as recently released UGC Limiteds and specifies the kind of data returned (demand level, stock left, predicted profit scores from RBX Invest). This distinguishes it from siblings like search_items at a high level, though it does not explicitly name any sibling.
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 phrase 'released recently' implies the tool is for recent UGC releases, and the inclusion of RBX Invest scores suggests a use case around evaluating profit potential. However, there is no explicit guidance on when to prefer this tool over search_items or get_item_details, nor any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What a tracked player holds: their most valuable positions plus the totals the leaderboard ranks them on. Follows rank_players, which returns the Roblox user id this needs. A player who set their inventory private comes back marked private rather than empty.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| roblox_user_id | Yes | Numeric Roblox user id, e.g. "27170037". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains the output contents and explicitly handles the private-inventory edge case: such a player 'comes back marked private rather than empty.' It doesn't address auth or rate limits, but the core behavior is well disclosed.
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?
Three compact sentences, each earning its place: the output summary, the prerequisite relationship to rank_players, and the private-inventory behavior. No filler or repetition.
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 two-parameter tool with no output schema, the description covers what is returned, how to obtain the required input, and an important edge case. It could be more explicit about how limit affects results, but it is largely complete for invoking the tool correctly.
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 documents roblox_user_id and gives constraints for limit, but the description only adds meaning for roblox_user_id by saying rank_players returns it. The limit parameter's effect on the returned holdings is not described, so the agent must infer it from the parameter name and defaults.
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 what the tool returns: a tracked player's most valuable holdings and the totals the leaderboard ranks them on. It differentiates this from sibling tools like get_community_holdings by focusing on a single player, and explicitly ties it to rank_players.
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 gives clear usage context: it should be used after rank_players, which provides the required roblox_user_id. It does not explicitly list exclusions or alternatives, but the sequencing guidance is strong enough to orient the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creators ranked across the whole Roblox Limited market — who is biggest, and whose releases most often end up profitable. get_creator answers about one creator you can already name; this finds them. Ranking by profitability shows only creators with enough settled releases to rate, and by growth only those with 3 or more items, because an average over one release is noise.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | chance = how often their releases end up profitable, score = RBX Invest's creator rating, totalValue = RAP across everything they have made, copies = copies of their items in circulation, uniqueItems = how many Limiteds they have released, growth = average lifetime appreciation against the price they first sold at (the old measure, not the windowed move the item sorts call growth). | totalValue |
| limit | No | ||
| query | No | Part of a creator name, to rank within matching creators. | |
| offset | No | Rows to skip, for reading past the first page. | |
| direction | No | desc |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful hidden behavior: profitability ranking requires enough settled releases, and growth ranking requires at least 3 items because a one-item average is noise. It does not mention output shape or pagination behavior, but the disclosed thresholds are valuable.
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?
Three sentences with each earning its place: first establishes scope and purpose, second distinguishes from get_creator, third explains important ranking thresholds. It is front-loaded and free of fluff, though slightly lengthier than the sparsest possible definition.
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?
There is no output schema and no annotations, so the description should clarify what the agent can expect back. It covers ranking semantics and thresholds well, but it does not describe the result shape, what fields are returned per creator, or edge behavior for empty results. Adequate but with clear gaps.
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 60%, with sort, query, and offset described, but limit and direction left to inference. The description adds meaning by explaining profitability and growth sort semantics beyond the enum descriptions, but it does not compensate for the undocumented limit and direction parameters.
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 ranks Roblox UGC creators across the whole Limited market, with a specific focus on who is biggest and whose releases are most often profitable. It also explicitly differentiates from get_creator, which handles a single already-known creator, making the tool's purpose and scope unambiguous.
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?
It directly names get_creator as the alternative when you already know a specific creator, and positions rank_creators as the discovery/ranking tool. It provides clear context for when to use this tool, though it does not explicitly discuss other sibling tools like rank_players or search_items.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The biggest Roblox Limited portfolios RBX Invest tracks, by total RAP held, copies held, or average lifetime appreciation. This covers people who signed up on RBX Invest and linked a Roblox account, not every Roblox player, so a rank from it is a rank on this board rather than a global one.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| metric | No | value = total RAP held, copies = number of copies held, growth = average lifetime appreciation across holdings (only players holding 3 or more copies are ranked). | value |
| offset | No | Rows to skip, for reading past the first page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It reveals a key trait: results are scoped to registered/linked users and are board-specific rather than global. It does not mention output shape, tie-breaking, or update frequency, but for a simple ranked list the provided scope caveat is meaningful.
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 focused sentences front-load the core purpose and then clarify the population limitation. There is no filler or repetition of schema details.
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 definition adequately covers what the tool ranks and the population it covers, which matters for correct invocation. However, with no output schema and no annotations, a description of the return shape or example result would improve completeness; the current description leaves some 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?
The schema already documents all three parameters, including the metric enum with its meanings and limit/offset constraints. The description reinforces the metric semantics by listing total RAP, copies, and average lifetime appreciation, but it does not add substantial meaning beyond what the schema already provides.
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 names a specific resource ('biggest Roblox Limited portfolios RBX Invest tracks') and a clear action ('rank'), and breaks down what ranking means: total RAP held, copies held, or average lifetime appreciation. It also scopes the tool to tracked/linked users, distinguishing it from a global player ranking.
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 gives useful context: this is a leaderboard for RBX Invest users only, not all Roblox players, so an agent can infer it is not appropriate for global rankings. However, it does not explicitly name alternatives like rank_creators or get_player_holdings, nor does it provide a when-to-use versus when-not-to-use comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Roblox Limited catalog by name, or screen the whole market when no query is given. Returns asset id, RAP, RAP across every copy sold, the lowest resale listing, stock left, the move in RAP over 1/7/30 days and lifetime in both percent and Robux, sales counts and sales value per window, and the item score. Rank by any of those with sort, and bound any of them with filters to ask a question with more than one condition in it. Prices are Robux.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Metric to rank by. Size: rap, totalValue, price, copies, copiesLeft, percentRemaining (stock still unsold, the reading the site shows), percentSold (its complement), score. Movement: growth1d/7d/30d/all (percent) and growthRs1d/7d/30d/all (the same move in Robux); only items that sold inside the window have one, and the "all" pair measures against the creator's original price. Trading: volume1d/7d/30d (sales) and salesTotal1d/7d/30d (Robux moved). | rap |
| limit | No | ||
| query | No | Part of an item name, e.g. "valkyrie". Omit to rank or screen the catalog. | |
| offset | No | Rows to skip, for reading past the first page. The reply reports the total that matched. | |
| filters | No | Ranges narrowing the catalog, ANDed together. Each is in the unit its metric is shown in: Robux for rap/totalValue/price/salesTotal*/growthRs*, percent for growth*/percentRemaining/percentSold, a count for copies/copiesLeft/volume*. An item with no value for a bounded metric is excluded. | |
| direction | No | desc | |
| item_type | No | regular_limited is a classic Limited, ugc_limited a UGC one. | all |
| availability | No | available = copies still in stock from the creator. | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It covers the return payload in detail, notes that prices are in Robux, explains that items without a value for a bounded metric are excluded, and mentions that movement metrics only exist for items that sold in the window. This is strong transparency, though it does not state read-only behavior explicitly.
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 dense paragraph but every sentence earns its place: purpose, return fields, units, ranking, filtering, and pricing. It is front-loaded with the main purpose. Slight structuring into two or three sentences with clearer separation would improve scannability, but there is no fluff.
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 tool with 8 parameters, no required arguments, no annotations, and no output schema, this description is unusually complete. It explains both invocation modes, lists the return fields, describes sort and filter capabilities, gives units, and clarifies edge cases like missing values and items with no sales in a window. An agent can call this tool correctly without further inference.
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 75%, and the schema already documents sort, query, offset, filters, item_type, and availability. The description adds useful semantics beyond that: 'Prices are Robux,' omitting query screens the whole market, and filters are ANDed conditions for multi-criteria questions. This exceeds the baseline for high schema coverage.
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 opens with a specific verb and resource: 'Search the Roblox Limited catalog by name, or screen the whole market when no query is given.' This clearly distinguishes it from sibling tools like get_item_details or get_new_limiteds and explains the core dual mode of searching and ranking.
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 gives clear context for when to use the tool: search by name, screen the whole catalog, rank by sort, or filter with multiple conditions. It does not explicitly name sibling tools or exclude cases, but the supported scenarios are stated well enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
find_articlesfind_dealsget_community_holdingsget_creatorget_item_detailsget_market_capget_market_statsget_new_limitedsget_player_holdingsrank_creatorsrank_playerssearch_itemsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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.
No comments yet. Be the first to start the discussion!
Live restock index per collectible niche + will-it-restock predictor (WAIT vs BUY-RESALE).
Roblox public profile + friends + badges + games + groups lookups.
Live eBay market intelligence: underpriced listing scans, price distributions, flip margins.
Read-only Bitcoin blockchain, mempool, mining, market, and on-chain analytics; no API key.
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.
