Skip to main content
Glama
Luvi-io

Luw MCP Server

Official
by Luvi-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Get generation result

luw_get_result
Read-only

Collect the result of a Luw.ai generation that was still processing (tools return a processing_url when a job outlasts their wait). Waits for the job to finish (up to the server's wait limit) — call again if it's still running.

Instructions

Collect the result of a Luw.ai generation that was still processing (tools return a processing_url when a job outlasts their wait). Waits for the job to finish (up to the server's wait limit) — call again if it's still running. Free; never re-run a generation instead.

Input Schema

NameRequiredDescriptionDefault
waitNoWait for completion (default true). false = check once and return immediately.
source_imageNoThe source returned with that processing_url (the job's input image), so the result is shown before and after.
processing_urlYesThe processing_url returned by a generation tool.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.2
    • addedInput schema / properties / source_image
      Added value: +{
+  "description": "The source returned with that processing_url (the job's input image), so the result is shown before and after.",
+  "type": "string"
+}
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly/destructive/openWorld, so the safety profile is covered. The description adds real behavioral value beyond that: long-polling semantics bounded by the server's wait limit, retry guidance, and the cost fact ('Free') that discourages re-running. It stops short of describing the returned payload, but no output schema exists to lean on.

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?

Three tight sentences with zero filler, front-loaded with the job-retrieval purpose before the retry and cost guidance. Every clause earns its place.

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 result-retrieval tool whose annotations carry the safety profile and with no output schema to explain, the description is nearly complete: it covers trigger, waiting, retry, and cost. The only gap is not naming what the collected result contains, which is minor here.

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 all three parameters (including wait and source_image) are documented in the schema itself. The description only implies the processing_url's provenance and the waiting behavior; it adds little parameter detail the schema doesn't already carry, matching the baseline for full 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?

States a specific verb (collect) and resource (result of a Luw.ai generation), and immediately scopes it to jobs that were 'still processing'. This clearly differentiates it from the sibling generation/design tools, which produce jobs rather than retrieve their results.

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 when to use it (a generation tool returned a processing_url because the job outlasted its wait), what to do if incomplete ('call again if it's still running'), and a when-not ('never re-run a generation instead' / 'Free'). This routes the agent away from the costly, wrong alternative.

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