# Show & Tell: Polyphemus, a single chat/API entry point for image workflows

**URL:** <https://discuss.huggingface.co/t/show-tell-polyphemus-a-single-chat-api-entry-point-for-image-workflows/182790>\
**Category:** Show and Tell\
**Created:** [October 2, 2026, 3:44am UTC](https://discuss.huggingface.co/t/show-tell-polyphemus-a-single-chat-api-entry-point-for-image-workflows/182790 "2026-10-02T03:44:07Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![shelledai](https://avatars.discourse-cdn.com/v4/letter/s/2acd7d/32.png) [@shelledai](https://discuss.huggingface.co/u/shelledai)\
**Post date:** [October 2, 2026, 3:44am UTC](https://discuss.huggingface.co/t/show-tell-polyphemus-a-single-chat-api-entry-point-for-image-workflows/182790/1 "2026-10-02T03:44:07Z")

</div>

Hi HF folks — I’m sharing Eye.Art Polyphemus as a workflow/API engineering project. It’s a hosted router, not an HF model or downloadable checkpoint: one conversational MCP entry point routes requests to image generation, reference-image edits, SVG creation, prompt ideas, and follow-up edits.

The main design problem is continuity. A follow-up like “change this image” needs the prior image and conversation context, while “make a new one” should start fresh. The API supports persistent sessions/conversations and asynchronous jobs: generation can return a job ID, and clients poll eye\_art\_image\_status instead of accidentally submitting the same request again.

Connect and docs: [MCP & API — Eye.Art](https://eye.art/polyphemus/api) · MCP endpoint: [https://eye.art/api/eye-mcp](https://eye.art/api/eye-mcp)

No model weights are hosted on HF; these are hosted Eye.Art workflows behind a chat/API surface. I’d love feedback from people building Spaces or MCP clients: what interaction patterns work best for carrying reference images through edits and showing users long-running image jobs?