Marsell

Stream set

stream_set

Start or change a stream: standing work that runs at a rate instead of a one-off task (posts a day on a connected channel, storyboard rounds a week, sign-up pages, pitches, replies a day). Give the rate per week; the checks hold it to input.channelLimits, to what an engine runs and to connected channels, and errors come back for you to fix. Setting an existing key changes its rate or brief. The owner approves each channel's first batches; a stream they approve to run on its own publishes within its cap with an undo window. Where the owner said the business's work runs on its own, nothing waits for those first batches: it publishes within its cap from the start (a person's own account, TikTok and trend posts still ask for each post). Returns the stream as it now stands. stream_stop ends one; a one-off piece is work_plan. It needs an act key.

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": {
      "key": "<key>",
      "title": "<title>",
      "engine": "<engine>",
      "kind": "<kind>",
      "channel": "<channel>",
      "ratePerWeek": "<ratePerWeek>",
      "brief": "<brief>",
      "goalKey": "<goalKey>",
      "verification": "<verification>",
      "stopRule": "<stopRule>"
    },
    "name": "stream_set"
  }
}

Input Schema

Name	Required	Description
`key`	Yes	The stream's key: lower case letters, digits, - and _, starting with a letter. An existing key changes that stream.
`kind`	Yes	What each piece is, a task kind (post, reply, pitch, landing and the rest).
`brief`	Yes	What every piece is about: the audience, the products it serves, the angle to rotate, what never to claim.
`title`	Yes	Its name as the owner reads it.
`engine`	Yes	The engine that makes it (content, social, community and the rest, as work_plan lists kinds on engines).
`channel`	Yes	Where it goes out; None for work that goes out nowhere.
`goalKey`	Yes	The key of the plan's goal it serves.
`project`	No	The project's id or exact name. Optional when the account has one project.
`stopRule`	Yes	When to stop it, in plain words: the metric and the threshold.
`ratePerWeek`	Yes	Pieces a week, 1 to 350 (7 is one a day, 28 four a day), held to the channel's limits.
`verification`	Yes	The number that shows it works, and the rule that verifies it.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare a non-read-only, open-world, non-destructive mutation, and the description adds substantial behavior on top: rates are validated against input.channelLimits, engine capability and connected channels; errors come back to fix; the owner-approval gate and the autonomy/undo-window path; and it returns the stream as it now stands. The only weak spot is the trailing "It needs an act key," which is unexplained and not a schema parameter, leaving an agent unsure what that prerequisite is.

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-loaded with the definition and the routing alternatives, which is the right order for an agent. It is dense and somewhat run-on — the nested parenthetical about a person's own account, TikTok and trend posts takes a re-read — but nearly every clause carries behavioral information rather than filler.

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

Completeness3/5

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

For an 11-parameter, 10-required mutation tool with no output schema, it covers the approval flow, validation failure mode and return value well. Gaps remain: the optional project parameter is never mentioned, the undo window has no stated length, and the "act key" requirement has no corresponding parameter, which could send an agent hunting for a field that does not exist.

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 schema carries the field-level burden and the baseline would be 3. The description still adds meaning beyond it: ratePerWeek is constrained by channel limits and engine capability, and key is an upsert selector whose change affects rate or brief, which the schema states only tersely.

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?

The description opens with a specific verb and resource ("Start or change a stream") and immediately defines the noun: "standing work that runs at a rate instead of a one-off task." It names the two siblings it is distinct from (stream_stop, work_plan), so an agent can route without opening either schema.

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?

Explicit when-to-use is given (recurring work defined by a rate per week), plus explicit alternatives: "stream_stop ends one; a one-off piece is work_plan." It also states the upsert condition ("Setting an existing key changes its rate or brief"), which removes ambiguity about create-vs-update.

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.