freeicon-mcp

ia_generate

Get a complete drawing spec for a flat-illustration scene card in any of 15 professional styles, with exact palettes and composition rules, then draw the SVG and validate it.

Instructions

Get a complete drawing spec for a flat-illustration scene card (480x360 SVG) in one of 14 professional styles (flat cut-paper, bold pop, halftone, ink sketch, isometric, one-line, vintage emblem, ...). The spec carries exact palettes, character proportions, composition rules and failure modes from the original methodology. The AI (you) draws the SVG per spec, validates with ia_validate, then delivers.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "scene": "<scene>",
      "style": "<style>"
    },
    "name": "ia_generate"
  }
}

Input Schema

Name	Required	Description
`size`	No	Card width in px (240-960, default 480; height = 4:3)
`scene`	Yes	Who is doing what, with which hero prop — e.g. "a designer presenting a wireframe on a big screen to a teammate"
`style`	Yes	One of 15 styles: flat / bold-pop / flat-with-black / framed-panel / grainy-gouache / halftone-line / ink-sketch / isometric-mono / line-interior / one-line / outlined-cartoon / teal-spot / two-colour-brush / vintage-emblem / line-minimal (calibrated from real iconfont illustrations)

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.4Nov 9, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description must carry the behavioral load, and it does disclose the most non-obvious trait: the tool returns a spec rather than a rendered image, and the caller is responsible for drawing and validating. It adds that the spec embeds palettes, proportions, composition rules and failure modes. It does not cover error behavior, response format specifics, or any limits.

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?

Three sentences, front-loaded with the deliverable and its dimensions, followed by what the spec contains and the downstream workflow. No filler, though the style enumeration partially duplicates what the schema already lists.

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?

There is no output schema, so the description must describe the return value; it does so at a conceptual level ('complete drawing spec' carrying palettes, proportions, composition rules, failure modes). For a three-parameter generation tool this is close to sufficient, with only the 14-versus-15 style count creating ambiguity.

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 description coverage is 100%, so the baseline is 3. The description corroborates the style parameter and names example styles, but it introduces a contradiction: the prose says '14 professional styles' while the schema documents 15 named styles, which could mislead an agent enumerating options.

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 and resource ('Get a complete drawing spec for a flat-illustration scene card') plus the output artifact (480x360 SVG). It also distinguishes itself from the adjacent step by naming ia_validate and clarifying that the AI itself draws the SVG, so an agent knows this is a spec generator, not an image generator.

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 workflow is spelled out: obtain the spec, draw the SVG from it, validate with ia_validate, then deliver. That gives clear when-to-use context and points to the follow-up tool. It stops short of stating when NOT to use it (e.g. versus g_generate for non-illustration assets) or any prerequisites.

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