Marsell

Start a series

series_start

Destructive

Starts a series: the owner's standing yes for Marsell to make every episode on its schedule and post it to the accounts given, without asking each time, until it is paused in Marsell. While Marsell's work is paused for the whole business, nothing already scheduled posts or sends until it is switched back on, and a newsletter paused in Marsell holds even the issues already approved. Set consent: true and owner_words only when the owner has said, in their own words in this conversation, that the series should start making and posting every episode on its own on its schedule, after hearing the month's cost; owner_words is what they said, as they said it. Never assume it, and never start one for them. accounts are where it posts (links or "platform @handle"; series_read's known_accounts lists the business's own). monthly_tokens is the month's tokens the owner agreed to (series_quote's per_month, or series_read's every_scheduled_type when more than one video type is on the schedule): it is refused when the series now costs more. episode_budget: true lets this series' episodes go ahead without a card, up to N tokens each, N being this series' quoted budget for an episode's film. It is kept on this series' standing yes only: the business's spend choices (sites, films, Series episodes) are not changed, and Series episodes switched off in Marsell, or the agent paused, still stop it. Without it, each episode follows the business's Series episodes choice (off, ask each time, a budget, or no limit). Use it only when the owner agreed to that spend too, in the same words. Before creating or starting one, quote the month with series_quote and tell the owner the tokens each episode and the month may use, whether their plan holds it, and what it costs them in dollars a month (costs_the_owner: the price of the plan that holds it). Starting spends nothing by itself; each episode spends its tokens as it is made.

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": {
      "series": "<series>",
      "consent": "<consent>",
      "owner_words": "<owner_words>"
    },
    "name": "series_start"
  }
}

Input Schema

Name	Required	Description
`series`	Yes	The series' id or exact name (series_read).
`consent`	Yes	true only when the owner said, in their own words, to start it.
`project`	No	The project's id or exact name. Optional when the account has one project.
`accounts`	No	Where it posts: account links or "platform @handle".
`owner_words`	Yes	What the owner said when they agreed, as they said it.
`episode_budget`	No	true to let each episode go ahead without a card, up to this series' quoted film budget. It is kept on this series only; the business's spend choices are not changed, and Series episodes switched off in Marsell still stop it.
`monthly_tokens`	No	The month's tokens the owner agreed to (series_quote's per_month.tokens, or every_scheduled_type's when series_read shows it).

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 flag destructiveHint/openWorldHint/readOnlyHint=false; the description adds real consequence detail: it posts to third-party accounts, is refused when the series now costs more, that pausing in Marsell stops scheduled posts and approved newsletters, that episode_budget is scoped to this series' standing yes only, and that starting spends nothing but each episode consumes tokens. It does not spell out reversibility of the posted output or error/return behavior, so not a 5.

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?

Front-loaded with the core meaning, but it is one dense multi-clause paragraph with heavy semicolon chaining and repeated re-explanations of budget scope; a call-critical rule such as the series_quote prerequisite is buried mid-paragraph rather than surfaced.

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?

For a 7-parameter write tool with no output schema, it covers consent gating, cost disclosure duties, refusal conditions, pause interactions and budget scoping. An agent can call it correctly and knows what to do beforehand.

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 baseline is 3; the description goes further by naming the authoritative source for each value (monthly_tokens from series_quote's per_month or series_read's every_scheduled_type; accounts from series_read's known_accounts) and by explaining exactly when episode_budget applies and what it does not change.

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 and defines what 'start' actually means here: a standing yes for Marsell to make and post every episode on its schedule without asking each time. That scope definition distinguishes it from series_create and series_video_type_set, which are its nearest siblings.

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 explicit preconditions and exclusions: quote the month with series_quote first and tell the owner the per-episode/month tokens, whether the plan holds it and the dollar cost; set consent/owner_words only when the owner said so in their own words; 'Never assume it, and never start one for them.' It also routes to series_read for known_accounts and every_scheduled_type.

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.