Marsell

Tell Marsell your homework schedule

homework_schedule

Records the pulling schedule the owner confirmed for you: the timer you set yourself with your own app's scheduler to wake you and do what Marsell has for you. That is homework (homework_list, when it is one of your tools) and, where the owner said yes to you sending on Reddit, X or LinkedIn, missions (missions_next), which need a wake every hour from 9 in the morning to 9 at night on the computer where the missions profile is (a separate browser profile signed in only to Reddit, X and LinkedIn, never to email or banking). timer_prompt, from homework_list, is its prompt; with a key for missions only, the line the owner pasted from Marsell is. Set the timer only on the owner's yes, then call this with on true, how often, what you set, whether it wakes you while the owner's app is closed and when it stops by itself. With on false, say why: the owner said no, or your app can't schedule. Call it again whenever the timer changes or stops. Marsell can't see your timer; it keeps what you say and shows the owner.

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": {
      "on": "<on>"
    },
    "name": "homework_schedule"
  }
}

Input Schema

Name	Required	Description
`on`	Yes	true: the owner said yes and you set the timer. false: no timer.
`why`	No	With on false: why (the owner said no; your app can't schedule).
`ends`	No	When it stops by itself, as an ISO date and time with its offset, if it does (a timer that lasts some days, or only while this conversation is open). Leave it out when it runs until removed.
`every`	No	With on: how often it wakes you, as you set it ("every day at 08:57", "every 3 hours from 9 to 18").
`timer`	No	With on: what you set, in a few words ("a routine on claude.ai", "a scheduled task in this app", "a cron job").
`project`	No	The project's id or exact name. Optional when the account has one project.
`wakes_closed`	No	With on: whether it wakes you while the owner's app or computer is closed.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

B3.3/5.0

Behavior4/5

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

Annotations declare this is a non-destructive write, and the description adds real behavior beyond them: 'Marsell can't see your timer; it keeps what you say and shows the owner' tells the agent this is owner-visible self-reporting rather than verified state, which materially affects how carefully it should report. It also defines the false branch as a required disclosure path. It does not say what happens on conflicting repeat calls beyond 'call it again whenever the timer changes', which is a minor gap.

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

Conciseness2/5

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

The description is a single rambling run-on with nested asides and dangling referents, notably 'with a key for missions only, the line the owner pasted from Marsell is', which never resolves into a complete clause. The operational instructions an agent needs (on true/on false behavior, re-call on change) are stranded at the end of the block instead of front-loaded. Substantial editing would be required before the sentences earn their place.

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 a 7-parameter write tool with full schema coverage and no output schema, the description covers the main things an agent needs: the trigger, the two on-branches, what to report, and that Marsell stores rather than observes the timer. But the discussion of timer_prompt and the separate missions browser profile is ambiguous enough that an agent could misread which value goes where, leaving the definition only adequately complete.

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 description coverage is 100% and every parameter already carries a clear description, so the baseline is 3. The description adds only light framing on top (on true means the owner said yes and the timer was set; on false requires a reason), and its attempt to explain inputs via timer_prompt and the missions key is vague rather than clarifying. No meaningful semantics beyond the schema are supplied.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The core action (record the timer/schedule you set) is stated, and the description distinguishes it from homework_list and missions_next by framing those as the sources of what is being scheduled rather than the thing being written. However, the purpose is buried inside a long clause chain ('Records the pulling schedule the owner confirmed for you: the timer you set yourself with your own app's scheduler to wake you and do what Marsell has for you'), so an agent must parse several sentences before it can state the tool's job plainly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Call conditions are explicit: set the timer only on the owner's yes, then call with on true; with on false, say why (owner said no, or your app can't schedule); call again whenever the timer changes or stops. That is unusually concrete when-to-call guidance. It stops short of 5 because no sibling is named as an alternative to use instead, so the agent is not told what to do when it has not set a timer at all.

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.