Herald.ink MCP

upload_entity_image

DestructiveIdempotent

Sets an entity's image: an NPC, monster, item or player portrait (token), a faction emblem or a location map. Replaces the current image of that kind. image is either a file URI from authorize_image_uploads (after its bytes were uploaded; the way to send a local file) or a data: URI with the image inline (png, jpg, webp or gif, at most 5MB, every byte of it in the call). Requires the Editor role.

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": {
      "campaignId": "<campaignId>",
      "entityType": "<entityType>",
      "entityId": "<entityId>",
      "image": "<image>"
    },
    "name": "upload_entity_image"
  }
}

Input Schema

Name	Required	Description
`kind`	No	Optional: Token, Emblem or Map. Defaults to the type's image (Map for a location, Emblem for a faction, Token otherwise).
`image`	Yes	The image: an mcp-file:// URI from authorize_image_uploads, or a data: URI (data:image/png;base64,...).
`entityId`	Yes
`campaignId`	Yes
`entityType`	Yes	NPC, MONSTER, ITEM, PLAYER, FACTION or LOCATION.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 6, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Adds real context beyond the annotations: it states the image of that kind is *replaced* (explaining the destructiveHint=true), requires the Editor role, and lists accepted formats. One flaw is the stated 5MB cap, which conflicts with the schema's maxSize of 20971520 bytes, leaving the agent unsure which limit to respect.

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?

Front-loads the purpose and then packs prerequisites and input forms tightly into a single dense block. Every clause carries information, though the run-on structure around the data: URI constraints makes it slightly harder to scan than it could be.

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?

With no output schema, the description covers the essentials an agent needs: auth role, destructive replacement semantics, and the two image transfer modes. It stops short of covering failure modes (nonexistent entity, oversized inline payload) or pointing to update_entity for non-image changes.

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 only 60%, so the description must compensate, and it does for the most complex parameter: `image` is explained as either an uploaded file URI or a fully inline data: URI with formats and size limit. It also implicitly maps entity types to the optional `kind` defaults (token/emblem/map), though campaignId and entityId get no explanation.

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?

Opens with a specific verb+resource ('Sets an entity's image') and immediately enumerates the concrete targets (NPC, monster, item, player token, faction emblem, location map). It is clearly distinguishable from siblings like update_entity or authorize_image_uploads, the latter being named explicitly as a prerequisite.

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?

Gives clear usage context: it says the image is either a file URI produced by authorize_image_uploads (for local files) or an inline data: URI, which is actionable routing guidance. It lacks an explicit exclusion ('use update_entity for other fields') or a statement of what happens if no prior authorization exists.

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

All Herald.ink MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?