Marsell

Set goal

set_goal

Sets the business's goal: the one outcome the plan works toward, counted by Marsell (GitHub stars, sign-ups, bookings, money raised, sales). words: the owner's own words, read by a small model (a few tokens) into what it counts, the target and the day; when they name no amount or could mean two goals, nothing is set and the answer says what was understood, so ask the owner again. use_suggestion: the owner takes Marsell's suggestion as it is. situation_read goal shows the goal now. It needs an act key.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "set_goal"
  }
}

Input Schema

Name	Required	Description
`words`	No	the owner's goal in their own words, exactly as they said it: '500 stars by Christmas', '20 tours a week this summer', '$5k a month'
`project`	No	The project's id or exact name. Optional when the account has one project.
`owner_words`	No	The owner's own words, exactly as they said them: what an argument ending in _from_message keeps.
`use_suggestion`	No	true when the owner takes Marsell's suggested goal as it is
`words_from_message`	No	true when the owner's goal is the message they just sent: it is read exactly as sent, so you never retype it

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations only say this is a non-read-only, non-destructive, closed-world write. The description adds real behavioral value beyond that: ambiguous or amount-less input results in nothing being set and an answer describing what was understood, so the owner must be asked again. It also mentions an 'act key' precondition, though without explaining what that is or where to get it.

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 is front-loaded and no sentence is pure filler, but the prose is run-on and uses bare labels ('words:', 'use_suggestion:', 'situation_read goal shows the goal now') instead of complete clauses, which costs readability. It is dense rather than efficient.

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?

The failure semantics and the read-alternative are covered, and the schema documents all five parameters. What is missing is the relationship between parameters: with zero required fields, an agent needs to know that words/words_from_message/use_suggestion are alternative input modes and that project is only conditionally needed. The dangling 'act key' requirement is also left undefined.

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 baseline is 3, but the description goes further: it explains that 'words' is parsed by a small model into what is counted, the target, and the day, and that 'use_suggestion' means the owner adopts Marsell's suggestion unchanged. The unexplained 'act key' mention does not map to any declared parameter, which slightly muddies rather than clarifies.

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

Purpose4/5

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

States a specific verb and resource: 'Sets the business's goal: the one outcome the plan works toward', and even defines what counts (stars, sign-ups, bookings, money, sales). It distinguishes itself from the read path by naming situation_read, though the telegraphic 'words:'/'use_suggestion:' labels make the core statement harder to parse than it needs to be.

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

Usage Guidelines3/5

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

It implies two invocation modes (owner's own words vs. accepting Marsell's suggestion) and points to situation_read for viewing the current goal, which is genuine routing guidance. However, it never states when this tool should not be called, nor which of the five parameters are mutually exclusive in each mode, leaving the agent to infer the selection logic.

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.