Uwear

Show Results

get_generation_results

Read-onlyIdempotent

Use this to show results in chat: generation_result_id (from mcp_brief_runs) for one result, generation_id for a job's results, or query, filters and dates to find past ones. Returns image previews to show as they are (never Markdown-embed result URLs); url is the original. Changes nothing.

Input Schema

Name	Required	Description
`kind`	No	Filter by type: 'Image', 'Edit', 'Upscale', 'Video'
`page`	No	Page number for pagination
`limit`	No	Number of items per page
`query`	No	Hybrid search across generated image content, originating item names, and SKUs.
`tag_ids`	No	Filter by tag IDs (results must have at least one)
`decision`	No	Filter by the unified result verdict.
`end_date`	No	Filter results created on or before this ISO date/datetime, e.g. 2026-04-27.
`model_ids`	No	Filter results to images generated with these AI models
`avatar_ids`	No	Filter results to images generated with these avatars
`outfit_ids`	No	Filter results to images generated with these outfits
`start_date`	No	Filter results created on or after this ISO date/datetime, e.g. 2026-04-20.
`qa_statuses`	No	Filter by QA statuses, e.g. pending, processing, completed, error.
`location_ids`	No	Filter results to images generated with these locations
`generation_id`	No	Filter by parent generation ID (lists all result images from one generation job)
`decision_source`	No	Filter by the verdict source.
`include_snapshot`	No	Include full generation settings, resource snapshots and raw prompt payloads. Large; use only for prompt recovery.
`art_direction_ids`	No	Filter results to images generated with these art directions
`clothing_item_ids`	No	Filter results to images generated with these clothing items
`generation_result_id`	No	Look up a single result image by its generation_result_id (the exact integer ID required by QA/edit/upscale/video tools). Returns that one result directly.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 22, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```

Changed1 schema field changedOct 11, 2026

addedInput schema / properties / include_snapshot

Added value: +{
+  "default": false,
+  "description": "Include full generation settings, resource snapshots and raw prompt payloads. Large; use only for prompt recovery.",
+  "type": "boolean"
+}

Changed3 schema fields changedAug 17, 2026

addedInput schema / properties / decision

Added value: +{
+  "default": null,
+  "description": "Filter by the unified result verdict.",
+  "enum": [
+    "approved",
+    "rejected",
+    "undecided"
+  ],
+  "type": "string"
+}

addedInput schema / properties / decision_source

Added value: +{
+  "default": null,
+  "description": "Filter by the verdict source.",
+  "enum": [
+    "auto",
+    "human"
+  ],
+  "type": "string"
+}

removedInput schema / properties / qa_decision

Removed value: -{
-  "default": null,
-  "description": "Filter by QA decision. true = accepted, false = rejected.",
-  "type": "boolean"
-}

First observedAug 1, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so 'Changes nothing' is redundant. What the description does add is beyond the annotations: it discloses that responses carry image previews intended to be displayed verbatim and that 'url' points to the original asset. That render-contract is exactly the kind of context annotations can't convey, though it says nothing about pagination or result volume.

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?

Front-loaded with the intent ('Use this to show results in chat'), then the disambiguation modes, then the rendering rule. It packs a lot into a couple of dense clauses, though the parenthetical '(from mcp_brief_runs)' is slightly opaque to an agent that doesn't know that tool.

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 19-parameter, zero-required, no-output-schema list tool, the definition covers the key decision points: which identifier selects which mode and how to render what comes back. Return shape is only partially described (previews + url), and pagination defaults/limits are left to the schema, but nothing essential for correct invocation is missing.

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% across 19 parameters, so the schema already carries the semantics; the description only highlights three of them by name. It adds the relationship 'generation_result_id is the exact integer ID required by QA/edit/upscale/video tools', which is useful, but the many filter dimensions are left entirely to the schema. Baseline 3 with schema doing the heavy lifting.

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 ('show results in chat') and enumerates three distinct lookup modes keyed on generation_result_id, generation_id, or query/filters/dates. It's clear what the tool retrieves, though it never names the sibling it differs from (e.g. mcp_read_generation_result or mcp_review_generation_results), so an agent must infer the split.

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?

The a/b/c mode breakdown is genuine routing guidance: one result by generation_result_id, all results of a job by generation_id, past results by query/filters/dates. It also gives a rendering directive (use previews as-is, never Markdown-embed result URLs, url is the original). No explicit exclusions versus sibling reader tools, but the usage context is clear.

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

All Uwear tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?