Marsell

Business read start

business_read_start

Starts reading the business again from the web, as business_read_quote priced it: setup's own read of its address and pages, on the owner's tokens. Only after you said the price from business_read_quote and the owner said yes to it in the message you are answering now; refused in the same message as the quote, without a quote, or when the price moved since (quote again). Nothing it finds counts until the owner confirms it on the review. It needs an act key, and spends the owner's tokens as the chat's same tool would: say the price before you spend.

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": {
      "yes_from_message": "<yes_from_message>"
    },
    "name": "business_read_start"
  }
}

Input Schema

Name	Required	Description
`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.
`yes_from_message`	Yes	true: the owner's message you are answering is their yes to the price business_read_quote gave, said to them in your last reply

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations say readOnlyHint=false and openWorldHint=true but reveal nothing about cost or gating; the description supplies both — it spends the owner's tokens, requires an act key, and its results are provisional until the owner confirms on the review. That is exactly the behavioral context an agent needs before invoking a paid, non-read-only operation.

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?

Effectively three sentences with no filler and the purpose front-loaded ahead of the preconditions and cost warning. The middle sentence stacks several nested clauses ('refused in the same message as the quote, without a quote, or when the price moved since'), which costs some readability but every clause carries a real condition.

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?

Covers what the agent must verify before calling, what it will cost, and that output is provisional pending review, which is the essential picture for a paid open-world operation with no output schema. It stops short of saying how the agent later checks progress or submits the review, so a small follow-up gap remains.

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 project, owner_words, and yes_from_message are already documented, including the const:true constraint. The description reinforces the gating semantics of the yes flag (the yes must be in the message being answered) but adds no new syntax or format detail, and its mention of an 'act key' refers to nothing in the schema, which could confuse rather than clarify. Baseline 3 applies.

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 action (start reading the business from the web) and ties it to the sibling that prices it ('as business_read_quote priced it'), so an agent can distinguish the quote step from the execution step. The phrasing 'setup's own read of its address and pages, on the owner's tokens' adds scope, though the sentence's density makes the core purpose slower to extract than it should be.

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?

Gives explicit when-to-use conditions ('only after you said the price ... and the owner said yes to it in the message you are answering now') and explicit refusal conditions ('refused in the same message as the quote, without a quote, or when the price moved since (quote again)'). The alternative path (re-quote via business_read_quote) is named with its trigger.

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.