Skip to main content
Glama
Sign In

Mondovo

by com.mondovo.app
OverviewDiscussionsAdmin

Make competitor alternative pages

generate_alternative_pages
Idempotent

Have our AI write one honest comparison page per competitor, for people searching " alternative": who should switch and who should stay, a side-by-side comparison, other alternatives, and FAQs, in the site's design at /alternatives/, with the SEO title and target keywords set. Nothing invented about the competitor. At most 5 per call; run plan_alternative_pages first and confirm the list with the user. Pages are added unlinked from the menu and nothing is live until publish_site. Returns a job_id; poll get_job (~1 minute per page). Counts as AI refinements. ON A SITE THAT STILL HOLDS SEVERAL DESIGNS this builds the site: Mondovo copies the chosen design into the working site (or reuses the copy made earlier), adds to that, and the response carries its new site_id and a build_transition — relay its tell_user and use the new site_id from then on. Pass variation_id for the design the user picked; omitted, Mondovo uses the design already built or the only one edited, and otherwise answers choose_design so you can ask the user.

Input Schema

NameRequiredDescriptionDefault
site_idYesThe site, from list_sites
user_goalNoOptional: the user's goal behind this call, in one short sentence of plain words (e.g. "add a page so customers can book tables"). No names, emails or other personal details.
competitorsYes
variation_idNoOn a site that still holds several designs: the design to build the site from (from list_variations). Mondovo copies it into the working site and adds to that. Omit on a site that is already built.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / user_goal
      Added value: +{
+  "description": "Optional: the user's goal behind this call, in one short sentence of plain words (e.g. \"add a page so customers can book tables\"). No names, emails or other personal details.",
+  "type": "string"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / variation_id
      Added value: +{
+  "description": "On a site that still holds several designs: the design to build the site from (from list_variations). Mondovo copies it into the working site and adds to that. Omit on a site that is already built.",
+  "maxLength": 200,
+  "type": "string"
+}
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations: pages are added unlinked from the menu, nothing is live until publish_site, the call is asynchronous (returns job_id, poll get_job, ~1 minute per page), and it consumes AI refinements. It also discloses the multi-design transition: a new site_id and build_transition come back and must be relayed.

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 is front-loaded and nearly every sentence earns its place, but the definition is dense — the all-caps multi-design paragraph and the parenthetical poll timing compress a lot into one block, and the capitalized warning could be integrated more cleanly.

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?

There is no output schema, yet the description covers the async return contract (job_id, get_job, ~1 minute per page), the multi-design site_id/build_transition relay, and the `choose_design` response. Nothing an agent needs to invoke and follow up correctly 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 75%, and the description still adds real meaning the schema lacks — the competitors list cap of 5, the 'nothing invented' constraint on competitor content, and the full variation_id selection semantics when the site holds several designs. user_goal and positioning remain unexplained, which is minor.

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?

States a specific verb and resource — AI-written competitor comparison pages, one per competitor, at /alternatives/<competitor> — and enumerates the exact content sections and SEO fields produced. This is clearly distinguishable from siblings like add_page or bulk_generate_service_location_pages.

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?

Explicitly requires running plan_alternative_pages first and confirming the list with the user, caps throughput at 5 per call, and explains the variation_id decision tree including the `choose_design` fallback. It also names publish_site as the gate for going live, so alternatives are covered.

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

All Mondovo toolsInspect
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.

Resources