Skip to main content
Glama
houtini-ai

Amazon Creators MCP

by houtini-ai

format_items

Read-only

Re-render previously fetched Amazon items into markdown, JSON, or HTML card/grid embeds without re-calling the API. Use to iterate on custom styles or produce embeddable HTML.

Instructions

Re-render Amazon items you already have (from a previous search_items, get_items, or get_variations call) without hitting the API again. Pass the exact structuredContent you received back as response, or pass items directly as an array. This tool IS for producing HTML embeds — the user has by this point explicitly asked for a card/grid/preview. Use it specifically when iterating on customStyles ("make the border hotpink", "dark mode", "bigger price") — it avoids rate-limit pressure and is much faster than re-querying Amazon.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemsNoAlternative to `response`: an array of Item objects.
formatNoOutput format. DEFAULT TO 'markdown' OR 'json' when you plan to summarise the results in chat. Use 'html-card' / 'html-grid' ONLY when the user has explicitly asked for an embed, preview, card, widget, grid, or paste-ready HTML — these formats return a full HTML document the user pastes into their blog and are not for in-chat reading. 'markdown' = friendly summary source; 'json' = raw API data for programmatic use; 'html-card' = single product card; 'html-grid' = responsive grid of all items.markdown
responseNoRaw response envelope previously returned in `structuredContent` by search_items / get_items / get_variations. Pass this OR `items`.
retrievedAtNoISO-8601 timestamp marking when the original response was fetched from Amazon. Rendered next to the price as "as of <ts>". If omitted, defaults to now — but you should pass the original fetch time when re-rendering old data so the displayed timestamp stays truthful.
customStylesNoExtra CSS appended to the default stylesheet when format is 'html-card' or 'html-grid'. Target stable class-name anchors: .amzn-card, .amzn-card__image, .amzn-card__title, .amzn-card__meta, .amzn-card__brand, .amzn-card__rating, .amzn-card__price, .amzn-card__price--unavailable, .amzn-card__savings, .amzn-card__cta, .amzn-card__disclosure, .amzn-grid. Ignored for 'markdown' and 'json'.
titleMaxCharsNoMaximum rendered title length for HTML card/grid output. Amazon titles are often 150+ chars of keyword stuffing; clamping to ~80 keeps cards one-line on typical widths. Defaults to 80. Set to 0 to disable. Ignored by 'markdown' and 'json' — those formats get the full untruncated title.
hideItemsWithoutPriceNoWhen format is 'html-grid', drop items that have no price. Defaults to true — cards without a price are weak embeds (no deal hook, reader must click through to learn anything). Set false for comparison tables where availability can lapse but you still want the product visible. Ignored for 'html-card', 'markdown', and 'json'.
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses that no API call is made, data must come from a previous call, and that it is a re-rendering operation. This adds meaningful behavioral context (rate-limit avoidance, no external mutation) that complements the annotations.

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?

Two sentences with no filler. The first sentence establishes the core purpose and inputs, the second provides concrete usage scenarios and benefits. Well structured and properly front-loaded.

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?

While there is no output schema, the rich parameter descriptions (especially the format enum) effectively explain what the tool produces. The description could explicitly say 'returns the formatted output' but this is strongly implied by the verb 're-render' and the format details. Overall it is complete enough for reliable tool selection and invocation.

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?

The input schema already has 100% coverage with detailed descriptions for each parameter. The description adds workflow value by clarifying the two alternative input paths (response vs. items) and linking to previous calls, but the schema alone is largely sufficient.

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 clearly states the tool re-renders already-fetched Amazon items without re-hitting the API, using a specific verb ('re-render') and naming the exact prior calls that produce the input. It explicitly contrasts with sibling retrieval tools by emphasizing it is for formatting existing data, not fetching new data.

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?

It explicitly tells when to use the tool: for producing HTML embeds after the user asks for a card/grid/preview, and specifically when iterating on customStyles. It also mentions avoiding rate-limit pressure and being faster than re-querying, giving clear reasons to prefer this over alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/houtini-ai/amazon-creators-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server