hypixel-skyblock-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.5
Disambiguation5/5
Each 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.
Naming Consistency5/5
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.
Tool Count4/5
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.
Completeness5/5
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.
Average 3.5/5 across 20 of 20 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- Last stable release on June 28, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
Tools from this server were used 2 times in the last 30 days.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness3/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![hypixel-skyblock-mcp MCP server](https://glama.ai/mcp/servers/crithitstudio/hypixel-skyblock-mcp/badges/card.svg)](https://glama.ai/mcp/servers/crithitstudio/hypixel-skyblock-mcp)

Score Badge

Copy to your README.md:

[![hypixel-skyblock-mcp MCP server](https://glama.ai/mcp/servers/crithitstudio/hypixel-skyblock-mcp/badges/score.svg)](https://glama.ai/mcp/servers/crithitstudio/hypixel-skyblock-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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