Skip to main content
Glama

generate_review

Idempotent

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

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.4/5.0
Behavior3/5

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

The annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the mutation and external-call profile is partly covered — but the description goes well beyond with the publish guardrail ("NEVER published by this tool"), the editor email hand-off, the /reviews/[slug] destination, plan gating and quota spend. The one weak spot is a tension with idempotentHint=true: each call "counts against the monthly review generation quota" and "still spends the generation", so repeating a call appears to have a cost the idempotency hint does not convey. That is not a flat contradiction, but it is left unexplained.

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?

The purpose and the not-published guarantee come first, then modes, then auth and preconditions — good front-loading given the complexity. It is long and has some overlap between the `hold_as_draft` narrative and the schema description of the same parameter, but for a nine-parameter, quota-consuming, multi-step tool the length is largely earned.

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?

With no output schema, the description supplies the return values itself — preview link and the name of the waiting editor — and covers auth (product API key vs admin key plus product_id), plan requirement, quota cost and the approval lifecycle. Nothing an agent needs before calling it is missing.

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 schema already documents every parameter, and the baseline would be 3. The description earns the extra point by explaining the relationship between parameters that no single schema entry can show: brief_only produces the matrix, which feeds `draft` on the second call, and `draft` bypasses the built-in writer while keeping the comparison table, cards and editor hand-off.

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?

Opens with a specific verb and artifact — "Generate a competitor review article" — scoped to "one of your apps" identified by website or id. This is clearly distinguishable from siblings like generate_seo_fixes, list_my_reviews or generate_submission_kit, and it names the two identifier inputs up front.

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?

It spells out three explicit operating modes with the conditions that select each: brief_only for a human/model-written article, hold_as_draft to skip editor involvement, and the default submit-for-approval path. It also says when to use `rivals` (overriding live search) and `fills` (rows research could not confirm), plus the paid-plan and quota preconditions.

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