Marsell

Read a page draft

site_draft_read

Read-only

Reads the project's pages that are not live yet (its site, its landing pages: a draft never published, or a newer version of a live page waiting for its yes). Without version_id it lists them; with one, it reads that version whole from its own files: each page's title, description and its words in order (headings as #, list items as -, links as words, pictures as alt , buttons and fields named, its regions such as [header] and [footer]), what the checks found, and its full-page pictures at a laptop's and a phone's width. A draft's address opens only from inside Marsell, so this is how you read it. Nothing is published: publishing is the owner's yes on the page's card (card_read). Each landing page with what making it again or changing it costs is pages_read. The owner's yes on a card is given in their name with answer_decision.

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

Input Schema

Name	Required	Description
`project`	No	The project's id or exact name. Optional when the account has one project.
`pictures`	No	true to get the pictures themselves as images beside the answer (Marsell's own pictures); otherwise their addresses, which you can open.
`version_id`	No	One version to read whole, by its id from this tool's list or a card's pages. The list of drafts when left out.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint true, destructiveHint false, openWorldHint false), and the description adds genuinely new behavior: nothing is published by this call, drafts are inaccessible externally, and the read returns rendered content structure (headings, links, pictures, named buttons/fields, regions) plus check results and two-width full-page screenshots. It does not say whether the list is bounded or paginated, which is the remaining behavioral gap.

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 main mode distinction is front-loaded, but the second sentence is a long run-on with stacked parentheticals (page structure, regions, checks, screenshots) that is harder to parse than needed. Colorful phrasing like 'waiting for its yes' and 'its words in order' costs clarity without adding callable detail.

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?

With no output schema, the description does the work of explaining what comes back: page title, description, ordered text, rendered regions, check results, and screenshots. For a three-optional-parameter read tool this is close to complete; only list scope (how many drafts, ordering, pagination) is left unspecified.

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 each of the three parameters is already documented in the schema, including the list-versus-single-version behavior of version_id. The description's version of that distinction largely restates the schema and adds no syntax, id format, or default guidance beyond it, so baseline 3 applies.

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 (reads the project's not-yet-live pages) and immediately splits the two modes: list without version_id, full read of one version with it. It also names the siblings that do the adjacent jobs (card_read for publishing, pages_read for landing-page costs, answer_decision for the owner's yes), so an agent can place it precisely.

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 about when this tool is the only option: a draft's address opens only from inside Marsell, so this is how you read it. It also states what is NOT done here (publishing is the owner's yes on the card, card_read) and routes cost/make-again questions to pages_read.

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.