Skip to main content
Glama
Sign In

Marsell

by com.getmarsell
OverviewDiscussionsAdmin

Work plan

work_plan

Add tasks to the calendar, each in the plan's task contract (key, title, kind, channel, brief, reason, date, goalKey, dependsOn, engine, executor, verification, expected, cost), dated on a day of the horizon (situation.horizon). A task under an open slot's key (situation.slotsDue, situation.calendar.slots) firms that slot: it becomes the slot's full task. Up to 2 new tasks a run beside the slots it firms. Work Marsell makes (executor marsell) is one of these kinds on its engine: board on content, video on content, image on content, article on content, comparison on content, gbp_post on content, script on content, audit on content, prospect_list on content, concept on content, carousel on content, landing_section on content, repo_page on content, launch_kit on content, release_notes on content, list_entry on content, share_kit on content, day_kit on content, original on content, cut_list on content, post on social, reply_drafts on community, pitch on community, reply_inbox on community, reddit_post on community, answer_audit on search, ad_test on paid, create on convert, sequence on convert, site on sites, landing on sites. A job for the owner's own AI is kind homework on engine homework with executor agent, its brief the whole job, and only while their AI can take homework. Anything else is a two-minute owner action (kind fix or connect, executor owner_2min). They are checked against the playbook, the connections and each seven-day window: the tasks that pass are written, and the ones refused come back with why, to send again alone, fixed. Returns the new work ids, the slots firmed, the keys already on the calendar (the same piece, never a second one) and the tasks refused. A later day is a slot instead (slot_add); a running series of the same work is a stream (stream_set). 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": {
      "tasks": "<tasks>",
      "rationale": "<rationale>"
    },
    "name": "work_plan"
  }
}

Input Schema

NameRequiredDescriptionDefault
tasksYesOne or more tasks in the plan's task contract, each fully filled in.
projectNoThe project's id or exact name. Optional when the account has one project.
rationaleYesWhy these tasks now, in plain words; the owner reads it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / tasks / items / properties / reason / description
      Previous value: -"Why it is on the plan, in one short plain sentence addressed to the owner as 'you' (never 'the owner'): the offer, people, goal or date it serves, or what it makes possible. Never the title again, never Marsell's own workings (a weekly minimum, a free day, an engine), and no 'today' or 'this week': the owner may read it days later."New value: +"The line the owner reads under this task's title. In one short plain sentence said to them as 'you' (never 'the owner'), what it is for: the offer, people, goal or date it serves, or what it makes possible. Never Marsell's own workings or how the task came to be planned (a playbook, a weekly count or minimum, an 'Ask N' label, a retry, a free day, an engine), never the title again, and no 'today' or 'this week': it may be read days later."
  2. Changed1 schema field changed
    • addedInput schema / properties / tasks / items / properties / reason / description
      Added value: +"Why it is on the plan, in one short plain sentence addressed to the owner as 'you' (never 'the owner'): the offer, people, goal or date it serves, or what it makes possible. Never the title again, never Marsell's own workings (a weekly minimum, a free day, an engine), and no 'today' or 'this week': the owner may read it days later."
  3. Changed1 schema field changed
    • addedInput schema / properties / tasks / items / properties / profileChange
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "becomes": {
+            "description": "The whole part after the change, written out in full. When now is null: only the exact words to add, or the piece to replace and where it goes; or, when the owner asked for it, the whole new name or bio as they asked.",
+            "minLength": 1,
+            "type": "string"
+          },
+          "channel": {
+            "description": "The platform, as input.profiles names it (instagram, facebook, linkedin, tiktok, youtube…).",
+            "minLength": 1,
+            "type": "string"
+          },
+          "handle": {
+            "description": "The account's handle as input.profiles names it, without @; null when the account is not connected.",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "now": {
+            "description": "The whole part exactly as input.profiles gives it when its state is read, character for character with its punctuation, line breaks and emoji; \"\" when it was read empty; null when its state is anything else, for pinned posts, and when the account is not connected.",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "ownerAsked": {
+            "description": "True only when input.ownerAsks or a rule in input.memory asks for this new name or bio in the owner's own words.",
+            "type": "boolean"
+          },
+          "part": {
+            "description": "Which part of the profile changes: name is the display name, never the @handle.",
+            "enum": [
+              "name",
+              "bio",
+              "link",
+              "pinned",
+              "other"
+            ],
+            "type": "string"
+          },
+          "until": {
+            "anyOf": [
+              {
+                "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "description": "When becomes adds a line that holds a date (a drop, an event, a deadline): its last day, YYYY-MM-DD; the plan then holds the task or slot that takes it out within the week after. Null otherwise."
+          },
+          "why": {
+            "description": "Why, in one or two plain sentences: what the change does for the business, what is cut to fit the limit, and why any line of its own that goes should go.",
+            "minLength": 1,
+            "type": "string"
+          }
+        },
+        "required": [
+          "channel",
+          "handle",
+          "part",
+          "now",
+          "becomes",
+          "why",
+          "ownerAsked",
+          "until"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "For a task that changes the name, bio, link or pinned items of one of the business's own profiles: each part it changes, with its text now (from input.profiles) and its new text. Null for every other task."
+}
  4. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond readOnlyHint=false and destructiveHint=false, the description explains slot-firming, the two-task cap, validation against the playbook, connections and seven-day windows, partial acceptance with refusal reasons, duplicate-key prevention, and the return contents. It also notes the act-key requirement.

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?

The purpose and main constraints are front-loaded, but the description is a dense block and the long 'kind on engine' enumeration is difficult to scan. That list carries useful mapping, yet as prose it is not concise and could be structured more clearly.

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 complex mutation with no output schema, the description covers the input contract, limits, alternatives, validation and failure behavior, authorization requirement, and what is returned. The rich schema supplies per-field detail, so no material invocation information appears to be missing.

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 per-field meaning is largely handled by the schema and the baseline is 3. The description adds useful interpretation: the task-contract context, the mapping of kinds to engines and executors, slot-key semantics, and the horizon-date rule. It adds little for extended fields such as label, series, buildsOn, pictures or profileChange, which remain schema-only.

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 opening sentence gives a specific verb and resource: add tasks to the calendar, each in the plan's task contract and dated within the horizon. It also names sibling alternatives slot_add and stream_set, so the agent can distinguish this tool from slot and stream operations.

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?

It states when to use it: creating new tasks within the horizon, up to two beside the slots it firms. It also gives explicit alternatives and exclusions: a later day is slot_add, a repeated series is stream_set, homework applies only while the owner's AI can take homework, and other work is an owner_2min action.

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

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