Read-only Roblox Limiteds market data: RAP, resale prices, deals below RAP, creators, portfolios.
Scored across 12 tools
Each tool maps to a distinct resource—articles, deals, items, creators, players, or market aggregates—and deeper-versus-search counterparts are explicitly differentiated. The only mild ambiguity is get_market_cap vs get_market_stats, but their descriptions separate market capitalization from tracked-portfolio totals.
All tool names follow a consistent snake_case verb_noun pattern, with find/get/search/rank indicating the operation type. No mixed casing or inconsistent verb styles are present.
12 tools is well within the ideal range for a specialized market-data server. Each tool addresses a separate query type—search, detail, rankings, aggregates, deals, articles—without redundancy.
The surface covers item lookup and screening, deep item details, creator and player rankings/holdings, market-wide stats and cap, deals, new releases, and explanatory articles. For read-only market data, there are no obvious dead ends; search_items feeds get_item_details and rank_players feeds get_player_holdings.
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 breakdown of how it was calculated (every input, its weight and how many points it moved the chance and profit-size blends, then the equation), a summary of its price trend, and its full recorded sales history (sales count, first and last sale, high and low daily average, average price by year and for the 12 most recent months with sales, and for UGC when it sold out and whether release buyers could resell at a profit). Use the breakdown to explain why an item scores what it does. 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 provided, the description carries the full burden and does so thoroughly. It discloses all returned data, including sales history, score breakdown, and interpretation caveats. It also warns that stock left does not mean the item is on sale, demonstrating transparency about behavioral nuances.
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 long run-on sentence that packs a wealth of information but is hard to scan. It is not concise, though it is front-loaded with the core purpose and every sentence earns its place by adding detail. Structure could be improved with bullets or paragraphs.
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 read tool with no output schema, the description thoroughly explains all returned data points, interpretation hints, and prerequisites. Nothing essential for calling the tool correctly is missing, including the need for an asset id and the distinction between stock and active sale status.
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 asset_id clearly, and the description reinforces it. For trend_days, the description hints at a 'window' but does not explicitly connect it to the parameter, leaving ambiguity. With 50% schema coverage, more compensation would be expected, but the description adds some value.
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 'Everything tracked about one Roblox Limited' and then enumerates a comprehensive list of specific data points. It distinguishes itself from siblings by requiring a numeric asset id and explicitly directing users to search_items to obtain one.
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 a clear prerequisite (get asset id from search_items first) and a specific interpretation rule (read creator_still_selling rather than copies_remaining to determine if an item is on sale). It does not explicitly list alternative tools, but the context makes it clear this is for deep dives on a single item.
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/14/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 (cheapest copy from any seller), creatorPrice (the creator's price for a new copy; only items still on sale from the creator have one), copies, copiesLeft, percentRemaining (stock still unsold, the reading the site shows), percentSold (its complement), score. Movement: growth1d/7d/14d/30d/all (percent) and growthRs1d/7d/14d/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/14d/30d (sales) and salesTotal1d/7d/14d/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/creatorPrice/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 |
| asset_type | No | Only this kind of item, e.g. Hat, HairAccessory, FaceAccessory, BackAccessory, Face, Gear. Omit for every kind. | |
| 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, the description carries the behavioral burden. It explains the no-query behavior, the computed return fields, the units, and the ranking/filtering capabilities. It does not mention pagination behavior or response shape, but those are covered in the schema and the behavior described is otherwise 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 dense sentences with no filler: the first states the core capability, the second enumerates return fields, and the third explains ranking, filtering, and units. The most important scoping behavior 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?
Given 9 parameters, 5 enums, and no output schema, the description is quite complete: it explains return fields, the no-query screen behavior, ranking, filtering, and units. It could additionally describe the exact output shape or maximum result size, but the rich schema covers most of those details.
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 78%, so the schema already does much of the work. The description adds useful semantic context by mapping return concepts to sort/filter metrics and stating that prices are in Robux. It could name parameter specifics more directly, but it meaningfully complements 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 names a specific verb and resource: searching or ranking the Roblox Limited catalog, and it adds the key scope distinction that omitting the query screens the whole market. This clearly separates it from item-detail and new-limiteds siblings by emphasizing market-wide ranking and filtering.
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 contexts: search by name when you have a name, screen the whole market when you don't, and use sort/filters to ask multi-condition questions. It does not explicitly name sibling tools or give when-not-to-use guidance, 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
search_items1 field changedInput schema / properties / asset_type / enumPrevious value: -[
- "AvatarBackground",
- "BackAccessory",
- "DressSkirtAccessory",
- "DynamicHead",
- "EmoteAnimation",
- "EyebrowAccessory",
- "EyelashAccessory",
- "Face",
- "FaceAccessory",
- "FaceMakeup",
- "FrontAccessory",
- "Gear",
- "HairAccessory",
- "Hat",
- "JacketAccessory",
- "LeftShoeAccessory",
- "LipMakeup",
- "NeckAccessory",
- "PantsAccessory",
- "ShirtAccessory",
- "ShortsAccessory",
- "ShoulderAccessory",
- "SweaterAccessory",
- "TShirtAccessory",
- "WaistAccessory"
-]New value: +[
+ "AvatarBackground",
+ "BackAccessory",
+ "DressSkirtAccessory",
+ "DynamicHead",
+ "EmoteAnimation",
+ "EyebrowAccessory",
+ "EyelashAccessory",
+ "EyeMakeup",
+ "Face",
+ "FaceAccessory",
+ "FaceMakeup",
+ "FrontAccessory",
+ "Gear",
+ "HairAccessory",
+ "Hat",
+ "JacketAccessory",
+ "LeftShoeAccessory",
+ "LipMakeup",
+ "NeckAccessory",
+ "PantsAccessory",
+ "ShirtAccessory",
+ "ShortsAccessory",
+ "ShoulderAccessory",
+ "SweaterAccessory",
+ "TShirtAccessory",
+ "WaistAccessory"
+]search_items1 field changedInput schema / properties / asset_type / enumPrevious value: -[
- "AvatarBackground",
- "BackAccessory",
- "DressSkirtAccessory",
- "DynamicHead",
- "EmoteAnimation",
- "EyebrowAccessory",
- "EyelashAccessory",
- "Face",
- "FaceAccessory",
- "FrontAccessory",
- "Gear",
- "HairAccessory",
- "Hat",
- "JacketAccessory",
- "LeftShoeAccessory",
- "NeckAccessory",
- "PantsAccessory",
- "ShirtAccessory",
- "ShortsAccessory",
- "ShoulderAccessory",
- "SweaterAccessory",
- "TShirtAccessory",
- "WaistAccessory"
-]New value: +[
+ "AvatarBackground",
+ "BackAccessory",
+ "DressSkirtAccessory",
+ "DynamicHead",
+ "EmoteAnimation",
+ "EyebrowAccessory",
+ "EyelashAccessory",
+ "Face",
+ "FaceAccessory",
+ "FaceMakeup",
+ "FrontAccessory",
+ "Gear",
+ "HairAccessory",
+ "Hat",
+ "JacketAccessory",
+ "LeftShoeAccessory",
+ "LipMakeup",
+ "NeckAccessory",
+ "PantsAccessory",
+ "ShirtAccessory",
+ "ShortsAccessory",
+ "ShoulderAccessory",
+ "SweaterAccessory",
+ "TShirtAccessory",
+ "WaistAccessory"
+]search_items1 field changedInput schema / properties / asset_typeAdded value: +{
+ "description": "Only this kind of item, e.g. Hat, HairAccessory, FaceAccessory, BackAccessory, Face, Gear. Omit for every kind.",
+ "enum": [
+ "AvatarBackground",
+ "BackAccessory",
+ "DressSkirtAccessory",
+ "DynamicHead",
+ "EmoteAnimation",
+ "EyebrowAccessory",
+ "EyelashAccessory",
+ "Face",
+ "FaceAccessory",
+ "FrontAccessory",
+ "Gear",
+ "HairAccessory",
+ "Hat",
+ "JacketAccessory",
+ "LeftShoeAccessory",
+ "NeckAccessory",
+ "PantsAccessory",
+ "ShirtAccessory",
+ "ShortsAccessory",
+ "ShoulderAccessory",
+ "SweaterAccessory",
+ "TShirtAccessory",
+ "WaistAccessory"
+ ],
+ "type": "string"
+}search_items4 fields changedInput schema / properties / filters / descriptionPrevious value: -"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."New value: +"Ranges narrowing the catalog, ANDed together. Each is in the unit its metric is shown in: Robux for rap/totalValue/price/creatorPrice/salesTotal*/growthRs*, percent for growth*/percentRemaining/percentSold, a count for copies/copiesLeft/volume*. An item with no value for a bounded metric is excluded."Input schema / properties / filters / items / properties / metric / enumPrevious value: -[
- "rap",
- "totalValue",
- "price",
- "growth1d",
- "growth7d",
- "growth14d",
- "growth30d",
- "growthall",
- "growthRs1d",
- "growthRs7d",
- "growthRs14d",
- "growthRs30d",
- "growthRsall",
- "score",
- "copies",
- "copiesLeft",
- "percentSold",
- "percentRemaining",
- "volume1d",
- "volume7d",
- "volume14d",
- "volume30d",
- "demandGrowth1d",
- "demandGrowth7d",
- "demandGrowth14d",
- "demandGrowth30d",
- "salesTotal1d",
- "salesTotal7d",
- "salesTotal14d",
- "salesTotal30d"
-]New value: +[
+ "rap",
+ "totalValue",
+ "price",
+ "creatorPrice",
+ "growth1d",
+ "growth7d",
+ "growth14d",
+ "growth30d",
+ "growthall",
+ "growthRs1d",
+ "growthRs7d",
+ "growthRs14d",
+ "growthRs30d",
+ "growthRsall",
+ "score",
+ "copies",
+ "copiesLeft",
+ "percentSold",
+ "percentRemaining",
+ "volume1d",
+ "volume7d",
+ "volume14d",
+ "volume30d",
+ "demandGrowth1d",
+ "demandGrowth7d",
+ "demandGrowth14d",
+ "demandGrowth30d",
+ "salesTotal1d",
+ "salesTotal7d",
+ "salesTotal14d",
+ "salesTotal30d"
+]Input schema / properties / sort / descriptionPrevious value: -"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/14d/30d/all (percent) and growthRs1d/7d/14d/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/14d/30d (sales) and salesTotal1d/7d/14d/30d (Robux moved)."New value: +"Metric to rank by. Size: rap, totalValue, price (cheapest copy from any seller), creatorPrice (the creator's price for a new copy; only items still on sale from the creator have one), copies, copiesLeft, percentRemaining (stock still unsold, the reading the site shows), percentSold (its complement), score. Movement: growth1d/7d/14d/30d/all (percent) and growthRs1d/7d/14d/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/14d/30d (sales) and salesTotal1d/7d/14d/30d (Robux moved)."Input schema / properties / sort / enumPrevious value: -[
- "rap",
- "totalValue",
- "price",
- "growth1d",
- "growth7d",
- "growth14d",
- "growth30d",
- "growthall",
- "growthRs1d",
- "growthRs7d",
- "growthRs14d",
- "growthRs30d",
- "growthRsall",
- "score",
- "copies",
- "copiesLeft",
- "percentSold",
- "percentRemaining",
- "volume1d",
- "volume7d",
- "volume14d",
- "volume30d",
- "demandGrowth1d",
- "demandGrowth7d",
- "demandGrowth14d",
- "demandGrowth30d",
- "salesTotal1d",
- "salesTotal7d",
- "salesTotal14d",
- "salesTotal30d"
-]New value: +[
+ "rap",
+ "totalValue",
+ "price",
+ "creatorPrice",
+ "growth1d",
+ "growth7d",
+ "growth14d",
+ "growth30d",
+ "growthall",
+ "growthRs1d",
+ "growthRs7d",
+ "growthRs14d",
+ "growthRs30d",
+ "growthRsall",
+ "score",
+ "copies",
+ "copiesLeft",
+ "percentSold",
+ "percentRemaining",
+ "volume1d",
+ "volume7d",
+ "volume14d",
+ "volume30d",
+ "demandGrowth1d",
+ "demandGrowth7d",
+ "demandGrowth14d",
+ "demandGrowth30d",
+ "salesTotal1d",
+ "salesTotal7d",
+ "salesTotal14d",
+ "salesTotal30d"
+]search_items3 fields changedInput schema / properties / filters / items / properties / metric / enumPrevious value: -[
- "rap",
- "totalValue",
- "price",
- "growth1d",
- "growth7d",
- "growth30d",
- "growthall",
- "growthRs1d",
- "growthRs7d",
- "growthRs30d",
- "growthRsall",
- "score",
- "copies",
- "copiesLeft",
- "percentSold",
- "percentRemaining",
- "volume1d",
- "volume7d",
- "volume30d",
- "demandGrowth1d",
- "demandGrowth7d",
- "demandGrowth30d",
- "salesTotal1d",
- "salesTotal7d",
- "salesTotal30d"
-]New value: +[
+ "rap",
+ "totalValue",
+ "price",
+ "growth1d",
+ "growth7d",
+ "growth14d",
+ "growth30d",
+ "growthall",
+ "growthRs1d",
+ "growthRs7d",
+ "growthRs14d",
+ "growthRs30d",
+ "growthRsall",
+ "score",
+ "copies",
+ "copiesLeft",
+ "percentSold",
+ "percentRemaining",
+ "volume1d",
+ "volume7d",
+ "volume14d",
+ "volume30d",
+ "demandGrowth1d",
+ "demandGrowth7d",
+ "demandGrowth14d",
+ "demandGrowth30d",
+ "salesTotal1d",
+ "salesTotal7d",
+ "salesTotal14d",
+ "salesTotal30d"
+]Input schema / properties / sort / descriptionPrevious value: -"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)."New value: +"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/14d/30d/all (percent) and growthRs1d/7d/14d/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/14d/30d (sales) and salesTotal1d/7d/14d/30d (Robux moved)."Input schema / properties / sort / enumPrevious value: -[
- "rap",
- "totalValue",
- "price",
- "growth1d",
- "growth7d",
- "growth30d",
- "growthall",
- "growthRs1d",
- "growthRs7d",
- "growthRs30d",
- "growthRsall",
- "score",
- "copies",
- "copiesLeft",
- "percentSold",
- "percentRemaining",
- "volume1d",
- "volume7d",
- "volume30d",
- "demandGrowth1d",
- "demandGrowth7d",
- "demandGrowth30d",
- "salesTotal1d",
- "salesTotal7d",
- "salesTotal30d"
-]New value: +[
+ "rap",
+ "totalValue",
+ "price",
+ "growth1d",
+ "growth7d",
+ "growth14d",
+ "growth30d",
+ "growthall",
+ "growthRs1d",
+ "growthRs7d",
+ "growthRs14d",
+ "growthRs30d",
+ "growthRsall",
+ "score",
+ "copies",
+ "copiesLeft",
+ "percentSold",
+ "percentRemaining",
+ "volume1d",
+ "volume7d",
+ "volume14d",
+ "volume30d",
+ "demandGrowth1d",
+ "demandGrowth7d",
+ "demandGrowth14d",
+ "demandGrowth30d",
+ "salesTotal1d",
+ "salesTotal7d",
+ "salesTotal14d",
+ "salesTotal30d"
+]find_articlesfind_dealsget_community_holdingsget_creatorget_item_detailsget_market_capget_market_statsget_new_limitedsget_player_holdingsrank_creatorsrank_playerssearch_itemsTrading card prices and grading ROI for 1.5M+ Pokémon, Magic, Yu-Gi-Oh! and sports cards. Read-only.
Read-only crypto and traditional portfolio: holdings, PNL, FIFO tax figures and market data.
Live restock index per collectible niche + will-it-restock predictor (WAIT vs BUY-RESALE).
Read-only impersonal market research: portfolio rankings, ticker scores, signals, daily briefs.
Add one secure layer between your agents and this server.