nomad-mcp

by udaisingh93

Overview Schema Related Servers Score Discussions

JavaScript

Local

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 resource and action: list vs get for jobs, allocations, nodes, deployments, and namespaces. The nested resources (allocations, deployments, evaluations) are clearly separated per job, with no overlapping purposes.
Naming Consistency5/5
All tool names follow a strict verb_noun pattern (list_* for collections, get_* for single items), with nested resources denoted by get_<resource>_<child>. Consistently lowercase with underscores.
Tool Count5/5
12 tools is well within the ideal range for a domain-specific server. Each tool covers a meaningful aspect of Nomad inspection (jobs, allocations, nodes, deployments, namespaces), and none feel redundant.
Completeness4/5
The toolset provides comprehensive read-only coverage for inspecting Nomad workloads, allocations, logs, deployments, and nodes. Minor gaps exist (e.g., no cluster-wide allocation list, no job version history), but core diagnostic workflows are fully supported.
Average 3.2/5 across 11 of 12 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavior. It only says 'Get details', which merely restates the tool's function. It doesn't describe error handling, return format, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it provides minimal information and essentially paraphrases the tool name. It is under-specified rather than concise and useful.
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?
For a simple get-by-id tool, the description leaves out key contextual information such as how the ID relates to other tools (e.g., returned by list_deployments) or what the response contains. It is not complete enough given the lack of annotations and output schema.
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 schema has one required 'id' parameter with no description, and the description does not mention it at all. With 0% schema description coverage, the description needed to explain how to identify the deployment, but it doesn't.
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 retrieves details for one deployment, using the verb 'Get' and resource 'deployment'. The word 'single' distinguishes it from sibling tools like list_deployments, though it doesn't explicitly name alternatives.
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 list_deployments or get_job_deployments. The intended use case must be inferred from the tool name and description.
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, but it only states 'List recent deployments' without explaining what 'recent' means, whether the output is ordered or paginated, or what the optional namespace parameter does. This leaves the agent unaware of the full operational semantics.
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, short sentence with no filler words, which is concise. However, it is too sparse and omits important details like the namespace filter and the meaning of 'recent', making it under-specified rather than effectively concise.
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?
The tool is relatively simple with one optional parameter and no output schema or annotations, but the description is incomplete. It fails to explain the namespace parameter, the notion of 'recent', or return characteristics, leaving the agent unable to make a fully informed decision about invocation.
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 one optional parameter 'namespace' with a type of string, but the description offers no explanation of this parameter. Since schema description coverage is 0%, the description should have compensated by mentioning that the namespace filter is supported, but it does not, providing zero added meaning.
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 uses the specific verb 'List' and resource 'deployments' with scope 'across the cluster', making the core purpose clear. It is distinguishable from siblings like get_deployment (single deployment) and get_job_deployments (deployments for a specific job), though the term 'recent' is vague and doesn't fully specify whether it includes all or a filtered subset.
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 such as list_jobs or get_job_deployments. There is no mention of context, prerequisites, or exclusions, leaving the agent without direction for tool selection.
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 bears full responsibility for behavioral disclosure. It only states the basic listing action and omits critical details like pagination, permissions, response format, or whether the namespace is required. This is a significant gap for a tool relying solely on its description.
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 no redundant words. While it is appropriately sized for a simple action, it underspecifies key details, but as a conciseness measure it efficiently communicates the core purpose.
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?
For a tool with no annotations, no output schema, and zero parameter coverage, this description is incomplete. It fails to explain return values, parameter semantics, or any use-case context, making it insufficient for an agent to reliably invoke the tool correctly.
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?
Schema description coverage is 0%, and the description adds no explanation for the 'id' or 'namespace' parameters. It does not clarify that 'id' likely refers to a job ID, nor does it specify how 'namespace' affects the query. The description provides no value beyond the raw parameter names in 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 uses a specific verb ('List') and resource ('deployments') with a clear scope ('for a job'), distinguishing it from general deployment tools like list_deployments and get_deployment. It could be more explicit about the id referring to a job ID, but the tool name and schema reinforce this correctly.
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 about when to use this tool versus the related sibling tools such as list_deployments or get_deployment. The description does not state any context, prerequisites, or alternatives, leaving the agent without decision support.
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 carries the full burden of behavioral disclosure. It indicates a read operation ('Get details') and hints at return content ('including task states and events'), but it does not disclose potential side effects, permissions required, rate limits, error conditions, or pagination behavior. For a tool that likely performs a simple retrieval, the description 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?
The description is a single sentence that is concise, front-loaded, and contains no extraneous information. Every word contributes to the purpose ('Get details of a single allocation, including task states and events'). This is appropriately sized for a simple tool.
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 low complexity (one parameter, no output schema, no annotations), the description is minimally adequate: it names the resource and indicates the type of details included. However, it lacks contextual completeness because it does not explain when to use this tool over sibling tools (e.g., get_allocation_logs) or provide any caveats. The absence of any behavioral or usage notes leaves gaps for an agent making tool-selection decisions.
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 schema has one parameter 'id' (string, required) with no description, and the schema description coverage is 0%. The tool description does not mention the parameter or provide any additional meaning, such as the format of the ID, how to obtain it, or any constraints. The parameter name alone is insufficient, especially since the description lacks any parameter-specific information.
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: 'Get details of a single allocation, including task states and events.' It uses a specific verb ('Get') and identifies the resource ('a single allocation'), and the mention of 'task states and events' distinguishes it from sibling tools like get_allocation_logs (which focuses on logs) or list_job_allocations (which lists multiple allocations).
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 does not provide any explicit usage guidance, such as when to use this tool versus alternatives (e.g., get_allocation_logs vs get_allocation). There is no mention of prerequisites, typical use cases, or exclusions. The only hint is that it retrieves a single allocation, which is implied by the name, but no direct comparison or decision framework is offered.
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?
There are no annotations, so the description must disclose behavior. It only restates the basic function without mentioning return shape, error handling, or side effects. For a read-only list, this is minimal coverage.
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, free of fluff and front-loaded. However, it omits necessary parameter context, making it slightly under-specified, but structurally efficient.
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 a 2-parameter tool with no schema descriptions, no output schema, and no annotations, this description leaves significant gaps around parameter semantics and usage. It is adequate for purpose but not fully contextual.
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?
Schema description coverage is 0%, and the description does not explain the 'id' or 'namespace' parameters. It is unclear whether 'id' refers to the job ID, and 'namespace' is entirely unexplained.
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 ('List') and resource ('allocations') scoped by 'belonging to a job.' This distinguishes it from singular 'get_allocation' and other list_* tools.
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 you need allocations for a specific job, but it does not explicitly mention alternatives or exclusions. Sibling tools like 'get_allocation' could serve as alternatives for single allocation, but no guidance 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 'recent' and 'stdout/stderr' but doesn't disclose behavioral details like the meaning of 'recent', how much data is returned, whether it's a read-only operation, or what the response format is. This is a significant gap for a tool with no annotation coverage.
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 front-loads the verb and resource. 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain return values, limits, and behavioral nuances. It doesn't explain tailBytes, what 'recent' means, or what the response looks like. For a 4-parameter tool, this is incomplete.
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 only 25% (only 'task' is described). The tool description mentions 'stdout/stderr' (matching the type enum) and 'task in an allocation' (matching allocId/task) but doesn't explain tailBytes or the default behavior. It adds minimal 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 uses a specific verb 'Fetch' and clearly identifies the resource: 'recent stdout/stderr log output for a task in an allocation.' This distinguishes it from sibling tools like get_allocation, which fetches allocation details rather than logs.
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 clearly indicates the tool's context: fetching logs for a task within an allocation. While it doesn't explicitly name alternatives or exclusions, the narrow scope makes the use case obvious, and no prerequisites or conflicting tools are implied.
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 are provided, so the description must carry the full burden. It does disclose that the response includes 'allocations and resource usage', adding value beyond a generic 'get'. However, it does not mention error behavior (e.g., 404 for unknown node ID), authorization requirements, or other operational traits. This is acceptable for a simple read but not fully 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?
The description is a single short sentence, highly concise and front-loaded with 'Get details'. It contains no filler or redundant information, 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?
The tool has only one parameter and no output schema, so the description needs to cover the essentials. It explains the basic purpose and hints at return content, but fails to clarify the 'id' parameter, which is fundamental. Without that, the description is incomplete for an agent attempting to invoke the tool correctly.
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 schema has one required parameter 'id' with no description, and schema description coverage is 0%. The description does not mention the parameter at all, leaving it unclear whether the ID is a node ID, allocation ID, or something else. This is a critical gap since the description should compensate for the missing schema documentation.
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 'Get' and clearly identifies the resource: 'a single Nomad client node'. It also specifies the included details ('allocations and resource usage'), which distinguishes it from sibling tools like list_nodes (for listing nodes) and get_allocation (for individual allocations).
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 the tool is for retrieving details of one specific node, which differentiates it from list_nodes (list all nodes). However, it does not explicitly mention when not to use it or name alternatives, so it falls short of a full 5. The context is clear but not exhaustive.
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, and the description only repeats the tool name with the addition of 'Nomad'. It does not disclose any behavioral details such as whether the list is paginated, returns all namespaces, or requires specific permissions. The read-only nature is implied by 'List' but not elaborated.
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 sentence with minimal words: 'List Nomad namespaces.' It is front-loaded with the action and includes no fluff. Every word earns its place.
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?
For a zero-parameter list operation with no output schema, the description is adequate but not thorough. It does not mention the shape of the returned data, potential empty results, or any API-specific details. While the tool is simple, a bit more context about the response would make it complete.
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 no parameters, and the input schema is an empty object with 100% schema coverage. Since there are zero parameters, the description is not required to explain them, and the baseline score of 4 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?
The description uses the verb 'List' and identifies the resource as 'Nomad namespaces', which is a distinct resource from sibling tools such as list_jobs, get_node, and list_deployments. This makes the tool's purpose immediately clear and differentiates it from 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?
The description provides no guidance on when to use this tool versus the sibling tools. There are no explicit mentions of conditions, exclusions, or alternative tools for similar operations, so an agent gets no directional help for selection.
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 of disclosing behavioral traits. It only restates the filter parameters without explaining critical behaviors like which namespace is used when none is specified, whether results are paginated, or what the response shape is. This is insufficient for a read operation with no other safety/behavior metadata.
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 directly states the tool's purpose and key parameters without redundancy or filler. Every word contributes to the understanding.
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 absence of annotations and output schema, the description is incomplete for correct invocation. It fails to mention default namespace semantics, pagination, or the structure of the returned job list, which are important contextual details for an AI agent reasoning about the tool.
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?
With 0% schema description coverage, the description clarifies that 'prefix' refers to job name prefix and 'namespace' is a namespace filter, which adds some meaning beyond bare parameter names. However, it lacks detail on matching semantics (e.g., exact match vs prefix) and default namespace behavior, so it only partially compensates for the missing schema descriptions.
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 unambiguously states the action ('List') and resource ('Nomad jobs'), and mentions optional filters (name prefix and namespace). This clearly distinguishes it from sibling tools like get_job, which fetches a single job, and other job-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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for enumerating jobs, and the optional filter context is given. However, it doesn't explicitly contrast with alternatives (e.g., 'use get_job for a specific job'), so it lacks explicit exclusions despite having clear 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?
Without any annotations, the description must convey behavioral traits. It merely says 'List client nodes' without disclosing whether the operation is read-only, the response format, or any potential side effects. This is a significant gap for a tool with no safety annotations.
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 immediately conveys the core functionality. It wastes no 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 is simple with no parameters and no output schema, so the minimal description covers the basic purpose. However, it does not clarify the relationship with get_node or list_jobs, which slightly reduces completeness. Given the low complexity, this is acceptable.
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 to explain. The baseline score of 4 applies, and the description does not need to add 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 action (List), the resource (client nodes), and the domain (Nomad cluster). It distinguishes from sibling tools like list_jobs and get_node by specifying 'client 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?
The description provides no guidance on when to use this tool versus alternatives such as get_node for individual node details or list_jobs for job listings. There is no explicit or implicit usage context beyond the basic listing operation.
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 carry behavioral disclosure. It states what is returned ('full spec and status') but does not mention potential 404s, namespace defaulting behavior, permissions required, or any side effects. This is minimal transparency for a read operation.
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, front-loaded sentence with no filler. Every word contributes to identifying the tool's purpose.
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 get-by-ID tool with no output schema, the description adequately states the scope ('full spec and status') and distinguishes it from sibling resource-specific getters. It could add a note about namespace or error behavior, but the core selection information is present.
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% and the description only references 'by ID,' adding meaning for the required id parameter but leaving the optional namespace parameter completely unexplained. With two parameters, the description should compensate for the schema gap, but it does not address namespace.
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 'Get' and names the exact resource: 'full spec and status of a single Nomad job by ID.' It clearly differentiates from siblings like list_jobs (plural/list) and get_job_allocations (nested resource).
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 phrase 'single Nomad job by ID' implies the tool should be used when the agent already has a job ID and needs the job's spec/status, contrasting with list_jobs for enumeration. It does not explicitly mention exclusions or alternatives, but the usage context is fairly clear.
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 are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only operation but does not detail permissions, return format, or potential side effects. The diagnostic note adds minimal behavioral context beyond the purpose.
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, front-loaded with the core action and a practical use case. Every word contributes to understanding, with no redundancy or filler.
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?
For a simple list tool, the description covers purpose and context, but gaps remain: no parameter semantics, no output format, no notes on ordering or limits. It's adequate for selection but not fully self-contained.
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%, and the description only loosely implies that 'id' refers to a job. It does not explain the 'namespace' parameter or any constraints. The description fails to compensate for the lack of schema descriptions.
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 ('List') and resource ('evaluations for a job'), clearly distinguishing it from sibling tools like get_job_allocations or get_job_deployments. The added use case ('useful for diagnosing why a job isn't placing') further clarifies intent.
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 a clear context for when to use the tool: diagnosing placement issues. It doesn't explicitly mention alternatives or exclusions, but the stated use case is strong enough to guide selection among sibling tools.
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:

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

Score Badge

Copy to your README.md:

[![nomad-mcp MCP server](https://glama.ai/mcp/servers/udaisingh93/nomad-mcp/badges/score.svg)](https://glama.ai/mcp/servers/udaisingh93/nomad-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/udaisingh93/nomad-mcp'

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