Marsell

Business context change

business_context_change

Destructive

Changes the business context. Named fields replace what is there and cost nothing. rules replaces the brand's design rules, which every picture writer follows above any brief. words keeps the owner's own words about the brand whole; they outrank everything else and every film director reads them. rebuild true rewrites every field from the owner's words (the ones given now, else the ones on file) and everything Marsell knows: one model call, about 1,200 tokens; use it when the owner pastes their brief or says the context is wrong about the brand. 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": "business_context_change"
  }
}

Input Schema

Name	Required	Description
`avoid`	No	what never to show or say; replaces the list
`rules`	No	the brand's design rules, one each, as the owner or their guide states them; replaces the rules (business_context_read designRules) and keeps the owner's other words as they are
`words`	No	the owner's own words about the brand, exactly as they wrote them, never a summary
`motifs`	No	recurring things; replaces the list
`imagery`	No	how pictures of this business look: photographs, illustration, screens
`project`	No	The project's id or exact name. Optional when the account has one project.
`rebuild`	No	true rewrites every field from the owner's words and everything Marsell knows (one model call, spends tokens); fields named beside it win over what it writes
`summary`	No	the design language in plain sentences; replaces what is there
`aesthetics`	No	aesthetics by their common names; replaces the list
`owner_words`	No	The owner's own words, exactly as they said them: what an argument ending in _from_message keeps.
`words_from_message`	No	true when the owner's words are the message they just sent: it is kept exactly as sent, so you never retype it

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, so the mutation profile is known. The description adds real context beyond that: named fields replace existing values, precedence ordering (rules outrank any brief; words outrank everything), the cost of rebuild (one model call, about 1,200 tokens), and an auth requirement ("It needs an act key"). The act-key statement is slightly confusing because no such parameter exists in the schema, but it is disclosed rather than contradicted.

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 and replacement semantics are front-loaded, which is good, but the prose is padded with decorative clauses ("which every picture writer follows above any brief," "every film director reads them") that lengthen the text without sharpening the decision. The rebuild sentence packs cost, source selection, and trigger conditions into one long run-on.

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 an 11-parameter destructive mutation with no output schema, the description covers the critical ground: replacement semantics, rebuild scope and cost, field precedence, and the act-key requirement. It stops short of saying whether unnamed fields are preserved when `rebuild` is false and does not describe what the call returns, but neither omission would likely cause a miscall.

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 alone sets a baseline of 3. The description earns above that by supplying precedence and downstream-effect semantics not present in the schema: `rules` is what every picture writer follows above any brief, and `words` outranks everything and is read by film directors. It also clarifies the interaction between `rebuild` and explicitly named fields.

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?

The opening states a specific verb and resource ("Changes the business context") and the following sentences make clear it is the write counterpart to business_context_read, covering field replacement and full rebuild. It is distinguishable from siblings, though the bare first sentence alone is close to a restatement of the name and only the detail sentences do the differentiating work.

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 gives explicit trigger conditions for the rebuild path: "use it when the owner pastes their brief or says the context is wrong about the brand," and contrasts it with the cheap named-field path ("cost nothing"). What is missing is guidance on when to call this at all versus reading context first, or how to choose between `words` and `words_from_message` when both are available.

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.