Skip to main content
Glama

Submit A Hedra Generation Job

hedra_submit_job

Submit a generation job to a Hedra model, returning an async job ID for tracking. Check the model schema first and confirm input before starting billed work.

Instructions

Submit a generation job to a Hedra model. This starts real, billed work against the API wallet — always confirm the model and input with the person for anything non-trivial, and consider calling hedra_estimate_cost first for expensive requests.

Submission is asynchronous: this returns immediately with a job_id in IN_QUEUE or IN_PROGRESS status, not the finished result. Follow up with hedra_wait_for_job (simplest) or poll hedra_get_job_status / hedra_get_job yourself.

Before your first call to this tool for a given model in this session, call hedra_get_model_input_schema to get the exact required fields and enums — submitting a malformed input wastes a round trip and Hedra's validation is strict (e.g. Seedance's duration_ms only accepts specific values: 4000, 5000 ... 15000).

For any input field that takes a media reference (images, videos, audios, start_image, end_image, reference audio for voice cloning, etc.), first upload the file with hedra_upload_file and pass {"source":"url","url":} — or reuse a prior job's output with {"source":"asset","asset_id":<from outputs[].asset_id>}.

Args:

  • model_id (string, required): the model's public id (e.g. "seedance-20").

  • input (object, required): model-specific input, matching hedra_get_model_input_schema's schema exactly.

  • webhook (string, optional): HTTPS URL to receive a signed completion webhook instead of polling.

  • idempotency_key (string, optional): pass the same key on a retried submit to get back the original job's ack instead of creating a duplicate paid job.

Returns: JSON {job_id, model, status, status_url, result_url, estimated_completion_at}.

Error Handling:

  • "Error [INVALID_ARGUMENT]..." lists every invalid field with the allowed values — fix and resubmit.

  • "Error [INSUFFICIENT_BALANCE]..." means the API wallet needs funding; the message includes the funding URL and, when quotable, the exact amount short.

  • "Error [MODERATION_FAILED]..." means an input (often a reference image) was refused by content moderation.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inputYesModel-specific input object. Fetch the exact shape with hedra_get_model_input_schema first.
webhookNoHTTPS URL to receive a signed job-completion webhook.
model_idYesThe model's public id (e.g. 'seedance-20', 'gpt-image-2', 'hedra-avatar'). Get valid ids from hedra_list_models.
idempotency_keyNoReplays the original ack for a retried submit instead of creating a duplicate job.
Behavior5/5

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

Beyond annotations (which only say non-readonly, non-idempotent), the description discloses async submission with immediate job return, billing impact, idempotency key replay behavior, strict validation, and detailed error handling. No contradiction.

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?

Though lengthy, the description is well-structured with front-loaded warning on billing, followed by async behavior, prerequisites, parameter details, return format, and error handling. Every section serves a purpose; nothing is redundant.

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 complex tool with nested input and asynchronous behavior, the description covers prerequisites, return format, error handling, and follow-up steps. It even explains media upload and asset reuse, leaving no significant gap for an agent to invoke correctly.

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. The description adds meaningful semantics: explains media reference format (source/url/asset_id), idempotency key purpose, and model_id source. This goes beyond the schema's simple descriptions, but does not cover every edge case.

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 opens with 'Submit a generation job to a Hedra model', clearly stating the verb and resource. It distinguishes itself from sibling tools by emphasizing this starts real billed work and returns a job_id, unlike list/status tools.

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 when-to-use guidance: call hedra_estimate_cost first for expensive requests, confirm with the person, fetch the model input schema before first use, and follow up with hedra_wait_for_job or status polling. It names direct alternatives and gives operational workflow.

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

Install Server

Other Tools

Latest Blog Posts

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/HemanthDonga/hedra-mcp-server'

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