Skip to main content
Glama
Sign In
SeedreamMCP

SeedreamMCP

by AceDataCloud
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Get Seedream task result

seedream_get_task
Read-onlyIdempotent

Check the status of a Seedream image generation or edit task and retrieve resulting image URLs and metadata using its task ID.

Instructions

Query the status and result of a Seedream image generation or edit task.

Use this to check if a generation/edit is complete and retrieve the resulting
image URLs and metadata.

Use this when:
- You want to check if an image generation has completed
- You need to retrieve image URLs from a previous generation
- You want to get the full details of a generated/edited image

Returns:
    Task status and image information including URLs, prompts, and metadata.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "task_id": "<task_id>"
    },
    "name": "seedream_get_task"
  }
}

Input Schema

NameRequiredDescriptionDefault
task_idYesThe task ID returned from a generation or edit request. This is the 'task_id' field from any seedream_generate_image or seedream_edit_image tool response.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.5
  2. Removedv0.1.3
  3. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld, so the safety profile is covered without description help. The description adds the polling intent ('check if a generation/edit is complete'), which is genuine behavioral context, but omits rate limits, auth requirements, or expected latency for an async task lookup.

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 purpose sentence and its scoping are front-loaded, and the content is short enough to scan quickly. The 'Use this when' bullets and the Returns block are partly redundant with the opening paragraph and the existing output schema, which costs a little density.

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?

With one fully documented required parameter, a present output schema, and covering annotations, the definition gives an agent everything needed to invoke it correctly. The main missing piece is lifecycle guidance (polling cadence / whether status can be mid-flight), which matters for an async task 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?

Schema description coverage is 100%, and the task_id description already explains it comes from the generate/edit responses. The tool description adds no further meaning about the parameter, so the baseline 3 for full schema coverage applies.

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?

States a specific verb and resource: 'Query the status and result of a Seedream image generation or edit task,' which an agent can immediately distinguish from the generate/edit siblings. It stops short of differentiating itself from seedream_get_tasks_batch, so the single-vs-batch boundary must be inferred from the name.

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 an explicit 'Use this when:' block with three concrete conditions (check completion, retrieve URLs, get full details), which is clear situational guidance. It names no exclusions or alternatives, notably omitting when to prefer seedream_get_tasks_batch, and the three bullets restate largely the same trigger.

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