Skip to main content
Glama
Sign In
>sdcraft-mcp

>sdcraft-mcp

by TimkoNZT
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

list_jobs

Lists all image generation and editing jobs tracked in the current session, so you can see active or completed tasks and identify job IDs for polling results.

Instructions

Jobs known to this MCP in this session.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_jobs"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral burden. It does disclose one real behavioral trait — that the listing is limited to jobs from the current session — but says nothing about ordering, pagination, whether completed jobs are included, or what a returned job looks like, which matters for a read tool with no safety metadata.

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?

One short fragment with no wasted words, and the scoping information is front-loaded. But it is terse to the point of under-specification for a tool whose only job is discovery, leaving the agent to infer the operation type from the name alone.

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 tool with no output schema, the description covers the scope but not what is returned (fields of a job object) or how results are ordered/limited. It is minimally adequate, but an agent calling it blind does not know what it will receive.

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 takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description is not required to add anything here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the resource (jobs) and adds a meaningful scope qualifier (known to this MCP in this session), which tells the agent the list is session-bound rather than global. However, it is a noun phrase with no verb and does not differentiate the tool from sibling get_job or cancel_job, so the agent must infer that this is an enumeration operation.

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?

There is no explicit statement of when to use this tool versus get_job (single job lookup) or the other job-management siblings. The session scoping hints at a 'discover what exists' use case, but that is left to inference rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools