Case study by Elmehdi, FluxDraw. This article examines my n8n agent test using Google Gemini and a Hugging Face MCP image tool. The tool returned image data, but the downstream content was incomplete and the HTTP Request failed. I did not publish the generated article or activate the workflow for public use.
The useful lesson is where to draw the success boundary: a working tool call is evidence of agent functionality, not evidence of a finished publishing pipeline. Here is what the execution screenshots establish and how I would validate a similar workflow before connecting it to a CMS.
Visual guide: Find the agent success boundary
How to use this map
- Use one short task that needs the connected tool. A broad request to research, generate an image and publish introduces several failure boundaries at once.
- Inspect the tool response itself. Image bytes and a MIME type are not automatically a public image URL suitable for an HTML img element.
- Check both structure and meaning: title must contain text, image source must be usable, and labels must have the expected type. A green Code node does not establish these conditions.
- Keep the CMS step disabled until the draft passes a human review. In the execution described here, the downstream HTTP Request failed; no successful publication is established.
Stop and check: Stop before the CMS request if required fields are empty. Keep the input and the failing output together when reporting the problem.
Next practical guides: n8n Self-Hosted AI Automation: Build a Content Pipeline · Build a Local AI Workflow with Ollama, ComfyUI and n8n
What this test actually demonstrates
The workflow is named Simple Trigger Workflow. Its main path is Chat Trigger → AI Agent → Code in JavaScript → HTTP Request. Google Gemini Chat Model, Hugging Face MCP and Structured Output Parser are connected beneath the agent. A separate Code Tool is also visible, but its presence alone does not establish that it ran.
- Observed: the Gemini model and Hugging Face MCP entries show successful execution.
- Observed: the MCP output includes an image response with
mimeType: image/webpand encoded data. - Observed: Structured Output Parser is marked successful in the execution trace.
- Observed: the downstream JavaScript node completes, but its visible output contains empty title and labels fields and an image tag with an empty source.
- Observed: HTTP Request is red and the overall run is marked as an error.
- Not established: the exact HTTP error cause, a successful upload, a published post, or repeatable performance across multiple runs.
The screenshots include an exploratory prompt mentioning 2027. That was test input, not a verified comparison of future products or evidence supporting any claims about them. The generated article was not published.
Why this is an AI Agent test rather than another n8n installation guide
FluxDraw already has a self-hosted n8n content pipeline overview. This case study starts after installation and follows one agent execution, its tool response and the data handed to the next node.
In n8n, an AI Agent combines a chat model with tools the model can choose to call. The official AI Agent documentation requires at least one connected tool. This is different from an editor assistant that helps build or debug a workflow: the agent is itself a running node in the workflow.
Local hosting does not mean local inference
I used this as a local n8n experiment, but Gemini and the Hugging Face tool are remote services. Hosting the workflow on a PC does not make those model calls offline or keep every input on that PC. The execution screenshots do not establish the exact Gemini model ID, the n8n version of this run, or its billing status.
For that reason, this is not an “unlimited free AI agent” claim. Check the current limits and pricing of each provider before repeating it. The broader Ollama, ComfyUI and n8n architecture guide covers a different goal: organizing a larger local creative stack.
How to build a small, inspectable version
The steps below are a reconstruction guide based on the visible architecture and official documentation. They are not a downloadable copy of my workflow: the screenshots do not expose all credentials, prompts, node versions or mappings.
1. Start with Chat Trigger and one model
Add a Chat Trigger and connect it to AI Agent. Connect a Google Gemini Chat Model using your own stored credentials and an available model that supports the required tool calls. Test one short message first. Keep the prompt narrow: ask for one image concept or a short draft, rather than research, image generation, formatting and publication in one instruction.
2. Connect one MCP tool and inspect its contract
The MCP Client Tool documentation explains how to connect an external server and select which tools the agent can access. Use the endpoint and authentication supplied by that service. Do not assume that a node label reveals its complete connection configuration.
For Hugging Face, follow its official MCP setup instructions and select the relevant tool. Available tools can depend on your account and selected Spaces. Start with the one capability you need so its inputs and returned data are easy to inspect.
3. Run a task that actually requires the tool
An example test instruction is: “Use the connected image tool to create one abstract illustration of a local automation workflow. Report the tool result and whether it returned image bytes or a hosted URL. Do not publish anything.” This is a suggested test prompt, not the exact prompt from my recorded run.
Open the execution log and select the tool entry. Confirm that the log contains a successful call with real output. A connected node, an agent saying it used a tool, and a successful tool invocation are three different levels of evidence.
The MCP call succeeded, but the publishing data did not
The selected Hugging Face MCP entry shows Success and an image response. The requested resolution shown in the input is 1280×720. That proves the requested size; it does not independently verify the decoded image dimensions or visual quality.
The returned data is encoded image content, not automatically a public URL that can be placed inside <img src="...">. A workflow needs a separate, verified handling step: retain the file as binary data, use a supported image upload mechanism, then map the resulting image URL or attachment into the draft. Do not send a large encoded image back into the language model unless the model and task specifically require it.
A green JavaScript node can still output an unusable draft
In the JavaScript output screenshot, the title and labels fields are empty. The content contains a centered image wrapper with an empty src and empty alt. The node ran without a runtime failure, but the result is not a complete article.
This is the most useful diagnostic detail in the test. Before investigating the final HTTP node, inspect the payload it received. A missing title, missing article body or blank image URL is an upstream data-quality issue even when the next API has its own separate error.
Validate meaning as well as JSON structure
The Structured Output Parser can return fields based on a JSON Schema. A successful parser status does not establish that the article is accurate, complete or suitable for publication. The exact schema used in my recorded run is not visible.
For a new workflow, define the required fields deliberately: a non-empty title, article content, source URLs where factual claims need support, and an image reference only when an image has actually been stored. Keep image data separate from prose fields. Inspect the actual output shape before writing expressions; do not assume every agent version returns the same property names.
A proposed validation gate before any CMS request
- Require a title containing meaningful text after trimming whitespace.
- Confirm the body contains actual paragraphs, not only markup or an image wrapper.
- If an image is required, check that its upload succeeded and its reference is usable.
- Reject placeholder links and empty image sources.
- Check source links and factual claims manually; JSON validation cannot do this for you.
- Route failed checks to review and keep the CMS branch disconnected until the payload is ready.
These are recommended next steps. The supplied execution does not show a successful rerun after applying them, so I cannot present them as fixes already proven in this workflow.
How I would investigate the failed HTTP Request
The red node tells us that the HTTP step failed, but the selected screenshots do not display its full response status and error body. It would be guessing to blame OAuth, a malformed request, a quota limit or a specific endpoint.
- Open that node in the failed execution and record the status code and response message, without exposing credentials.
- Compare its input JSON with the API’s required fields.
- Check method, endpoint, authentication and content type against the destination’s official documentation.
- Validate a minimal draft request before adding image handling or optional fields.
- After any ambiguous timeout, check the destination for an existing draft before retrying a create operation.
A successful retry should be documented separately with its actual response and destination state. Until then, the correct result for this test remains “tool call succeeded; publishing path failed; no publication.”
What I would change before another run
I would separate image generation, article generation and CMS preparation so each stage has a visible input and output contract. I would also replace the speculative topic with a small, verifiable task and inspect the returned fields before moving forward.
The screenshots show large token counts in the execution panel, but they do not establish billing cost or prove which payload caused that usage. I would inspect the model input and tool responses, keep only necessary text in model context, and store image bytes outside the text-generation path. This is a diagnostic plan, not a claim that I measured a reduction.
For a larger project, use the n8n automation overview to plan triggers and review stages. Use this case study to check a narrower question: did the agent call the tool, and did the resulting data remain useful all the way to the next node?
Frequently asked questions
Did this workflow publish an article?
No. I did not publish the generated article or put the workflow into public operation. The recorded execution ends with a failed HTTP Request.
Does a successful parser mean the article is ready?
No. Check the actual fields, factual accuracy, links, images and final rendered draft. A structurally acceptable response can still contain missing or unusable content.
Is the whole workflow local and free?
No such claim is supported by this test. The orchestration was a local experiment, while the visible model and MCP integration use external services. Their availability, quotas and costs need separate verification.
Can I reproduce the exact run from these screenshots?
Not exactly. They document architecture and specific results, but do not contain a complete exported workflow, all configuration values or a confirmed end-to-end fix. Start with the small tool-call test above and record your own environment and results.
Evidence and limitations
This case study is based on the supplied execution screenshots and my confirmation that nothing was published. It does not claim repeated benchmarks, a fully offline setup, a working production pipeline or a verified fix for the final HTTP error. The screenshots are the evidence for the observed node states; the linked n8n and Hugging Face documentation supports the reconstruction guidance.
