This server is an AI-facing MCP server for Hypixel SkyBlock that fetches and processes game data into compact JSON for AI assistants.
Player & Profiles
Resolve Minecraft usernames or UUIDs via Mojang normalization
Fetch Hypixel network stats (rank, login times, karma, online status)
List SkyBlock profiles with compact metadata
Get detailed profile context: skills, slayers, dungeons, pets, collections, currencies, accessories, and decoded inventories
Inventories & Storage
Decode inventory sections (wardrobe, armor, equipment, ender chest, backpacks, vault, bags) from base64 gzipped NBT
Search merged storage across backpacks, ender chest, vault, sacks, and bags with item grouping and sack totals
Progression & Guides
Audit a profile with skill levels, HOTM/HOTF perk trees, minions, bestiary, Crimson Isle, Rift, essence, gear summaries, accessory analysis, and prioritized next actions
Build guide context combining profile data with active mayor and Bazaar economy signals for tailored advice
World Systems
Fetch museum donations and value summaries
Fetch garden plot, commission, and composter data
Economy & Resources
Estimate net worth from liquid coins, inventory/storage items, and sacks priced with live Bazaar data
Look up items by ID or name for metadata, live Bazaar prices, lowest-BIN, and optional wiki context
Query Bazaar prices, volumes, and spread signals
Browse auctions (active pages, recently ended, or keyed lookups by player/profile/auction)
Calculate essence, coin, and material costs to star up dungeon/crimson gear with optional live Bazaar estimates
Fetch public SkyBlock resources (items, skills, collections, election/mayor, bingo, news)
Wiki & Utilities
Search and fetch official Hypixel SkyBlock Wiki pages with section summaries
Decode raw base64 gzipped NBT payloads into plain JSON and compact item lists
Clear the in-memory response cache
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@hypixel-skyblock-mcp get skyblock profile for Technoblade"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An AI-facing Model Context Protocol server for Hypixel SkyBlock data. It fetches profile data, public resources, Bazaar prices, auctions, museum/garden data, HOTM/HOTF skill trees, merged storage search, and base64 gzipped NBT inventory payloads, then returns compact JSON that is easier for an AI assistant to use for guides and tips.
Node.js 22 or newer
A Hypixel API key for private/profile endpoints
Get a key from the Hypixel Developer Dashboard and provide it as HYPIXEL_API_KEY.
Related MCP server: riocloud-reader
Add the server to your MCP client config. The package ships a hypixel-skyblock-mcp binary, so npx can run it without a manual install:
{
"mcpServers": {
"hypixel-skyblock": {
"command": "npx",
"args": ["-y", "hypixel-skyblock-mcp"],
"env": {
"HYPIXEL_API_KEY": "your-key"
}
}
}
}See .env.example for the full list of supported environment variables (cache TTL, request timeout, optional lowest-BIN source).
npm install
npm run build
node dist/server.js # reads HYPIXEL_API_KEY from the environmentnpm test # run the unit tests
npm run coverage # run tests + enforce coverage thresholds
npm run check # build + test (also runs automatically before publish)GitHub Actions runs the build and the coverage gate on every push and pull
request (.github/workflows/ci.yml). The coverage gate (configured in
vitest.config.ts) is scoped to the deterministic, pure-logic modules; the
network/orchestration layer that calls the live Hypixel API is verified
manually rather than by unit tests.
Publishing is automated (.github/workflows/publish.yml): creating a GitHub
Release whose tag matches the package.json version publishes the package to
npm with provenance. Authentication uses npm
Trusted Publishing (OIDC), so no
NPM_TOKEN secret is required — configure a Trusted Publisher for this repo and
workflow in the package's npm settings instead.
resolve_player: username/UUID normalization through Mojang.
hypixel_player: network status, rank, login times, karma, and selected stats.
skyblock_profiles: compact list of a player's SkyBlock profiles.
skyblock_profile: one profile's AI-readable context with skills, progression, slayers, dungeons, pets, collections, essence, accessories, and optional decoded inventories.
skyblock_inventory: decode wardrobe, armor, equipment, ender chest, backpacks, vault, sacks, bags, and loadouts.
skyblock_storage: merged storage search across backpacks, ender chest, vault, sacks, and bags with item grouping and sack totals.
skyblock_audit: compact audit with official skill levels, full HOTM/HOTF perk trees, minions, bestiary, crimson isle, rift, essence, gear/loadouts (including essence cost to finish starring equipped gear, priced live), accessories, ranked gaps, and next actions.
skyblock_guide_context: profile plus mayor and Bazaar economy signals for tailored advice.
skyblock_museum: museum donations and value summary.
skyblock_garden: garden plots, commissions, and composter data.
skyblock_networth: estimate a profile's net worth from liquid coins, decoded inventory/storage holdings, sacks, and supported item modifiers, priced with live Bazaar data. Returns a total, per-section breakdown, modifier breakdown, top items by value, and a pricing-coverage report.
skyblock_item: look up one item by ID or name and get official metadata plus a live value (Bazaar buy/sell/spread/volume, lowest-BIN when configured, or a clear auction-only note). Set includeWiki: true to enrich the result with official Hypixel SkyBlock Wiki page URL, revision timestamp, and cleaned obtaining/upgrading/usage/history sections. Ambiguous searches return candidate IDs, and it resolves in-game names (e.g. "Necron's Chestplate") to canonical IDs.
skyblock_resource: items, skills, collections, election/mayor, bingo, or news.
skyblock_wiki_search: search the official Hypixel SkyBlock Wiki through its MediaWiki API.
skyblock_wiki_page: fetch a specific official wiki page and return AI-readable section summaries from the page wikitext.
skyblock_bazaar: Bazaar prices, volumes, and spread signals.
skyblock_auctions: active pages, ended auctions, or keyed lookups.
skyblock_essence_costs: exact essence, coin, and material cost to star up (or master-star) a dungeon/crimson item by SkyBlock ID, with an optional live-Bazaar coin estimate. Returns found: false with suggestions for unknown or non-upgradeable IDs.
decode_skyblock_nbt: decode a SkyBlock NBT payload.
cache_clear: clear the in-memory response cache.
HOTM (Heart of the Mountain) is summarized in member.progression.hotm and skyblock_audit:
HOTM level, powder totals, crystal states, selected ability
Full unlocked perk list with human-readable names
HOTF (Heart of the Forest) is summarized in member.progression.hotf:
Forest Whispers balance and spend
Unlocked foraging perks and selected ability
Storage is best accessed through skyblock_storage:
{ "username": "Ventoy", "search": "enchanted diamond" }{
"username": "Ventoy",
"skyblockIds": ["DIVAN_HELMET", "DIVAN_CHESTPLATE"],
"sectionTypes": ["backpack", "ender_chest", "personal_vault"]
}skyblock_inventory remains the tool for raw per-section NBT when you need slot-level detail.
skyblock_profile (per member) and skyblock_audit (ratings) expose the headline numbers players compare:
Skill average (and fractional "true" average) over the eight counted skills: Farming, Mining, Combat, Foraging, Fishing, Enchanting, Alchemy, Taming.
Total slayer XP and summed slayer levels, plus per-boss XP/level.
Catacombs level, magical power, and SkyBlock level.
skyblock_audit and skyblock_guide_context also include a compact mayor summary: the active mayor, special-mayor flag, active perks, and the ongoing election leaderboard.
skyblock_networth prices a profile from:
Liquid coins (purse + bank).
Items in decoded inventory, ender chest, backpacks, personal vault, wardrobe, armor, equipment, and bags, priced by SkyBlock ID via the Bazaar.
Sacks, priced via the Bazaar.
On top of the base SkyBlock-ID price, skyblock_networth adds modifier value for enchantments, hot potato/fuming books, recombobulators, essence/master stars, socketed gemstones, and reforge stones (set includeModifiers: false to disable). Each modifier is valued at the SkyHelper-Networth "application worth" fraction of the live Bazaar price of the component (e.g. enchantments at 85%, essence at 75%, gemstones and reforge stones at 100%), and essence/master-star costs come from the official items resource's upgrade_costs. The response reports items.modifiers (total, byType breakdown, and unpricedComponents).
The modifier categories above are the ones currently modelled. SkyHelper values several more that this server does not yet add, so total is a conservative estimate for heavily upgraded items: gemstone slot-unlock costs, runes, dyes, pet items/pet levels, art of war/peace, power scrolls, and other cosmetic or upgrade consumables are excluded.
Modifier value is only added to items that already have a base price, so auction-only gear is undervalued unless a lowest-BIN source is configured. Read the coverage report (pricedPercent) to see how much of the profile could be priced, and treat total as an estimate.
Auction-only items are priced only when an external lowest-BIN source is configured via the SKYBLOCK_LOWEST_BIN_URL environment variable (a JSON map of { SKYBLOCK_ID: price }, e.g. a Moulberry-style lowest-BIN dump). Bazaar prices always take precedence over that source. Use priceBasis to switch between buy (market/replacement value, default) and sell (liquidation value).
Hypixel profile data depends on each player's in-game API settings. When fields are missing, the MCP returns privacy notes so the AI does not overclaim inventory, pet, collection, or skill state.
Skill levels use Hypixel's official /v2/resources/skyblock/skills tables (bundled in src/skill-tables.json). SkyBlock level uses the flat 100-XP-per-level formula, pet levels use the official per-rarity XP tables (Golden/Jade/Rose Dragons cap at level 200), and Garden level uses the real Garden XP table (15 levels, capping at 60,120 XP).
Essence upgrade costs (skyblock_essence_costs) come from the NotEnoughUpdates essencecosts.json constants (bundled in src/essence-costs.json). The dataset covers essence-funded stars (1–5 for dungeon gear, up to 10 for crimson/kuudra gear); Master Stars applied with Master Star items are noted but not priced.
For profile reviews, prefer skyblock_audit over skyblock_guide_context when you want compact gaps and next actions.
The server uses the official Hypixel Public API v2. Keyed endpoints use the API-Key header and report rate-limit headers when Hypixel provides them.
Clear this MCP server's in-memory Hypixel and Mojang response cache.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates it clears an in-memory cache, which is non-destructive but does not disclose side effects or scope. Since no annotations exist, the description carries the burden, but it omits details like idempotency, impact on other cached data, or performance implications.
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, concise sentence that immediately conveys the action. Every word serves a purpose with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless tool with no output schema, the description adequately explains the function. It could mention that it affects all users of the server, but overall it is sufficient.
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 input schema has zero parameters, so there is nothing for the description to add beyond what the schema provides. A baseline of 4 is appropriate since no parameter information is needed.
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 clears the MCP server's in-memory Hypixel and Mojang response cache. The verb 'Clear' and specific resource are well-defined, and none of the sibling tools have similar cache-clearing functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, or under what circumstances cache clearing is appropriate. The description lacks context such as 'use after data updates' or 'to force refresh'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode a Hypixel SkyBlock base64 gzipped NBT inventory/item payload into plain JSON and a compact item list.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| maxItems | No | ||
| includeRaw | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits beyond the basic operation. It omits error handling, input validation, or potential side effects, leaving the agent uninformed about what happens under various conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that efficiently conveys the core purpose. No wasted words, and the key action 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 the lack of output schema, annotations, and parameter explanations, the description is incomplete. It does not clarify the output structure or parameter constraints, leaving significant gaps for a tool with 3 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 input schema has 0% description coverage, and the tool description does not explain any of the parameters (data, maxItems, includeRaw). The agent cannot infer the meaning of maxItems or includeRaw from the text.
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 verb 'decode', the resource 'base64 gzipped NBT inventory/item payload', and the output 'plain JSON and a compact item list'. It uniquely identifies the tool's function among siblings which are mostly about player data and market info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, nor any prerequisites or conditions. The description simply states the action without context about appropriate invocation scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch Hypixel network player data: online status, rank, login times, karma, and selected network stats. Requires HYPIXEL_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | No | Minecraft UUID, dashed or undashed. | |
| username | No | Minecraft username. Use this when the user gives a name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only discloses the API key requirement and lists data types. It does not mention error handling, rate limits, read-only nature, or behavior for missing players.
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 concise sentence with an additional requirement note. It is front-loaded and free of redundancy, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description is minimally adequate but lacks details on errors, API key usage, and exact stats returned. It is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The tool description adds no additional information about the parameters 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 clearly states the verb 'Fetch' and resource 'Hypixel network player data', listing specific data types (online status, rank, login times, karma, selected network stats). It distinguishes from skyblock-focused siblings by focusing on general player status.
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 only mentions the requirement for HYPIXEL_API_KEY but does not provide guidance on when to use this tool vs alternatives (e.g., resolve_player) or how to choose between uuid and username parameters. No usage context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a Minecraft username or UUID into normalized UUID forms for Hypixel tools.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | No | Minecraft UUID, dashed or undashed. | |
| username | No | Minecraft username. Use this when the user gives a name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions 'normalized UUID forms' but does not disclose behavior for invalid inputs, parameter priority if both uuid and username are provided, or any error handling. Minimal insight into side effects 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?
Single sentence, front-loaded with purpose, zero waste. Every word earns its place.
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 simplicity, description lacks critical context: parameter precedence, output format, validation behavior, and whether it involves network calls. No output schema to supplement. Incomplete for a resolver tool with two optional 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?
Schema has 100% coverage, already describing both parameters clearly. The description adds value by stating overall purpose but does not elaborate on parameter semantics beyond what schema provides. Baseline 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?
Description clearly states the action 'Resolve', the resource 'Minecraft username or UUID', and the purpose 'into normalized UUID forms for Hypixel tools'. This distinguishes it from sibling tools like hypixel_player which retrieves player data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for Hypixel tools' implies usage as a prerequisite before other Hypixel tools, but there is no explicit guidance on when to use versus alternatives, nor when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch active auction pages, recently ended auctions, or API-key auction lookups by auction, player, or profile. Filters output for AI use.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | ||
| page | No | ||
| tier | No | ||
| limit | No | ||
| search | No | ||
| binOnly | No | ||
| category | No | ||
| profileId | No | ||
| includeRaw | No | ||
| playerUuid | No | ||
| auctionUuid | No | ||
| playerUsername | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'filters output for AI use' but does not explain the filtering criteria, authentication needs, or side effects. The behavioral differences between modes are not detailed.
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 tight two sentences that front-load the key actions and modes. Every sentence adds value with no 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?
Given 12 parameters, no output schema, and no annotations, the description is insufficient. It does not explain modes, required parameters, or return structure, leaving significant gaps for effective use.
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 0%, so the description must compensate. It only mentions three modes and filtering by auction/player/profile, leaving 9 undocumented parameters (e.g., page, tier, limit, search) without clarification. The description adds minimal meaning beyond the schema's property names.
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 fetches auctions with three distinct modes (active_page, ended_recent, lookup) and specifies filtering by auction, player, or profile. It distinguishes itself from sibling tools like skyblock_bazaar by focusing on auctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates modes of use but does not provide guidance on when to prefer this tool over alternatives, nor does it mention conditions for use or exclusions. No sibling differentiation is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a compact profile audit with computed levels, HOTM/HOTF trees, progression gaps, gear/loadout summaries, accessory analysis, and prioritized next actions.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | No | Minecraft UUID, dashed or undashed. | |
| focus | No | Audit focus areas: mining, foraging, farming, dungeons, slayers, money, combat, pets, accessories, skills, progression. | |
| username | No | Minecraft username. Use this when the user gives a name. | |
| profileId | No | Specific SkyBlock profile UUID. | |
| memberUuid | No | Coop member UUID to inspect. Defaults to requested player. | |
| profileName | No | Cute profile name, for example Apple, Lemon, or Coconut. | |
| includeMayor | No | ||
| selectedOnly | No | Prefer the selected profile when multiple profiles exist. | |
| includeEconomy | No | ||
| memberUsername | No | Coop member username to inspect. Defaults to requested player. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description outlines what the tool computes but does not disclose any behavioral traits such as data source latency, authentication requirements, potential errors if profile data is missing, or if external API calls are made. It appears read-only, but no guarantees stated.
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, information-dense sentence covering multiple output categories. It is efficient but could be more readable (e.g., bullet points). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, so the description should hint at return format; it only lists computed items. Also, with 10 optional parameters, there is no guidance on minimal requirements to identify a profile (e.g., uuid or username). The description is adequate but leaves 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 description coverage is 80%, so the schema already documents most parameters adequately. The tool description does not add additional parameter-level details beyond what the schema provides, meeting the baseline for high 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 clearly states 'Return a compact profile audit' and lists specific outputs: computed levels, HOTM/HOTF trees, progression gaps, gear/loadout summaries, accessory analysis, and prioritized next actions. This distinguishes it from sibling tools like skyblock_profile (raw data) and skyblock_networth (net worth only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. It implies a comprehensive audit use case but does not contrast with skyblock_profile, skyblock_networth, or other siblings. No prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch current Bazaar product prices, volumes, and spread signals. Useful for money-making tips and crafting cost checks.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| search | No | ||
| sortBy | No | movingWeek | |
| includeRaw | No | ||
| productIds | No | ||
| includeOrders | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only mentions fetching data, but omits information about permissions, rate limits, response format, or behavior with invalid inputs.
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 concise, with two short sentences. The first sentence identifies the action and outputs; the second adds use cases. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters with no schema descriptions, no output schema, and no annotations, the description is incomplete. It does not enable an agent to use the tool effectively without additional knowledge.
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 provides no information about any of the 6 parameters. Schema coverage is 0%, so the description fails to compensate by explaining what parameters like 'limit', 'search', or 'sortBy' do.
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's action ('Fetch') and specific resources ('current Bazaar product prices, volumes, and spread signals'). It is distinct from sibling tools like skyblock_auctions or skyblock_item.
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 context for usage ('useful for money-making tips and crafting cost checks') but does not explicitly state when not to use or name alternative tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the exact essence, coin, and material cost to star up (or master-star) a dungeon/crimson item by its SkyBlock ID, using authoritative per-star cost data. Optionally prices essence and materials with live Bazaar data for a coin estimate. Returns found=false with suggestions when the item ID is not star-upgradeable or not recognized.
| Name | Required | Description | Default |
|---|---|---|---|
| itemId | Yes | Canonical SkyBlock item ID, for example NECRON_CHESTPLATE, HYPERION, or CRIMSON_HELMET. | |
| toStar | No | Target star level. Defaults to the item's maximum (includes master stars). | |
| fromStar | No | Current star level (0 = no stars). | |
| quantity | No | Number of identical items to upgrade (e.g. a full 4-piece armor set). | |
| priceBasis | No | buy = replacement cost (insta-buy), sell = liquidation value (insta-sell). | buy |
| priceWithBazaar | No | Convert essence and material costs into an estimated coin cost using live Bazaar prices. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that it uses authoritative per-star cost data and can optionally price with live Bazaar data. It also specifies the response behavior for invalid items. It lacks mention of rate limits or permissions, but for a read-only calculation tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each serving a clear purpose. The first sentence states the primary function, and the second addresses edge cases. No superfluous information, making it efficient for an AI to parse.
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, the description explains the return behavior for unrecognized items. It covers optional parameters and data sources. However, it does not describe the output format for successful cases, but for a cost calculator, the purpose is well-understood without full schema.
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 baseline is 3. The description adds context about using authoritative data and optional Bazaar pricing, but does not significantly enhance meaning beyond the schema's parameter descriptions. It provides a high-level overview but no additional parameter-level details.
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's purpose: computing essence, coin, and material costs for starring dungeon/crimson items by SkyBlock ID. It uses specific verbs like 'compute' and 'star up', and the resource is well-defined. This distinctively sets it apart from sibling tools like skyblock_auctions or skyblock_bazaar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: for upgrading items with stars, using authoritative cost data and optional Bazaar pricing. It explains behavior for unrecognized items (returns found=false with suggestions). However, it does not explicitly state when to use this tool versus alternatives, such as skyblock_item for generic info, but the use case is fairly specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch garden plot, commission, and composter data for a SkyBlock profile.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | No | Minecraft UUID, dashed or undashed. | |
| username | No | Minecraft username. Use this when the user gives a name. | |
| profileId | No | Specific SkyBlock profile UUID. | |
| memberUuid | No | Coop member UUID to inspect. Defaults to requested player. | |
| profileName | No | Cute profile name, for example Apple, Lemon, or Coconut. | |
| selectedOnly | No | Prefer the selected profile when multiple profiles exist. | |
| memberUsername | No | Coop member username to inspect. Defaults to requested player. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It indicates a read operation but omits details about authentication, rate limits, or potential side effects. The description is adequate but minimal.
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, well-structured sentence that is front-loaded with the core action. Every word is necessary and no extraneous information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and no output schema, the description is too brief. It does not explain return values, parameter dependencies, or common usage patterns, leaving significant gaps for an agent.
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 fully documents parameters. The description adds no additional meaning beyond the schema, earning the baseline score of 3.
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 uses a specific verb ('fetch') and clearly identifies the resource ('garden plot, commission, and composter data') and scope ('for a SkyBlock profile'). It distinguishes from sibling tools like skyblock_profile by focusing on garden-specific data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when garden data is needed, but does not explicitly state when to use this tool versus alternatives like skyblock_profile, nor does it provide any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a profile plus current mayor and economy signals so an AI can write tailored SkyBlock progression advice. Requires HYPIXEL_API_KEY for player/profile data.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | No | Minecraft UUID, dashed or undashed. | |
| goals | No | Guide focus areas, for example mining, farming, dungeons, money. | |
| username | No | Minecraft username. Use this when the user gives a name. | |
| profileId | No | Specific SkyBlock profile UUID. | |
| memberUuid | No | Coop member UUID to inspect. Defaults to requested player. | |
| profileName | No | Cute profile name, for example Apple, Lemon, or Coconut. | |
| includeMayor | No | ||
| maxLoreLines | No | ||
| selectedOnly | No | Prefer the selected profile when multiple profiles exist. | |
| includeGarden | No | ||
| includeMuseum | No | ||
| includeRawNbt | No | Include simplified raw NBT for decoded sections. Very large output. | |
| includeEconomy | No | ||
| memberUsername | No | Coop member username to inspect. Defaults to requested player. | |
| decodeInventories | No | ||
| includeAllNbtData | No | Search every base64 NBT payload on the member, not only inventory-like paths. | |
| includeItemDetails | No | Include extra compact ExtraAttributes fields on decoded items. | |
| maxInventorySections | No | ||
| maxItemsPerInventory | No | ||
| inventorySectionPaths | No | Filter decoded inventory sections by case-insensitive path substring, for example wardrobe_contents or backpack_contents. | |
| inventorySectionTypes | No | Filter decoded inventory sections by type. Common values: inventory, wardrobe, armor, equipment, ender_chest, backpack, accessory_bag, potion_bag, fishing_bag, quiver, personal_vault, sack, loadout, container, unknown. Omit or include all for all inventory-like sections. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions an API key requirement and implies data fetching, but does not specify rate limits, output size, error behavior, or side effects. For a composite tool with many parameters, this is insufficient transparency.
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 extremely concise with only two sentences. The first sentence captures the tool's purpose and outcome, and the second states a key prerequisite. No superfluous content; every sentence is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (21 parameters, no output schema, many sibling tools), the description lacks crucial context such as output format, return structure, error cases, or size implications. An agent cannot fully anticipate the tool's behavior or integrate its output into a progression advice workflow from this description alone.
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 62%, and the description adds no extra meaning beyond the schema's parameter descriptions. The schema itself provides adequate descriptions for most parameters (e.g., 'goals' has a clear example), so baseline 3 is appropriate despite no added value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb ('Fetch'), resource ('profile plus current mayor and economy signals'), and purpose ('so an AI can write tailored SkyBlock progression advice'). It distinguishes itself from sibling tools that focus on individual data sources (e.g., skyblock_profile, skyblock_bazaar) by combining multiple signals into a single context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite (HYPIXEL_API_KEY) but does not provide explicit when-to-use or when-not-to-use guidance relative to sibling tools. It implies use for tailored advice but lacks exclusions or alternatives, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch and decode inventory-like NBT sections for one SkyBlock profile, including wardrobe, armor, equipment, ender chest, backpacks, vault, and bags. Use filters to keep output focused.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | No | Minecraft UUID, dashed or undashed. | |
| username | No | Minecraft username. Use this when the user gives a name. | |
| profileId | No | Specific SkyBlock profile UUID. | |
| memberUuid | No | Coop member UUID to inspect. Defaults to requested player. | |
| maxSections | No | ||
| profileName | No | Cute profile name, for example Apple, Lemon, or Coconut. | |
| maxLoreLines | No | ||
| sectionPaths | No | Filter decoded inventory sections by case-insensitive path substring, for example wardrobe_contents or backpack_contents. | |
| sectionTypes | No | Filter decoded inventory sections by type. Common values: inventory, wardrobe, armor, equipment, ender_chest, backpack, accessory_bag, potion_bag, fishing_bag, quiver, personal_vault, sack, loadout, container, unknown. Omit or include all for all inventory-like sections. | |
| selectedOnly | No | Prefer the selected profile when multiple profiles exist. | |
| includeRawNbt | No | Include simplified raw NBT for decoded sections. Very large output. | |
| memberUsername | No | Coop member username to inspect. Defaults to requested player. | |
| includeRawMember | No | Include the raw selected member object. Very large output. | |
| includeAllNbtData | No | Search every base64 NBT payload on the member, not only inventory-like paths. | |
| includeItemDetails | No | Include extra compact ExtraAttributes fields on decoded items. | |
| maxItemsPerSection | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the full burden. It does not disclose any behavioral traits such as rate limits, authentication needs, potential for large responses, or side effects. The only behavioral hint is the ability to filter, but the tool's impact (e.g., API cost) is unmentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first clearly states the tool's purpose, the second gives a concise usage tip. No extraneous information; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (16 parameters, no output schema, no annotations), the description is incomplete. It fails to describe the return format, potential for large output, or any constraints. The agent lacks context to correctly handle the tool's response.
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 high (81%). The description lists section types that overlap with the schema's 'sectionTypes' parameter description, adding minimal new meaning. The baseline 3 applies as the schema already documents parameters well.
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 fetches and decodes inventory-like NBT sections for a SkyBlock profile, listing specific sections (wardrobe, armor, etc.). It distinguishes from sibling tools like skyblock_profile or decode_skyblock_nbt by focusing solely on inventory contents.
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 advises using filters to keep output focused, but does not explicitly state when to use this tool vs alternatives (e.g., skyblock_profile for general profile data). No when-not-to-use guidance or comparisons to siblings are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a single SkyBlock item by ID or name and return its official metadata (tier, category, stats, NPC price, museum/soulbound flags) plus a live value: full Bazaar buy/sell/spread/volume for Bazaar items, or a lowest-BIN price when an external source is configured, otherwise a clear auction-only note. Set includeWiki for official Hypixel SkyBlock Wiki obtaining/usage/upgrading/history context. Ambiguous searches return candidate IDs instead of guessing.
| Name | Required | Description | Default |
|---|---|---|---|
| itemId | No | Exact SkyBlock item ID, for example HYPERION or ENCHANTED_DIAMOND. | |
| search | No | Item name or substring when the exact ID is unknown. | |
| priceBasis | No | Price basis used only for the lowest-BIN fallback. | buy |
| includeWiki | No | Fetch official Hypixel SkyBlock Wiki context for the resolved item. | |
| maxCandidates | No | Max candidate IDs to return for an ambiguous search. | |
| includeBazaarOrders | No | Include top Bazaar buy/sell order summaries for Bazaar items. | |
| maxWikiSectionChars | No | Maximum characters per wiki section when includeWiki is true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of behavioral disclosure. It details that the tool returns candidate IDs for ambiguous inputs, includes Bazaar or lowest-BIN pricing conditionally, and offers optional wiki context. It does not mention potential side effects or authentication needs, but it adequately discloses core behaviors.
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 paragraph that efficiently conveys the tool's purpose, behavior, and key parameter effects. It is front-loaded with the main action and output summary, then details specifics. While not broken into sections, it is dense but clear, with no redundant sentences.
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 7 parameters, no output schema, and no annotations, the description provides enough context for an AI agent to understand the tool's capabilities and return value structure (metadata fields and live value). It misses a formal return schema but compensates with a clear summary of output contents.
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 input schema has 100% coverage, so each parameter already has a description. The tool description adds value by explaining how parameters interact (e.g., priceBasis only used for lowest-BIN fallback), the behavior of ambiguous searches, and optional features like includeBazaarOrders and includeWiki. This enhances understanding beyond the schema alone.
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 specifies a clear verb ('Look up'), resource ('SkyBlock item'), and scope ('single item by ID or name'). It distinguishes the tool from siblings by detailing its specific output (metadata, live value) and handling of ambiguous searches, making its purpose 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?
The description provides context for when the tool is appropriate (looking up item metadata and market values) and explains behavior for ambiguous searches (returning candidate IDs). It does not explicitly state when not to use it, but the context signals and sibling names imply alternatives for other tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch museum donations and value summary for a SkyBlock profile member.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | No | Minecraft UUID, dashed or undashed. | |
| username | No | Minecraft username. Use this when the user gives a name. | |
| profileId | No | Specific SkyBlock profile UUID. | |
| memberUuid | No | Coop member UUID to inspect. Defaults to requested player. | |
| profileName | No | Cute profile name, for example Apple, Lemon, or Coconut. | |
| selectedOnly | No | Prefer the selected profile when multiple profiles exist. | |
| memberUsername | No | Coop member username to inspect. Defaults to requested player. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It only states 'Fetch', implying a read operation, but lacks details on authentication, rate limits, or error scenarios (e.g., missing museum data). The behavior is under-specified.
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?
A single concise sentence that efficiently communicates the core functionality. No redundant words or unnecessary details. The structure is ideal for quick scanning.
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 7 parameters and no output schema, the description is too brief. It does not explain what the return format is, how to interpret the value summary, or how parameters like memberUuid or selectedOnly affect results. More context is needed for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a clear description. The tool description adds no extra semantic value beyond 'fetch museum donations', so it meets the baseline but does not enhance understanding of parameter usage or relationships.
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 action (fetch) and the resource (museum donations and value summary for a SkyBlock profile member). It is specific and distinguishes from siblings like skyblock_profile or skyblock_networth, but could explicitly contrast with related 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?
No guidance on when to use this tool versus alternatives such as skyblock_profile or skyblock_inventory. No prerequisites or exclusions are mentioned, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate a profile's net worth from liquid coins, decoded inventory/storage holdings, sacks, and supported item modifiers, priced with live Bazaar data (and an optional external lowest-BIN source for auction items). Returns a total, per-section breakdown, top items by value, modifier breakdown, and pricing coverage.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | No | Minecraft UUID, dashed or undashed. | |
| topItems | No | ||
| username | No | Minecraft username. Use this when the user gives a name. | |
| profileId | No | Specific SkyBlock profile UUID. | |
| memberUuid | No | Coop member UUID to inspect. Defaults to requested player. | |
| priceBasis | No | buy = market/replacement value (insta-buy), sell = liquidation value (insta-sell). | buy |
| profileName | No | Cute profile name, for example Apple, Lemon, or Coconut. | |
| includeSacks | No | ||
| selectedOnly | No | Prefer the selected profile when multiple profiles exist. | |
| memberUsername | No | Coop member username to inspect. Defaults to requested player. | |
| includeUnpriced | No | List items that could not be priced. Helps explain coverage gaps. | |
| includeModifiers | No | Add modifier value (enchantments, hot potato books, recombobulator, essence/master stars, gemstones, reforge stones) on top of base item prices. | |
| includeAuctionPrices | No | Use the configured external lowest-BIN source for auction-only items when available. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the use of live Bazaar data, optional external BIN source, and returns a breakdown. However, it does not mention rate limits, data freshness, or potential destructive actions (though none expected).
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 moderately long sentence packing much information. It could be more concise or structured (e.g., bullet points). It is front-loaded with the main purpose but could be improved for readability.
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 13 parameters and no output schema, the description covers inputs well but lacks detailed output structure. It mentions return fields (total, breakdown, top items) but not their types or formats, leaving some ambiguity for an agent.
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 85%, and remaining params have meaningful descriptions. The description adds context like 'use when user gives a name' for username. Default values and enums are well explained, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool estimates a profile's net worth from liquid coins, inventory/storage holdings, sacks, and modifiers, using live Bazaar data. It distinguishes from sibling tools like skyblock_profile or skyblock_inventory by focusing on net worth estimation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for net worth queries but lacks explicit guidance on when to use this tool versus alternatives (e.g., skyblock_profile for profile info, skyblock_bazaar for pricing). No when-not-to-use or context for differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one SkyBlock profile and return compact AI-readable member context: skills, slayers, dungeons, pets, collections, currencies, accessories, and optional decoded inventories.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | No | Minecraft UUID, dashed or undashed. | |
| username | No | Minecraft username. Use this when the user gives a name. | |
| profileId | No | Specific SkyBlock profile UUID. | |
| memberUuid | No | Coop member UUID to inspect. Defaults to requested player. | |
| profileName | No | Cute profile name, for example Apple, Lemon, or Coconut. | |
| maxLoreLines | No | ||
| selectedOnly | No | Prefer the selected profile when multiple profiles exist. | |
| includeGarden | No | Fetch garden data for the selected profile. | |
| includeMuseum | No | Fetch museum data for the selected profile. | |
| includeRawNbt | No | Include simplified raw NBT for decoded sections. Very large output. | |
| memberUsername | No | Coop member username to inspect. Defaults to requested player. | |
| includeRawMember | No | Include the raw selected member object. Large output. | |
| decodeInventories | No | Decode base64 gzipped NBT inventory sections when available. | |
| includeAllNbtData | No | Search every base64 NBT payload on the member, not only inventory-like paths. | |
| includeRawProfile | No | Include the raw selected profile object. Large output. | |
| includeItemDetails | No | Include extra compact ExtraAttributes fields on decoded items. | |
| maxInventorySections | No | ||
| maxItemsPerInventory | No | ||
| inventorySectionPaths | No | Filter decoded inventory sections by case-insensitive path substring, for example wardrobe_contents or backpack_contents. | |
| inventorySectionTypes | No | Filter decoded inventory sections by type. Common values: inventory, wardrobe, armor, equipment, ender_chest, backpack, accessory_bag, potion_bag, fishing_bag, quiver, personal_vault, sack, loadout, container, unknown. Omit or include all for all inventory-like sections. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only mentions what it returns, not safety (e.g., read-only), rate limits, or authentication requirements. The description is not contradictory but lacks necessary behavioral context.
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, front-loaded sentence that efficiently conveys the tool's core purpose and output. It avoids wordiness but could be slightly more structured with separate sentences for 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?
Despite having 20 parameters and no output schema, the description is brief and does not explain return format, error handling, or the meaning of 'compact AI-readable'. Important parameters like maxInventorySections and inventorySectionPaths lack context in the description.
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 85%, so the schema already documents most parameters. The description adds a high-level list of returned data but does not explain parameter interactions or specific effects beyond what the schema 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 clearly states it fetches one SkyBlock profile and returns compact AI-readable member context with specific categories (skills, slayers, etc.), distinguishing it from sibling tools like skyblock_profiles which likely lists multiple profiles.
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 a full profile overview but does not explicitly state when to use alternatives like skyblock_garden or skyblock_inventory. No direct comparison or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List a player's SkyBlock profiles with compact member metadata. Requires HYPIXEL_API_KEY and respects the player's API privacy settings.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | No | Minecraft UUID, dashed or undashed. | |
| username | No | Minecraft username. Use this when the user gives a name. | |
| includeRaw | No | Include raw Hypixel profile objects. Large output. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses API key requirement and privacy respect, but omits details like response format, error handling, or pagination. Behavior is partially 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?
Description is a single sentence with a necessary note, front-loaded with the main action, and contains 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?
No output schema is provided, and the description does not elaborate on what 'compact member metadata' includes or the structure of the response. For a listing tool, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds no additional meaning beyond the schema, so baseline score 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?
Description clearly states the tool lists a player's SkyBlock profiles with compact member metadata, distinguishing it from the sibling 'skyblock_profile' which likely returns a single profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions requirements (API key) and behavioral notes (respects privacy settings), but does not explicitly guide when to use this tool over alternatives like 'skyblock_profile' or other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch public SkyBlock resources: items, skills, collections, election/mayor, bingo, or news. Supports filtering for item and resource searches.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | Item IDs to fetch when kind=items. | |
| kind | Yes | ||
| tier | No | Item tier filter when kind=items. | |
| limit | No | ||
| search | No | ||
| category | No | Item category filter when kind=items. | |
| includeRaw | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states it fetches public resources and supports filtering, but does not disclose any behavioral traits like pagination, error handling, rate limits, or the fact that parameters like 'ids' and 'tier' are conditional on 'kind'. This lack of transparency could lead to 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 description is concise at two sentences, front-loading the primary action and listing resource types. Every sentence contributes, though the second sentence is somewhat vague. It avoids unnecessary 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?
Given the tool has 7 parameters, no output schema, and many siblings, the description is insufficient. It omits return format, error cases, caching behavior, and does not adequately differentiate from sibling tools. The high complexity demands more completeness than provided.
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 43% (low), so the description must compensate. It adds a general statement about filtering but does not explain parameters beyond what the schema already provides. For example, the meaning of 'kind' enum values, 'search', 'limit', and 'includeRaw' are not elaborated. The description adds minimal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches public SkyBlock resources and lists specific types (items, skills, collections, election/mayor, bingo, or news). It uses a specific verb and resource, but does not explicitly distinguish from siblings like skyblock_item or skyblock_bazaar, though the list of categories provides implicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'supports filtering for item and resource searches' but provides no explicit guidance on when to use this tool versus alternatives such as skyblock_auctions or skyblock_bazaar. No when-to-use or when-not-to-use information is included, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode and merge items across backpacks, ender chest, personal vault, sacks, bags, and inventory. Returns grouped item counts, sack totals, and optional per-section detail.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | No | Minecraft UUID, dashed or undashed. | |
| search | No | Case-insensitive search across item names and SkyBlock IDs. | |
| username | No | Minecraft username. Use this when the user gives a name. | |
| itemLimit | No | ||
| profileId | No | Specific SkyBlock profile UUID. | |
| memberUuid | No | Coop member UUID to inspect. Defaults to requested player. | |
| maxSections | No | ||
| profileName | No | Cute profile name, for example Apple, Lemon, or Coconut. | |
| skyblockIds | No | Only include these SkyBlock item IDs. | |
| sectionPaths | No | Filter decoded inventory sections by case-insensitive path substring, for example wardrobe_contents or backpack_contents. | |
| sectionTypes | No | Filter decoded inventory sections by type. Common values: inventory, wardrobe, armor, equipment, ender_chest, backpack, accessory_bag, potion_bag, fishing_bag, quiver, personal_vault, sack, loadout, container, unknown. Omit or include all for all inventory-like sections. | |
| selectedOnly | No | Prefer the selected profile when multiple profiles exist. | |
| memberUsername | No | Coop member username to inspect. Defaults to requested player. | |
| includeSections | No | Include raw decoded sections. Large output. | |
| groupBySkyblockId | No | Merge duplicate item IDs across storage locations. | |
| includeItemDetails | No | ||
| maxItemsPerSection | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. While it mentions 'decode and merge' and 'large output' for includeSections, it omits critical details: read-only vs write operations, auth requirements, rate limits, data freshness, or potential performance impact. The agent lacks key information to assess safety and constraints.
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 efficiently communicate purpose and output. Every word contributes meaning; no filler or 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?
Given 17 parameters, no output schema, and no annotations, the description is insufficient. It lacks details on return format, pagination, error handling, and how filters interact. An agent would need to infer or guess many operational aspects.
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 76%, so baseline is 3. The description adds context for a few parameters (e.g., case-insensitive search, profile selection) but doesn't detail all 17 parameters. The high-level overview helps but relies heavily on the schema for parameter meaning.
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 title 'Search SkyBlock Storage' and description clearly specify the tool's function: decoding and merging items across multiple storage locations (backpacks, ender chest, vault, etc.) and returning grouped counts. This distinguishes it from siblings like skyblock_inventory which likely focuses on a single inventory view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for aggregated storage searches but provides no explicit guidance on when to use this tool over alternatives like skyblock_inventory or skyblock_audit. No prerequisites, when-not-to-use, or contextual hints are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one official Hypixel SkyBlock Wiki page via MediaWiki query/revisions and return cleaned AI-readable section summaries. For item pages, this extracts summary, obtaining, upgrading, usage, history, and trivia when present.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | Exact wiki page title, for example Hyperion or Necron's Blade Scrolls. | |
| search | No | Fallback wiki search query when title is unknown or missing. | |
| includeRaw | No | Include raw wikitext. Large and usually unnecessary. | |
| maxSectionChars | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the return format and section extraction for items, but does not mention error handling, authentication, rate limits, or what happens if a page is not found.
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 minimal waste. The first sentence introduces the purpose and method, and the second provides a concrete example. Front-loaded and efficient.
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 clear purpose, the description lacks detail on the exact return format (e.g., JSON structure) and error scenarios. With no output schema, the agent may be uncertain about the expected response.
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 high (all parameters have descriptions). The description adds value by clarifying the interaction between 'title' and 'search' and specifying what sections are extracted for item pages, going beyond the schema definitions.
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 verb 'Fetch', the resource 'one official Hypixel SkyBlock Wiki page', and the return format 'cleaned AI-readable section summaries'. It also provides a specific example for item pages, distinguishing it from the sibling 'skyblock_wiki_search' which is for search.
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 this tool is for single pages compared to skyblock_wiki_search, but does not explicitly state when to use this versus alternatives. It mentions behavior for item pages but lacks when-not or prerequisite guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the official Hypixel SkyBlock Wiki through its MediaWiki API. Use this for item, mechanic, update, NPC, location, and guide-page discovery from first-party wiki data.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| search | Yes | Search query, for example Hyperion, Lotus Atoll, or Armor. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the tool as a search via the MediaWiki API, which implies read-only behavior. However, it does not explicitly state it is safe or discuss rate limits or side effects. Adequate but not exhaustive.
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 concise sentences, front-loaded with the main action and use cases. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters and no output schema, the description covers purpose and general usage but lacks details on the 'limit' parameter and return format (e.g., page titles, snippets). Could be more complete for a search tool.
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 50% (only 'search' has a description). The tool description does not explain the 'limit' parameter or its default/range. With low schema coverage, the description should compensate but does not add any parameter details.
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 searches the Hypixel SkyBlock Wiki via its MediaWiki API, and lists specific use cases (item, mechanic, update, NPC, location, guide-page discovery). It distinguishes from sibling 'skyblock_wiki_page' which likely retrieves a single page.
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 says 'Use this for... discovery,' implying it's for searching rather than retrieving a specific page, but it does not explicitly state when not to use it or mention alternatives like 'skyblock_wiki_page' for direct page access.
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.
v1.0.4skyblock_item2 fields changedInput schema / properties / includeWikiAdded value: +{
+ "default": false,
+ "description": "Fetch official Hypixel SkyBlock Wiki context for the resolved item.",
+ "type": "boolean"
+}Input schema / properties / maxWikiSectionCharsAdded value: +{
+ "default": 900,
+ "description": "Maximum characters per wiki section when includeWiki is true.",
+ "maximum": 2500,
+ "minimum": 200,
+ "type": "integer"
+}skyblock_networth1 field changedInput schema / properties / includeModifiers / descriptionPrevious value: -"Add modifier value (enchantments, hot potato books, recombobulator, essence/master stars) on top of base item prices."New value: +"Add modifier value (enchantments, hot potato books, recombobulator, essence/master stars, gemstones, reforge stones) on top of base item prices."skyblock_wiki_pageskyblock_wiki_searchv1.0.1cache_cleardecode_skyblock_nbthypixel_playerresolve_playerskyblock_auctionsskyblock_auditskyblock_bazaarskyblock_essence_costsskyblock_gardenskyblock_guide_contextskyblock_inventoryskyblock_itemskyblock_museumskyblock_networthskyblock_profileskyblock_profilesskyblock_resourceskyblock_storageEach tool has a clearly defined purpose with no overlap. Even similar-sounding tools like skyblock_profile, skyblock_profiles, and skyblock_audit are differentiated by their descriptions and output focus.
Tools follow a consistent verb_noun pattern in snake_case, with most domain-specific tools prefixed with 'skyblock_'. Helper tools use distinct prefixes (hypixel_, resolve_, cache_, decode_) that clearly indicate their function.
With 20 tools, the server covers a wide range of SkyBlock functionalities without being overwhelming. While slightly above the typical well-scoped range (3-15), each tool serves a distinct purpose and the count is appropriate for the game's complexity.
The tool set covers nearly all major aspects of Hypixel SkyBlock: player profiles, inventories, auctions, bazaar, items, wiki, garden, museum, net worth, and more. Only minor features like minion management are absent, but core progression support is fully present.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
One AI endpoint to search and call 22k+ MCP servers; 50+ hosted tools work instantly, no key.
Pre-computed market data that improves agent reasoning, reduces token usage, and replaces pipelines.
Savecraft serves real save game data and expert game knowledge to AI assistants.
Blockchain analytics API for AI agents. Smart Money signals, wallet profiling, token analytics.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/crithitstudio/hypixel-skyblock-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
