Marsell

Discovery read

discovery_read

Read-only

Reads what discovery found for this business, one part at a time. Every answer carries frame: what buyers choose it for (lookingFor, the inferred phrases among them, category, place, who its buyers, fans and peers are, compared: rivals on file, comparedGuesses: unverified names that are never rivals to state). communities: where its buyers gather, with platform, url, fit, activity, frameShare (the share of recent posts about the frame), audience (buyers could buy; fans are into what buyers choose it for and share more than they shop; peers make or run the same kind of business and are not buyers) and a promotion note (forbidden means never plug the business there). threads: untouched conversations asked in the last 14 days, with age, fit and a draft reply. competitors: rivals with pricing and positioning. themes: questions and complaints raised by two or more threads, each with a content angle. Ground finished work in these.

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": {
      "part": "<part>",
      "limit": "<limit>"
    },
    "name": "discovery_read"
  }
}

Input Schema

Name	Required	Description
`part`	Yes	communities, threads, competitors or themes, as above.
`limit`	Yes	The most items to return, in discovery's own order (threads best fit first, themes most raised first).
`project`	No	The project's id or exact name. Optional when the account has one project.

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 already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds genuinely useful behavioral facts: reads are scoped to a single part per call, threads are limited to untouched conversations from the last 14 days, and returned order is meaningful. It says nothing about freshness of the other parts, caching, or result size caps beyond the limit parameter, which is the remaining 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 purpose is front-loaded, but the body is a single dense block with heavily nested parentheticals (audience definitions, frameShare, promotion notes) that would read far better as a per-part list. The information is useful, yet the packing makes it slow to parse at selection time.

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 carries the burden of describing return content, and it does so thoroughly for all four parts, including field-level semantics like frameShare and audience roles. Only the absence of any note on default project behavior or response size makes it short of complete.

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 the baseline is 3. The description does add value by unpacking what each enum value of `part` contains (frame fields, communities with fit/activity/frameShare, competitors with pricing, themes with content angle), but it adds nothing about `limit` or `project` beyond what the schema already says.

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 ('Reads what discovery found for this business, one part at a time') and enumerates the four parts, so an agent knows exactly what domain data comes back. It doesn't explicitly distinguish itself from near-neighbors like business_context_read, situation_read, or get_market, which is the only thing keeping it off a 5.

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?

'Ground finished work in these' is a real usage cue, telling the agent to pull this before producing content, and 'one part at a time' implies repeated calls per part. But there is no when-not guidance and no routing to alternatives among the many sibling read tools, so the selection logic is only implied.

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.