List ID photo presets, plan print layouts, and render printable HTML photo sheets.
Scored across 3 tools
Each tool has a clearly distinct role: list_photo_presets is pure reference data, plan_photo_sheet computes geometry without rendering, and render_photo_sheet_html produces output. The descriptions explicitly distinguish plan vs render and even advise when to prefer one over the other, leaving no room for misselection.
All three names follow a consistent snake_case verb_noun pattern (list_/plan_/render_ + domain object). The _html suffix on render is a meaningful, descriptive qualifier rather than a convention break.
Three tools is on the thin side but well-matched to a narrow, focused purpose (ID-photo sheet planning and rendering). Each tool earns its place with no redundancy, though the surface is small.
The lifecycle of preset lookup, non-destructive layout planning, and HTML rendering is covered, including custom dimensions and fit-checking. Minor gaps exist (no separate validation/preview tool), but the core workflow has no dead ends.
List the supported ID-photo document presets (France and Canada, with exact millimetre sizes, head-height bands, background rules and official sources), the printable paper formats, the standard grid layouts and usage notes. Takes no parameters.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. 'Takes no parameters' effectively discloses a safe, non-mutating read, and the parenthetical lists exactly what data is returned, but nothing about output format (it returns prose vs structured records?) or whether the data is static or fetched live.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with the key verb first and the no-parameter fact last. The deep parenthetical is dense but each clause describes real returned content, so little is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description compensates well by enumerating the returned categories (presets with mm sizes, head-height bands, background rules, sources, paper formats, grid layouts, usage notes). It lacks only a note on response shape and how the data relates to the sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters and 100% schema coverage; the baseline applies. 'Takes no parameters' explicitly confirms this, which is the only parameter-related information that could be added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (ID-photo document presets) plus the exact contents returned, including regions and attributes. An agent can distinguish it from plan_photo_sheet and render_photo_sheet_html, which are action tools, without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage as a reference/requirements lookup before planning or rendering, but no explicit when-to-use, when-not-to-use, or named alternative. The zero-parameter nature makes routing fairly obvious, but the description never says it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the layout of an ID-photo print sheet without rendering it: resolves the photo size from the preset (or custom millimetres), counts the photos, and checks whether the grid fits the printable area of the chosen paper. Returns a JSON plan with ok, photo/needed/usable dimensions and a message; ok is false (never an error) when the grid does not fit.
| Name | Required | Description | Default |
|---|---|---|---|
| cols | No | ||
| rows | No | ||
| gapMm | No | ||
| paper | No | A4 | |
| preset | No | fr-std | |
| marginMm | No | ||
| customWidthMm | No | ||
| customHeightMm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses the return shape (ok, photo/needed/usable dimensions, message) and, crucially, that ok=false is a normal negative result rather than an error — a genuinely non-obvious behavioral trait. It stops short of explicitly stating the tool is pure/side-effect-free and cheap to call repeatedly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads the verb and then layers purpose, scope, return contract, and failure semantics in order of importance. No filler, nothing repeated from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately documents the return payload and the failure convention, which is the main thing an agent needs to interpret results. The remaining gap is the undocumented layout parameters, which the schema names but never explains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 8 parameters, so the description must compensate. It only clarifies one relationship — that the photo size comes from the preset, or from custom millimetres when the preset is custom — and says nothing about cols, rows, gapMm, marginMm, or which paper enum values mean what.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb + resource: "Compute the layout of an ID-photo print sheet", and the qualifier "without rendering it" implicitly separates it from render_photo_sheet_html. It does not name either sibling explicitly, so the differentiation is inferable rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase "without rendering it" hints at the plan-vs-render split, but there is no explicit when-to-use/when-not guidance and no mention of list_photo_presets as the source of valid preset values. Usage is implied rather than routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a self-contained, printable HTML sheet tiling one ID photo at real physical size across a cols x rows grid on the chosen paper, with optional cut guides and image framing (zoom/offset). Pass the photo as an inline base64 data URL (image/jpeg or image/png); without one, the sheet prints sized placeholders. If the grid does not fit the paper, the tool returns a structured error with the exact needed and usable dimensions and renders nothing. WARNING: a base64 image payload is large and is echoed back inside the returned HTML, so it consumes a lot of the calling LLM client's context window; resize/compress the image (small JPEG, 3 MB decoded max) before calling, and prefer plan_photo_sheet when you only need the geometry.
| Name | Required | Description | Default |
|---|---|---|---|
| cols | No | ||
| rows | No | ||
| zoom | No | ||
| gapMm | No | ||
| paper | No | A4 | |
| preset | No | fr-std | |
| marginMm | No | ||
| cutGuides | No | ||
| offsetXPct | No | ||
| offsetYPct | No | ||
| imageDataUrl | No | ||
| customWidthMm | No | ||
| customHeightMm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses placeholder behavior, structured error behavior when the grid does not fit, the exact failure output, and a strong context-window warning about base64 payloads. These are meaningful behavioral traits beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core operation, then adds the photo payload behavior, failure behavior, and a clearly marked warning. Every sentence contributes necessary context for a complex rendering tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is strong on purpose, alternatives, and behavioral warnings, and it explains the returned HTML and error case. However, for a 13-parameter tool with zero schema descriptions and no annotations or output schema, it omits important parameter semantics that an agent would need to invoke it precisely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with 13 parameters, so the description must compensate. It mentions cols/rows, paper, cut guides, zoom/offset, and imageDataUrl, but does not explain preset, marginMm, gapMm, customWidthMm, customHeightMm, defaults, ranges, or how custom dimensions interact with presets.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: render a self-contained printable HTML sheet tiling an ID photo at physical size across a cols x rows grid on chosen paper. It also distinguishes the tool from plan_photo_sheet by naming the alternative when only geometry is needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear usage condition and one explicit alternative: prefer plan_photo_sheet when only the geometry is needed. It does not mention list_photo_presets or explain when to use this tool versus preset-discovery workflows, leaving a small gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
list_photo_presetsplan_photo_sheetrender_photo_sheet_htmlTurn a portrait into a compliant passport, visa or ID photo. 300+ official specs, 3 free a day.
Render PDFs from templates you design once: list templates, check the data shape, preview, render.
Generate images and PDFs from HTML/CSS, live websites, and reusable templates.
Generate IDs, QR codes, and hashes, encode values, geolocate IPs, plus gated host diagnostics.
Add one secure layer between your agents and this server.
