jobd

Server Quality Checklist

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

Latest release: v0.5.37
Disambiguation5/5
Each tool targets a distinct operation: submitting, checking status, cancelling, tailing logs, preempting, listing, viewing events, checking workers, deleting workers. No two tools have overlapping purposes.
Naming Consistency5/5
All tools follow the consistent pattern 'jobd_<verb-or-noun>', using lowercase with underscores. The naming is predictable and uniform.
Tool Count5/5
With 9 tools, the server is well-scoped for a job broker. Each tool serves a clear purpose without unnecessary bloat or missing essentials.
Completeness5/5
The tool set covers the full job lifecycle (submit, status, cancel, preempt, logs, list) plus debugging events and worker management. No obvious gaps for its domain.
Average 4.3/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 199 commits in the last 12 weeks
- Last stable release on August 7, 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.
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.
This repository includes a glama.json configuration file.
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?
Discloses state transitions and mechanism (SIGTERM via worker signal poll) with approximate delay (~2s). Lacks details on idempotency, permissions, or side effects, but is informative for a cancel action.
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 essential information, no waste. Efficient and to the point.
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?
Tool is simple with two parameters and no output schema. Description covers behavior well but omits parameter semantics, leaving a gap in completeness.
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 coverage is 0% and description provides no parameter details. Agent must infer job_id and reason without any format or constraint 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?
Description clearly states verb 'Cancel a job' and resource 'job', and specifies behavior for different states (queued vs running) with mechanism (SIGTERM). Distinguishes from siblings like jobd_preempt or jobd_status.
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 when-to-use or when-not-to-use guidance. Implies cancellation but does not differentiate from jobd_preempt or mention when to use one over the other.
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?
Discloses that default is async and wait blocks, with server clamping timeout. With no annotations, the description bears full burden but omits many behavioral traits (e.g., dry-run mode, array/sweep behavior, authorization, rate limits). The provided information is accurate and useful, but incomplete for a complex submission 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?
Two sentences that front-load the purpose and key behavior. No unnecessary words. Each sentence earns its place: first defines the tool, second explains the critical async/sync distinction.
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 the tool's complexity (10 parameters, nested objects, no output schema), the description does not cover many important aspects like array jobs, sweep, dry-run, or response structure. Agents may need to infer or consult schema for full context. The sibling tools are listed but not explicitly differentiated.
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 detailed descriptions. The tool description adds context for the wait parameter (default async, timeout clamping) but otherwise does not add new meaning beyond the schema. Baseline is 3 due to 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?
Clearly states the tool submits a job to the jobd broker. The description differentiates from sibling tools (jobd_status, jobd_logs, jobd_cancel) by focusing on submission. Includes key behavior (default async, optional wait) which adds specificity beyond a generic verb+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?
Provides explicit guidance on when to use the wait parameter and its timeout behavior. However, does not explicitly state when not to use this tool or compare to alternatives (though siblings are distinct by purpose). The description implies usage through the async/sync distinction, making it clear for common cases.
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. It discloses that wait=true blocks until terminal and that the timeout is server-clamped to 270s. However, it does not mention error handling, authentication needs, or whether the operation is read-only (implied but not explicit).
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 front-loads the record contents, then provides usage guidance, then wait behavior. It is reasonably concise with no wasted words, though it could be slightly tighter.
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 has 3 parameters and no output schema, the description adequately covers the purpose, parameter behaviors, and usage context. It does not describe return format but lists the fields included in the record, which suffices.
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 only 33% (only wait_timeout_s has a schema description). The description adds meaning by explaining the wait parameter (block until terminal) and that wait_timeout_s is clamped to 270. job_id is straightforward but not elaborated. Thus, the description adds significant value beyond the sparse 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 it returns the full JobInfo record for a job_id and lists specific fields (state, exit_code, timings, host, scheduling internals). It distinguishes itself from sibling tools like jobd_submit, jobd_logs, and jobd_cancel by focusing on status and debugging.
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 explicitly says 'Use for a quick state check AND for debugging why a job routed/failed/stalled.' It also mentions optional wait behavior. However, it does not explicitly state when not to use this tool (e.g., preferring jobd_logs for logs), but the context is clear.
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?
Without annotations, the description fully covers behavioral traits: it states the action is destructive, documents the 409 conflict condition, and explains the reason. Missing details about success response or side effects, but sufficient for a simple 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?
Two sentences: first states the action, second explains a critical caveat and remediation. No wasted words, effectively structured.
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 one-parameter tool with no output schema, the description covers purpose, failure mode, and user action. It lacks details on success response or authentication, but overall adequate.
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 the host parameter described as 'Worker host identifier.' The description does not add further semantic value beyond the schema, meeting the baseline expectation.
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 'Remove a worker from the broker registry' with a specific verb and resource. It distinguishes itself from sibling tools like jobd_workers (which likely lists workers) by focusing on deletion.
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 explains that deletion fails with 409 if the worker is online and advises either stopping the worker process or waiting for the heartbeat sweeper. This provides clear usage context, though it does not explicitly compare with other 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?
Discloses that it returns log_tail with configurable tail_bytes (default 8 KiB, max 1 MiB) plus metadata fields, and works for both running and finished jobs. No annotations exist, so the description carries full burden and does so well.
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?
Two sentences, first contains main action and context, second details use cases. Efficient with no wasted words, though the second sentence is slightly dense.
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?
Despite no output schema, the description enumerates return fields (log_tail, size_bytes, returned_bytes, truncated). Covers behavior for running/finished jobs and mentions tail size limits. Sufficiently complete for a log-reading 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?
Schema coverage is 100%, so baseline is 3. Description adds semantic guidance: for job_id, it specifies 'numeric'; for tail_bytes, it explains purpose and provides usage advice ('Raise for context, lower for a quick liveness peek').
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 tails captured stdout/stderr of a job, specifying that it works for running and finished jobs. It distinguishes itself from sibling tools (submit, status, cancel) by being solely for reading 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?
Explicitly lists use cases: check progress mid-run, diagnose failure traceback, grab final output. No explicit when-not-to-use or alternatives, but siblings are unrelated, so the guidance is clear enough.
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 carries full burden. It describes the nature of the event stream, the types of events, and the filtering parameters. It also mentions hook-ingested custom events. However, it does not detail response format, pagination, or performance characteristics like rate limits.
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 core purpose, then detailed examples and filters. Every sentence adds value without redundancy.
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 annotations and no output schema, the description adequately explains when and how to use the tool. It covers the key aspects: purpose, use case, filters, and relationship to sibling tools. Lacks details on response format, but sufficient for an agent to decide on invocation.
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%, so baseline is 3. The description adds some contextual examples (e.g., 'skipped 400 times') but does not provide significant additional meaning beyond the schema definitions themselves.
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 is an event stream that explains why jobs behave as they do, contrasting with jobd_status which only reports what happened. It provides specific examples of insights (e.g., skipped due to worker capability, dependency cancelled) and lists filterable parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when a job is not doing what you expect and jobd_status alone does not explain it.' This provides clear guidance on when to invoke this tool versus alternatives like jobd_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the key behavioral traits: sending SIGTERM with grace period, resulting state 'preempted', and conditions for refusal. This covers the core safety and mutability aspects.
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 that front-load the action and immediate behavior, with no redundant information. Every word adds value.
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?
For a simple tool with one parameter and no output schema, the description provides complete contextual information: what it does, how it behaves, and when it is not applicable. It is sufficient for correct agent decision-making.
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 only parameter (job_id) is not explicitly described in the text, but its purpose is implicitly clear from the tool's action. Schema coverage is 0%, but the description does not add explicit parameter details; 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?
The description clearly states the action (preempt), the target (running/assigned preemptible job), and the specific behavior (SIGTERM with grace, final state 'preempted'). It distinguishes from siblings like jobd_cancel by specifying the preemptible job constraint.
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?
Explicitly states when the tool is refused ('if not preemptible or not running'), providing clear usage context. However, it does not compare to alternatives (e.g., when to use jobd_cancel instead).
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 exist, so the description carries full burden. It describes the tool as a read-only snapshot with state, capacity, and health rollup, implying no side effects. It could mention data freshness or limitations, but the description is otherwise transparent about the output.
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, information-dense sentence with clear front-loading of the core purpose. Every phrase adds value, and there is no redundant or vague 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 no parameters and no output schema, the description thoroughly covers what the tool returns and when to use it. It is complete and actionable for an agent deciding whether to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema coverage is trivially 100%. The description adds immense value by detailing the output fields and structure, effectively compensating for the lack of an output 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 explicitly states 'Fleet snapshot: every registered worker...' and ends with 'Use before submitting GPU work to see what's free, or to diagnose why a job isn't being dispatched.' This gives a specific verb+resource and clear differentiation from sibling tools like jobd_submit or jobd_list.
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 explicit usage context: 'Use before submitting GPU work... or to diagnose why a job isn't being dispatched.' It does not mention when not to use or alternatives, but the guidance is clear and actionable for the primary use case.
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?
Discloses default behavior, filtering, row fields, limit clamping, and truncated field. Without annotations, it covers read-only nature and pagination, but lacks mention of authentication or rate limits.
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?
Four sentences, front-loaded with purpose, no redundancy. Every sentence adds value: purpose, filtering options, row contents, and guidance to sibling tool.
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?
Explains row fields and counts, mentions truncated field. No output schema, but adequately describes return structure. Missing explicit sort order (newest first only in schema description), but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond schema: explains default state set, provides example filter values, clarifies limit behavior with truncated reporting, and describes project restriction context.
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 lists jobs with per-state counts, uses specific verb 'List', and explicitly distinguishes from sibling tool jobd_status for full records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases: 'what is running / queued right now?' and locating job IDs. States defaults and filtering options, and directs to jobd_status for full details, effectively guiding when to use alternatives.
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:

[![jobd MCP server](https://glama.ai/mcp/servers/musharna/jobd/badges/card.svg)](https://glama.ai/mcp/servers/musharna/jobd)

Score Badge

Copy to your README.md:

[![jobd MCP server](https://glama.ai/mcp/servers/musharna/jobd/badges/score.svg)](https://glama.ai/mcp/servers/musharna/jobd)

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/musharna/jobd'

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