Skip to main content
Glama

Sellular

generate_review

Generate a competitor review article for one of your apps, named by its website (product_url, e.g. "sparkmobile.dev") or its id. Asks you to confirm the website and optionally name its rivals, then runs live competitor research (Tavily), writes the article and (optionally) builds a head-to-head comparison table. Returns a preview link and the name of the editor it is waiting on. The article is NEVER published by this tool: it is submitted to a Sellular editor for approval (the editor is emailed) and only goes live at /reviews/[slug] once that editor approves it. Requires a paid plan (starter+) and counts against the monthly review generation quota. Authenticate with either your product API key (Dashboard -> Analytics -> API key), which names the product on its own, or the admin key plus product_id. TO WRITE THE ARTICLE YOURSELF: call once with brief_only=true to get the researched feature matrix and the full writing brief, then call again passing your article as draft. That skips the built-in writer entirely and is the better article, because you are already holding the comparison. The editor approval step is identical either way. TO DRAFT WITHOUT SUBMITTING: add hold_as_draft=true and the article is saved as a dashboard draft instead, with no editor involved; the owner reads it at the dashboard and submits it from there when happy.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
draftNoYour article, written from a brief_only call. Supplying it skips the built-in writer: the comparison table, the strengths and weaknesses cards, the quality score and the editor hand-off all run exactly as they otherwise would. Prose fields together should run 320 to 480 words.
fillsNoAnswers for rows the research could not confirm from your site, as {"Feature name": "value"}, e.g. {"MCP tools": "Yes"}. Authoritative: you know whether you ship the thing, and a dash next to three ticks reads as a missing feature rather than a missing fact. Use the row names exactly as they come back from brief_only.
rivalsNoCompetitors to compare against, comma separated, instead of whatever a live search turns up. You know your own market better than a listicle does.
researchNoThe extracted research JSON, when a previous call handed you the extraction prompt instead of running it. This server never calls an AI model on your behalf: you are the model. Pass back exactly the JSON object the prompt asked for.
brief_onlyNoResearch only: return the competitors, the verified feature matrix and the full writing brief, and write nothing. Nothing is saved, no quota is spent and no editor is involved. Follow it with a second call passing `draft`.
product_idNoWhich product to review, by id. Ignored with a product API key. Prefer product_url, which is how people name their own app.
product_urlNoWhich product to review, by website, e.g. "sparkmobile.dev". Matched by domain against the products on the account, ignoring www and the scheme. Ignored with a product API key.
hold_as_draftNoSave the article as a dashboard draft and stop: no editor is picked, nobody is notified. The owner reviews it at the dashboard (Reviews view) and submits it from there, where the same publish benchmark applies. Still spends the generation (one review per app), so use it when a human should read the article before any editor does.
include_comparisonNoInclude the head-to-head comparison table (research runs either way).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description fully carries the behavioral burden. It discloses that the article is never published, goes to an editor for approval, requires a paid plan and quota, supports auth via product API key or admin key, and explains side effects of brief_only and hold_as_draft.

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

Conciseness5/5

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

Although long, the description is appropriately sized for a complex tool with nine parameters and multiple workflows. It is front-loaded with the core purpose and uses clear all-caps section markers like TO WRITE THE ARTICLE YOURSELF and TO DRAFT WITHOUT SUBMITTING to organize dense but necessary content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, lack of output schema, and interconnected parameters, the description is remarkably complete. It covers auth, quota, editor approval, draft holding, custom rivals, research extraction, comparison table control, and the return artifact (preview link and editor name).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/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 substantial meaning beyond the schema: it explains the product_url matching rules, the brief_only-to-draft flow, the research JSON pass-back mechanism, the fills semantics, and the quota implications of hold_as_draft.

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?

The description states a specific verb and resource: generating a competitor review article for an app identified by product_url or id. It clearly distinguishes itself from sibling tools like generate_seo_fixes and list_my_reviews by describing the article generation workflow and editor hand-off.

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?

The description provides detailed usage modes: normal generation, brief_only followed by draft, hold_as_draft, and auth requirements. It explains when to use these modes and their consequences, though it does not explicitly contrast with sibling tools or list exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources