Skip to main content
Glama
Sign In

Marsell

by com.getmarsell
OverviewDiscussionsAdmin

Fill in the business's words

fill_setup
Destructive

Writes the business's words into the setup (name, what it is, who it's for, offerings, pricing, voice and the rest of get_setup's answers_fields), its colours and its headline and body fonts. Write as much as each answer needs. Call again to change one; an answer sent empty clears the one on file. Fill name and description first: the project that holds files is made from them. A font family Marsell doesn't ship is fetched from Google Fonts when Google has it; otherwise send its file with add_font.

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": "fill_setup"
  }
}

Input Schema

NameRequiredDescriptionDefault
answersNoAnswers by field.
paletteNoEvery brand colour, the main one first.
body_fontNoThe body font's family.
display_fontNoThe headline font's family. Bricolage Grotesque, DM Sans, Geist, Geist Mono ship with Marsell.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already flag destructiveHint and openWorldHint, and the description adds concrete substance beyond them: an empty answer deletes the stored value, name/description trigger creation of a project, and unknown font families are fetched from Google Fonts with add_font as the fallback. These are exactly the side effects an agent needs before calling a destructive write.

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

Conciseness4/5

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

Front-loaded with the core action, then ordering advice, then the font caveat — a sensible priority order with no filler. The middle sentence is dense and slightly run-on, but every clause carries information.

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, open-world write with a large nested schema and no output schema, the description covers side effects, ordering constraints, clearing semantics and external font resolution. It leaves partial-failure behavior and merge-vs-replace semantics unstated, which is a modest gap rather than a blocking one.

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 adds semantics the schema lacks: answers are per-field and can be written incrementally, empty means clear, and font families not shipped by Marsell are resolved externally. It does not clarify whether the answers object merges or replaces, which is the one remaining ambiguity.

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 ('Writes the business's words into the setup') and enumerates the covered fields, then extends scope to colours and fonts. It explicitly distinguishes itself from siblings by naming get_setup (source of the field list), add_font (font fallback) and implicitly add_products/add_rivals via the schema notes.

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?

Gives real operational guidance: call again to change a single answer, empty string clears, and fill name/description first because the file-holding project is derived from them. It also names the alternative path for fonts (add_font). It does not address when to use this versus finish_setup or remove_from_setup, so it stops short of full when/when-not coverage.

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