A Model Context Protocol (MCP) server for interacting with HashiCorp Nomad, enabling job management, deployment management, namespace management, node management, allocation management, variable management, volume management, and ACL management.
The Nomad MCP server presents 48 well-organized tools with consistent naming conventions (verb_noun pattern across all tools: list_, get_, create_, delete_, run_, scale_, drain_, set_, stop_, bootstrap_). Tool descriptions are present for all tools and range from adequate to good (average ~80-120 chars, within the 10-1024 char baseline). Input schemas are visible and properly typed across all tools, with parameter descriptions present. However, output schemas are not documented, the server provides no schema documentation for what each tool returns, which is a critical gap for LLM planning. Error handling descriptions are minimal; most tools lack guidance on what to do if a call fails or what conditions trigger errors. Security-sensitive operations (delete, stop, purge) lack dry-run or confirmation patterns. Parameter descriptions are functional but sometimes terse (e.g., 'The job ID to stop' vs 'The Nomad job ID (unique per namespace) to stop').
Bootstrap ACL system in Nomad (only works when ACL is disabled)
Create a new ACL policy
Create a new ACL role
Create a new ACL token
Create a new namespace in Nomad
Create or update a Sentinel policy
Create or update a Nomad variable
Delete an ACL policy
Output schemas not documented. Tools return data structures, but LLMs have no visibility into what fields are returned. This prevents agents from chaining tools (e.g., knowing what fields create_job returns to pass to downstream tools) and forces LLMs to guess at response structure.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 51 | - | v1 |
Delete an ACL role
Delete an ACL token
Delete a namespace from Nomad
Delete a Sentinel policy
Delete a Nomad variable
Delete a volume from Nomad
Enable or disable drain mode on a Nomad node
Get details about a specific ACL policy
Get details about a specific ACL role
Get details about a specific ACL token
Get detailed information about a specific allocation
Get logs from a running allocation task
Get detailed information about a specific deployment
Get detailed information about a specific Nomad job
Get summary statistics for a job
Get version history for a job
Get detailed information about a specific Nomad node
Get details about a specific Sentinel policy
Get a specific Nomad variable
Get details about a specific volume
List all ACL policies in Nomad
List all ACL roles in Nomad
List all ACL tokens in Nomad
List allocations for a job in a namespace
List cluster peers and regions in Nomad
List all deployments in Nomad, optionally filtered by namespace
List deployments for a job
List evaluations for a job
List services exposed by a job
List all jobs in Nomad, optionally filtered by namespace and status
List all namespaces in Nomad
List all nodes in the Nomad cluster, optionally filtered by status
List Sentinel policies in Nomad
List Nomad variables in a namespace, optionally filtered by path prefix
List CSI or host volumes in Nomad, optionally filtered by node or plugin
Run a new job in Nomad from a HCL job specification
Scale a job's task group to a specific count
Set a node's job eligibility status
Stop a running allocation
Stop a running Nomad job
Destructive operations lack dry-run or confirmation patterns. Tools like stop_job, delete_namespace, delete_volume, delete_acl_token, delete_acl_policy, delete_acl_role, delete_sentinel_policy, and stop_allocation can permanently destroy resources, but there is no way for agents to preview consequences or request user confirmation before executing.
Error handling and recovery guidance missing. Tool descriptions do not explain what errors can occur, how to interpret them, or what the agent should do (retry, ask user, give up). Examples: 'If job not found, call list_jobs() to verify it exists' or 'Namespace deletion fails if jobs still exist, stop all jobs first.'
Parameter constraint documentation is sparse. Many enum-like parameters (e.g., status in list_jobs, log_type in get_allocation_logs, enforcement_level in create_sentinel_policy) have examples in descriptions but no formal enum constraints. LLMs may hallucinate invalid values.
Delete operation descriptions lack detail. Tools like delete_namespace, delete_variable, delete_volume, delete_acl_token, delete_acl_policy, delete_acl_role, and delete_sentinel_policy have minimal descriptions (40-60 chars) that don't explain consequences or prerequisites. 'Delete a namespace from Nomad' doesn't tell the agent if the namespace must be empty first or if active jobs block deletion.
ACL and Sentinel tool descriptions are generic. Tools like create_acl_policy, get_acl_role, create_sentinel_policy lack guidance on when to use them relative to each other or what typical workflows look like. Descriptions like 'Create a new ACL policy' don't help the agent understand policy vs role vs token distinctions.
set_node_eligibility parameter description is unclear. The 'eligible' parameter description says 'Set to true or false' but the input schema shows type string, not boolean. This mismatch will cause LLM confusion about whether to pass a string ('true'/'false') or a boolean (true/false).
Pagination support not fully documented. Tools like list_jobs, list_allocations, list_variables, and list_volumes accept per_page/next_token parameters, but descriptions don't explain pagination semantics (e.g., 'Call again with next_token from prior response to fetch next batch') or the maximum page size limits that might apply.