Skip to main content
Glama
Sign In

Marsell

by com.getmarsell
OverviewDiscussionsAdmin

Send the posts scheduled elsewhere

scheduled_posts_sync
Destructive

Tells Marsell every post the business has scheduled outside Marsell in a window (from to to): in another tool, a sheet or on the platforms themselves. Posts the owner already has scheduled (a launch calendar, a content calendar, a list of what is live and scheduled) go here, one entry per post, not into a guide, a brand file or setup notes: this list is what the planner plans around. Marsell then plans nothing that goes out as a post on a channel and day one of them holds, never a second piece doing the same job (a second announcement or save-the-date), and never the same subject that week. Send the whole list for the window each time, each post with its own ref (your id for it, the same every time). Sending it again updates the posts instead of adding them twice, and a post in the window you no longer list is taken off as cancelled. A post that already went out stays as it went out. Posts Marsell itself made never go in this list. Free: it spends no tokens.

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": {
      "from": "<from>",
      "to": "<to>",
      "posts": "<posts>"
    },
    "name": "scheduled_posts_sync"
  }
}

Input Schema

NameRequiredDescriptionDefault
toYesThe window's last day, YYYY-MM-DD (or a time). Every post you send may fall in it or not; only posts inside it are taken off when missing.
fromYesThe window's first day, YYYY-MM-DD (or a time, 2026-10-20T00:00:00Z).
postsYesEvery post scheduled outside Marsell in the window. An empty list takes off every post you sent before for that window.
projectNoThe project's id or exact name. Optional when the account has one project.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Goes well past the destructiveHint=true annotation by explaining precisely what is destructive: a resend upserts rather than duplicates, a post in the window that is no longer listed is treated as cancelled, and a post that already went out stays as it went out. It also discloses cost ('spends no tokens') and that Marsell will not double-book the same channel/day or subject.

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?

Purpose is front-loaded, but the prose is long and runs together: the parenthetical '(a launch calendar, a content calendar, a list of what is live and scheduled)' and the sentence about Marsell planning 'never a second piece doing the same job' restate the same idea at length. For a four-parameter tool this could be tightened considerably without losing any operative rule.

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?

For a destructive sync tool with no output schema, the description covers semantics, idempotency, cancellation and cost thoroughly. The remaining gap is the response: nothing says what comes back (counts added/updated/cancelled, or errors on invalid refs), which an agent would want after a destructive call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents from, to, posts, project and every nested post field. The description reinforces the ref-stability rule and the full-list-per-window contract, but both are already stated in the schema text ('the same every time you send it', 'An empty list takes off every post you sent before'). Baseline 3 is right — it adds emphasis, not new meaning.

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 with scope: tells Marsell about every post the business has scheduled outside Marsell within a from/to window. It names the excluded artifacts (guide, brand file, setup notes) and the sibling concept of Marsell-made posts, so an agent can separate this from scheduled_posts_read/scheduled_posts_remove without opening a 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 routing rules: external scheduled posts go here, one entry per post, and 'Posts Marsell itself made never go in this list.' It also states the cadence requirement ('send the whole list for the window each time'), which is the key when-to-call condition, and names the wrong destinations to avoid.

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