YuniKorn MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct domain entity: partitions, partition queues, applications, individual application details, nodes, user usage, and scheduler health. There is no overlap in purpose, making selection unambiguous.
Naming Consistency5/5
All tool names follow a clear verb_noun pattern (get_partitions, get_partition_queues, get_applications_by_state, inspect_application, get_node_details, get_user_usage, check_scheduler_health). The pattern is consistent and predictable.
Tool Count5/5
With 7 tools, the server is well-scoped for its purpose of monitoring and querying a YuniKorn cluster. Each tool covers a necessary aspect without unnecessary bloat.
Completeness4/5
The tool set covers the core query surfaces: partitions, queues, applications, nodes, user usage, and health. Minor gaps exist (e.g., no scheduler configuration or historical metrics retrieval), but the primary workflows are fully supported.
Average 4.1/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 28, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It prominently discloses that resource values are raw integers (bytes, millicores) and instructs conversion, which is critical for correct interpretation of results. This goes beyond simple read-only intent, though it omits details like error conditions or permission requirements.
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, each earns its place. The first states the tool's purpose, and the second delivers a high-value conversion warning. No filler or redundant repetition of schema details.
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?
The output schema covers return structure, and the description supplies the missing unit semantics. For a simple read-only usage tool, this is sufficient context; the only gap is the lack of explicit usage guidance, already scored separately.
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 0%, so description must compensate. It clarifies that the optional userName parameter can target a specific user or omit to get all users, which maps directly to the schema's default-null userName. However, it does not explain partitionName beyond the schema title, leaving partial ambiguity.
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 uses a specific verb ('Retrieves') and resource ('resource usage and quota information') with clear scope ('all users or a specific user'). This clearly distinguishes it from sibling tools focused on partitions, queues, applications, nodes, and health.
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 siblings, no explicit exclusions, and no prerequisites are stated. The description implies a query tool but does not help the agent decide between it and related tools.
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 the burden of behavioral disclosure. It adds valuable context about raw integer units (bytes, millicores) and the need to convert them, which is beyond what the schema provides. However, it omits error cases, pagination, and permission requirements.
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: a clear purpose statement plus an important note about value formatting. No filler, front-loaded, and every sentence adds value.
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?
The tool has a simple parameter set and an output schema, so the description doesn't need to detail return structure. However, it lacks explicit usage guidance and leaves partitionName semantics unclear. The raw integer note adds useful context, making the description adequate but not comprehensive.
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 0%, but the description partially explains that nodeId is optional ('all nodes or a specific node') and clarifies output unit semantics. It does not explicitly explain partitionName, which is required and left undocumented by 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 fetches nodes (all or specific) managed by YuniKorn, including capacity and utilization. This distinguishes it from sibling tools like get_partitions or get_applications_by_state, which target different resources.
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 when to use the tool (when node-level resource details are needed) but does not explicitly compare with alternatives or state exclusions. No direct guidance is provided about when other tools would be preferred.
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?
No annotations are provided, so the description must carry the behavioral disclosure burden. It does well by explaining the uuid/allocationID relationship and the raw integer representation of resources, which are non-obvious and critical for correct interpretation. It does not mention side effects or auth, but this is clearly a read-only introspection tool.
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 compact and well-structured: it leads with the core purpose, then provides the essential field-variant note, and ends with a clear conversion warning. Every sentence adds value, and there is no redundant or filler content.
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?
An output schema exists, so the description does not need to enumerate return fields. It covers the most crucial contextual quirks (allocation identifiers and unit conversions) that would trip up an agent. The only minor gap is not giving a hint about the partitionName parameter's role, but the name itself is fairly meaningful.
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?
The schema provides no parameter descriptions (0% coverage), and the tool description does not elaborate on `appId` or `partitionName`. While the names are self-explanatory, there is no guidance on how they relate to the returned metadata or any format expectations (e.g., is appId the UUID?). The description does not bridge the schema coverage gap.
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 function: 'Provides detailed metadata for a single application, including its allocation log and resource requests.' This is a specific verb-resource pair and distinguishes from sibling tools that list or summarize many applications (e.g., get_applications_by_state).
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?
Usage is implied by the phrase 'for a single application'—it is the tool to call when deep metadata on one application is needed. However, there is no explicit when-to-use vs alternatives, no exclusions, and no mention of when not to use it.
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 the transparency burden. It discloses that the tool checks for critical logs and negative resource values, and importantly warns that resource values are raw integers (bytes/millicores) and should be converted. This adds meaningful behavioral context beyond a simple 'get health' statement.
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, front-loaded with the main purpose, and the second sentence provides a critical unit-conversion warning. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and the output schema exists to describe return values, the description is sufficient: it states the purpose, what is checked, and a key formatting caveat. This is complete for a simple health-check tool.
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 tool has zero parameters, so the baseline is 4. There is no parameter information needed, and the description appropriately adds no irrelevant 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 returns scheduler health status and specifies what it checks (critical logs and negative resource values). This distinguishes it from sibling tools that focus on partitions, applications, and nodes.
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. The note about raw integers is about interpreting output, not about tool selection, so it does not address usage context.
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 the transparency burden. It discloses the virtual state mapping (active includes New, Accepted, Running, Completing, Failing), the default status (running), and importantly warns that resource values are raw integers (bytes/millicores) and need conversion. This is valuable beyond the schema, though it omits details like pagination or error cases.
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 three sentences, front-loaded with the core purpose, and every sentence adds essential information (purpose, virtual state/status nuance, and unit conversion warning). No wasted words.
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?
The tool has an output schema, so return value structure need not be in the description. The description covers the core lifecycle state filtering, the status sub-filter, and the critical unit conversion, making it mostly complete. Minor gaps include not explaining partitionName and not addressing potential large result sets or ordering.
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 0%, so the description must compensate. It clearly explains the 'state' values, the 'status' options for active state, and the default status, but it does not explain 'partitionName' at all, which is a required parameter. This is a significant gap for a parameter that must be provided.
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 opens with 'Retrieves applications filtered by their current lifecycle state', which is a specific verb+resource+scope. It clearly distinguishes this tool from sibling tools (get_partitions, inspect_application, etc.) by focusing on applications by state, and enumerates the exact states (active, rejected, completed) and the virtual state composition.
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 clear context on when to use the tool (to retrieve applications by lifecycle state) and explains the optional status narrowing for the active state, but it does not explicitly mention alternatives or when not to use it. It gives context but no exclusions.
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?
Since no annotations are provided, the description carries the full burden. It adds key behavioral insight by stating that resource values are raw integers (bytes for memory, millicores for CPU) and that they must be converted to human-readable formats before presentation. It also discloses exactly which resource fields are included.
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 and front-loaded: two sentences pack the purpose, included fields, and an important conversion caveat with no redundancy or filler.
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 the tool's simplicity (one required parameter) and the presence of an output schema, the description sufficiently covers what the tool does, key return fields, and a critical usage caveat. Minor aspects like exact hierarchy format are left unspecified, but overall it is complete enough for a reliable agent to use.
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?
The schema provides no descriptions (0% coverage), so the description must compensate. It identifies that the partitionName parameter refers to 'a specific partition,' but it does not elaborate on the parameter's format, possible values, or how to derive them. The contribution is minimal but non-zero.
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 action: 'Fetches the full queue hierarchy for a specific partition.' This specifies the resource (queue hierarchy) and the scope (partition), distinguishing it from sibling tools like get_partitions or get_applications_by_state.
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 effectively conveys when to use this tool: when needing queue hierarchy and resource details for a specific partition. It does not explicitly mention alternatives or exclusions, but the context is strong enough to guide selection.
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 carries the full burden of behavioral disclosure. It discloses a key behavioral trait: resource values are returned as raw integers (bytes/millicores) and must be converted to human-readable formats. This is valuable beyond the basic read operation implied by 'Retrieves.' It does not mention permissions or side effects, but for a read-only tool the provided detail is substantial.
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, front-loaded with the purpose and followed by the critical unit-conversion note. Every sentence earns its place with no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema exists, and sibling tools give surrounding context, the description is sufficiently complete. It covers what the tool returns, its scope, and an essential caveat about raw units, so the agent has enough information to use it correctly.
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, which yields a baseline of 4. The description adds no parameter-specific information because none exist, but it does clarify that the tool covers 'all partitions' and the type of data retrieved, which still aids understanding.
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 states a specific verb ('Retrieves') and resource ('partitions in the cluster'), and clarifies the scope ('all partitions'). It also lists the kind of information (total cluster capacity, used capacity, node counts), which distinguishes it from sibling tools like get_partition_queues that focus on queues rather than partitions.
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 gives clear context for when to use the tool: 'Useful for seeing total cluster capacity, used capacity, and node counts.' It implies the tool is for cluster-level statistics but does not explicitly mention alternatives or when not to use it, so it just misses the top score.
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:

[![yunikorn-mcp-server MCP server](https://glama.ai/mcp/servers/frenoid/yunikorn-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/frenoid/yunikorn-mcp-server)

Score Badge

Copy to your README.md:

[![yunikorn-mcp-server MCP server](https://glama.ai/mcp/servers/frenoid/yunikorn-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/frenoid/yunikorn-mcp-server)

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/frenoid/yunikorn-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server