Nextmail

Upload template image

uploadTemplateImage

Upload an image for templates, the way the template editor does, and get the public url to use in a template. Pass the picture in base64 as image with its type (image/png, image/jpeg, image/webp, image/gif, image/svg+xml), or an image in Files as fileId, up to 100MB. It is fitted into 1200 by 1800 pixels and stored in a form every mail client shows.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "uploadTemplateImage"
  }
}

Input Schema

Name	Required	Description
`crop`	No	The part of the image to keep, each value a fraction of the whole from 0 to 1: x and y are its left and top edges, width and height its size. Leave it out to keep the whole image.
`image`	No	The image in base64, or as a data: URL. Leave it out when you pass fileId instead.
`fileId`	No	An image in Files to use instead of image: one the user attached in this chat, or one listFiles found. It can be up to 100MB.
`contentType`	No	The type of the image, such as image/png. It is needed with image and taken from the file with fileId.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 25, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations cover the safety profile (readOnlyHint false, destructiveHint false, openWorldHint false), and the description adds real value beyond that: a 100MB cap, the 1200x1800 fitting behavior, and that the stored form is optimized for mail client rendering. It does not say where the image persists or whether repeated uploads create duplicates, which would complete the mutation story.

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 dense sentences, front-loaded with purpose and outcome before inputs. Every clause carries information — verb, return value, alternatives for input, size cap, supported types, and transform behavior — with no filler.

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, yet the description tells the agent the return value (the public URL) and the two input modes, with parameters fully documented in the schema. What is missing is persistence context: whether the resulting image is enumerable via listTemplateImages or how it is later referenced in a template.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema lacks: it enumerates the concrete accepted content types (png, jpeg, webp, gif, svg+xml) whereas the schema only says 'such as image/png'. It also clarifies the effective outcome of omitting crop (whole image fitted into 1200x1800).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (upload an image for templates) plus the payoff (get the public url to use in a template), which is enough to separate it from listTemplateImages or getTemplate. It does not explicitly contrast with the sibling uploadFile, so an agent must infer that this one is template-scoped.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context ('the way the template editor does') and explains the two input paths (base64 image vs fileId from Files), which implies when each applies. But it never states when to pick this over uploadFile, nor whether the result must be used with a specific template call, so the when-to-use guidance remains implied.

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

All Nextmail tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.