Skip to main content
Glama

create_comparison_page

Generate a comparison or 'X vs Y' page for your brand, using research mode to crawl competitors or simple mode to write from your own data.

Instructions

Create a comparison / 'X vs Y' / 'best ' page for the brand WITHOUT going through the full SEO cluster → brief flow. One call kicks off generation and returns quickly with an operationId and a 'still_generating' or 'completed' status — it does NOT block until the page is fully built. mode controls the engine: 'research' crawls the named competitors + live SERP results before writing — slower (can take several minutes) but produces the strongest, best-grounded page; 'simple' skips all crawling and lets the LLM author from what you provide — fast, best when you already have the facts or just want a quick draft. When your inputs are sparse (few/no options, no domains, no seedData), prefer 'research' — it will discover and ground the comparison for you and yield a far stronger page than 'simple'. seedData (simple mode): paste your own raw facts/notes/competitor details here and the LLM writes from them instead of crawling — this is how you feed your own data and avoid a crawl. Async — fires the create, then waits only a short grace window before responding. On success returns { briefId, sidePageId, sidePageSlug, landingPageSlug, webUrl, warnings }. If it is still running past the grace window, returns { status: 'still_generating', operationId } — poll get_job with that operationId until state is 'completed'; do NOT fabricate the page yourself, and do NOT call create_comparison_page again for the same request while it's pending. Any warnings are surfaced verbatim — relay them to the user (e.g. sparse-input notes such as 'research mode would produce a stronger page').

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeYesGeneration engine. 'research' = crawl the competitors + live SERP, then write (slower, strongest, best for sparse inputs). 'simple' = no crawl, LLM authors from what you pass (fast; pair with seedData to feed your own facts).
presetNoPage shape: head_to_head (X vs Y), alternatives_listicle (X vs alternatives), or category_roundup (best <category>). Inferred when omitted.
brandIdNoBrand ID (defaults to active brand)
optionsNoThe things being compared. Omit to let research mode discover them.
seedDataNoSimple-mode only: your own raw data/notes/facts about the options. When set, the LLM writes from this instead of crawling — feed it here to avoid a research crawl.
briefDataNoAdvanced: a full pre-built structured comparison brief. When supplied, generation uses it directly and skips the LLM authoring step.
proposedSlugNoDesired URL slug fragment for the new page (auto-generated from primaryKeyword if omitted).
primaryKeywordYesThe topic/keyword the page targets, e.g. "Acme vs alternatives", "best CRM for startups", "Notion vs Obsidian".
voiceProfileIdNoVoice profile ID to write the page in.
pinnedCompetitorNoA specific competitor to anchor a head-to-head comparison around.
allowGenericRoundupNoAllow a generic category roundup when no concrete options are supplied.
parentLandingPageSlugNoSlug of the parent landing page to nest this comparison under. Defaults to the brand's primary landing page.
Behavior5/5

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

No annotations are provided, but the description thoroughly discloses the async nature (returns quickly and does not block), explains what happens in each status case, warns against fabricating the page or re-calling, and surfaces that warnings are passed verbatim. It also describes the behavioral difference between research and simple modes in detail.

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 description is long, but every sentence provides essential operational detail (async behavior, mode semantics, input strategies, return values). For a tool with this complexity, the length is justified and the content is organized with clear separators (hyphens and semicolons). It is front-loaded with the core purpose.

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 no output schema and 12 parameters, this description fully covers behaviors, return values in both success and pending scenarios, parameter usage guidance, and error handling (poll get_job, don't fabricate, don't re-call). It leaves no major gaps for an agent invoking this tool.

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?

The input schema already describes all 12 parameters with 100% coverage, so the baseline is 3. The description adds extra meaning for key parameters: mode (explains crawl vs no-crawl tradeoff), seedData ('this is how you feed your own data and avoid a crawl'), and options (omit to let research mode discover them). This goes beyond the schema's property descriptions.

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 opens with a specific verb ('Create') and resource ('comparison / X vs Y / best <category> page for the brand'), and explicitly distinguishes itself by saying 'WITHOUT going through the full SEO cluster → brief flow'. This clearly identifies what the tool does and differentiates it from the standard SEO flow.

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 explicitly contrasts the two modes ('research' vs 'simple'), gives guidance for when to choose each: 'When your inputs are sparse... prefer research' and 'simple... best when you already have the facts or just want a quick draft'. It also tells the agent not to call again while pending and to use get_job instead, which are clear when/when-not directives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bitsandtea/postking-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server