Marsell

Ask Marsell

ask_marsell

Destructive

Talks to Marsell, the project's marketer, in its chat: ask what it is doing and why, or tell it what to change (the week, a post, the plan). Without conversation it starts a new conversation, kept under your name in the owner's list of chats; pass the conversation id an answer gave to go on in it. Returns Marsell's reply, what it changed, the conversation's id, anything that waits for the owner's press, and each card it raised for the owner (a picture's ad, which spends only when the owner starts it) with its id and words. Prefer the direct tools for a plain read or change; use this for what needs Marsell's judgement or works on a canvas or a video. Marsell uses its own tools, so an answer may take a minute and spends the owner's tokens. With canvas or video, Marsell works on that canvas or video as when the owner has it open: what spends or posts there waits for the owner's press in Marsell's chat, and the answer says so. With attachments, the files sent through get_upload_link (each answer's attachment ids) go with the message, as files sent in the chat do.

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": {
      "message": "<message>"
    },
    "name": "ask_marsell"
  }
}

Input Schema

Name	Required	Description
`video`	No	A video, by its channel and episode ids (canvas_film's answer gives them as open).
`canvas`	No	A canvas, by its id.
`message`	Yes	What you say to Marsell, in plain words, as the owner would.
`project`	No	The project's id or exact name. Optional when the account has one project.
`attachments`	No	Files to send with the message, by the attachment ids an upload link's answer gave (get_upload_link, kind file).
`conversation`	No	Go on in this conversation (the id an earlier answer gave). Leave it out to start a new one.
`new_conversation`	No	Start a new conversation, even when conversation is given. Without conversation a new one starts anyway.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 7, 2026

changedInput schema / properties / conversation / description

Previous value: -"Continue this conversation (the id an earlier answer gave)."New value: +"Go on in this conversation (the id an earlier answer gave). Leave it out to start a new one."

changedInput schema / properties / new_conversation / description

Previous value: -"Start a fresh conversation instead of continuing the latest."New value: +"Start a new conversation, even when conversation is given. Without conversation a new one starts anyway."

Changed1 schema field changedNov 7, 2026

addedInput schema / properties / attachments

Added value: +{
+  "description": "Files to send with the message, by the attachment ids an upload link's answer gave (get_upload_link, kind file).",
+  "items": {
+    "format": "uuid",
+    "type": "string"
+  },
+  "type": "array"
+}

First observedNov 4, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations (readOnly=false, openWorld=true, destructive=true), it discloses cost and latency ("an answer may take a minute and spends the owner's tokens"), that Marsell runs its own tools, and that spending or posting on canvases/videos is gated on the owner's press. It also describes the returned artifacts (what changed, conversation id, waiting items, cards with ids), which is exactly the context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Core routing guidance is front-loaded, but the text is one dense paragraph of run-on clauses (the enumeration of the reply, changes, id, waiting items and cards) with repeated material — the new-conversation default is stated both in the body and again in the new_conversation schema field, and the canvas/video owner-press rule is stated twice. It is information-dense but harder to scan than it needs to be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a complex tool (7 params, two nested objects) with no output schema, so the description must explain returns itself — and it does, listing the reply, the changes, the conversation id, pending owner actions and card ids. Cost, latency, gating and id provenance are all covered, leaving nothing an agent needs missing before invoking it.

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 description coverage is 100%, so the baseline is 3; the description earns above that by explaining cross-tool provenance the schema can't: conversation ids come from an earlier answer, attachment ids come from get_upload_link, and video channel/episode ids come from canvas_film's answer. The redundant restatement of new_conversation behavior keeps it from a 5.

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?

"Talks to Marsell, the project's marketer, in its chat" names a specific verb and resource, then enumerates what it can do (ask what it is doing, tell it what to change in the week, a post, the plan). It explicitly separates itself from the sibling direct tools: "Prefer the direct tools for a plain read or change; use this for what needs Marsell's judgement or works on a canvas or a video."

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 both the when-to-use and the when-not: plain reads/changes go to the direct tools, while judgement calls, canvas work and video work come here. It also states the continuation rule (pass the conversation id from an earlier answer) and the attachment precondition via get_upload_link, so routing is explicit rather than inferred.

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.