Skip to main content
Glama

partner_generate

Generate images with hosted PARTNER models (Flux, Ideogram, DALL·E, Recraft) by sending prompts and parameters to remote infrastructure, spending credits only after user consent, and optionally saving outputs to a specified path.

Instructions

Run a hosted PARTNER model (Flux / Ideogram / DALL·E / Recraft / …) — SPENDS CREDITS.

Wraps comfy generate <model> [--param=value]…. Runs entirely on the PARTNER's infrastructure — the user's local ComfyUI never executes anything. For local execution, use emit_partner_workflow -> run_workflow -> fetch_outputs instead (covers only the models comfy-cli can render as a node).

Args: params: the model's own inputs (prompt, aspect_ratio, seed, …), forwarded verbatim. Discover them with list_partner_models() and partner_model_schema(model) — not nodes / search_templates, which answer a local-install question. confirm_spend: this call ALWAYS spends credits. Set True ONLY when the user has actually agreed to spend on this call — never merely to clear an error. A client that supports MCP elicitation prompts the user anyway, so this is the fallback for one that cannot. A durable comfy generate consent always in comfy-cli's own config skips the prompt — the engine consenting to itself, not this server. out_path: forwards --download <path>; a save-path TEMPLATE, not a filename — {request_id}/{index}/{ext} are substituted, and a trailing slash means "default filename in this directory".

Gotchas: - With no consent source available, comfy-cli fails CLOSED — nothing is spent. - Saved paths come back as saved_paths, verbatim from what comfy-cli printed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelYes
paramsNo
out_pathNo
confirm_spendNo
timeout_secondsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.8/5.0
Behavior5/5

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

There are no annotations, so the description carries the full behavioral burden. It fully discloses that the call ALWAYS spends credits, runs remotely on PARTNER's infrastructure, fails closed when no consent source is available, and returns saved_paths verbatim from comfy-cli. This is unusually transparent about side effects and failure behavior.

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 long but every sentence earns its place: headline warning, local-vs-remote distinction, parameter semantics, and gotchas are all tightly packed without repetition. The front-loaded 'SPENDS CREDITS' immediately signals the most critical behavioral fact.

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 credit-spending, remote-execution tool with no annotations and no output schema, the description covers nearly all critical context: purpose, consent, spend, fail-closed behavior, path templating, and saved_paths. The only notable gap is timeout_seconds, which is undocumented, and the return payload beyond saved_paths is not described.

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?

With 0% schema description coverage, the description compensates substantially by explaining params (model's own inputs forwarded verbatim), confirm_spend (real user consent vs fallback), and out_path (template with placeholders). However, it does not explain timeout_seconds at all, and the model parameter itself only gains meaning through the intro text, not a dedicated parameter explanation.

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 states a specific action ('Run a hosted PARTNER model') and names the model families it covers. It also explicitly differentiates from local execution by saying 'For local execution, use emit_partner_workflow -> run_workflow -> fetch_outputs instead', which lets an agent pick the right tool without opening schemas.

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?

The description gives explicit when-to-use instructions: hosted PARTNER models versus local execution, and even redirects to sibling tools for the local path. It also tells agents to discover model parameters with list_partner_models() and partner_model_schema(model) rather than nodes/search_templates, so the selection and invocation context is clearly mapped.

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