Marsell

Name the business's own characters

add_characters

Destructive

Names the business's own characters, when it has any: a mascot, a host, a narrator, the recurring cast of its channel. Each with who it is in a sentence, and each look it is drawn in (a 3D render, a flat drawing, a plush, a costume), with how that look differs. Then send pictures of every look with add_pictures or get_upload_link, giving character and look: each picture becomes that character in that look, which Create lists first under Characters and every picture and film keeps exactly as pictured. A name already on file is updated, never doubled (looks merge by name). Works during setup and after it (give project when no setup is open). Never a real person who isn't the business's own presenter. Spends nothing.

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": {
      "characters": "<characters>"
    },
    "name": "add_characters"
  }
}

Input Schema

Name	Required	Description	Default
`project`	No	Only with no setup open: the project's id or exact name.
`characters`	Yes	One or more characters, each with its name, who it is and its looks.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations only say readOnly=false, destructive=true, openWorld=false; the description adds idempotency semantics ('A name already on file is updated, never doubled (looks merge by name)'), downstream persistence ('every picture and film keeps exactly as pictured'), and cost ('Spends nothing'). That is substantial context beyond the hints, though it never spells out what existing text or looks are lost when an existing character is updated, which is the main destructive risk the annotation flags.

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?

Purpose and the picture follow-up are front-loaded, and most clauses carry information (idempotency, setup state, exclusion, cost). It is dense and fragmentary in places ('Each with who it is in a sentence') and partly restates schema guidance, but there is little genuine filler for a tool of this complexity.

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 still covers the full workflow (name, then attach pictures), where results surface ('Create lists first under Characters'), setup vs post-setup context, and the real-person restriction. The one gap is update-overwrite behavior for existing characters, which an agent making a destructive call would want spelled out.

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 real meaning: it explains that 'project' applies only when no setup is open and that supplying character plus look on a picture binds that picture to that character in that look. The merge-by-name rule for looks also clarifies what the nested 'looks' array actually does, not just its shape.

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 ('Names the business's own characters') and enumerates the concrete forms they take (mascot, host, narrator, recurring cast). It also distinguishes the tool from the picture-upload siblings by positioning it as the naming step that add_pictures/get_upload_link then feeds.

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?

Gives the triggering condition ('when it has any'), the follow-up workflow ('Then send pictures of every look with add_pictures or get_upload_link'), the setup-dependent parameter rule ('give project when no setup is open'), and an explicit exclusion ('Never a real person who isn't the business's own presenter'). Alternatives and boundaries are both named.

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

All Marsell 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.