Skip to main content
Glama
Sign In

Mondovo

by com.mondovo.app
OverviewDiscussionsAdmin

Turn a built-in site feature on or off

manage_feature
Idempotent

Switch a built-in capability on or off: help center, job board, event registration, courses, directory, digital downloads, shopping cart, wishlists, comparison, sales funnels, payments, quizzes, booking and inquiry flows. Activating adds the feature's page and its content collection to the design; deactivating hides the page and keeps the content. Costs no credits. Announcement bars, popups and chat buttons are not features. 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
actionYes
featureYesThe capability. One of: saved_list_flow, native_cart, booking_request, booking_availability, help_center, inquiry_form, quote_request, quiz, comparison_builder, payment_collection, job_application, funnel_flow, template_catalog_apply, event_registration, directory_inquiry, course_enrollment, game_catalog, digital_delivery, form.
site_idYesThe site the collection belongs to
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.
content_keyNoRarely needed: the collection that backs it, when not its default (e.g. booking against "rooms").
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. Changed2 schema fields changed
    • changedInput schema / properties / variation_id / description
      Previous value: -"The design to install it into. Omit for the site's live design."New value: +"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."
    • addedInput schema / properties / variation_id / maxLength
      Added value: +200
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations, the description discloses concrete side effects: activation adds the feature page and content collection, deactivation hides the page while keeping content, and the call costs no credits. It also explains the multi-design build transition, the new site_id, and the build_transition handoff, which materially affects how the agent should proceed.

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 front-loaded and logically ordered: core toggle first, then side effects, exclusions, and the multi-design edge case. Its long feature enumeration partly duplicates the schema enum and makes it dense, but the complexity justifies most of the length.

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 still explains the unusual response fields for multi-design builds, including the new site_id and build_transition tell_user relay. Combined with the input schema and annotations, it gives an agent enough context to invoke the tool and handle the main branching case.

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 description coverage is high at 83%, so the schema already documents most parameters and establishes a baseline of 3. The description adds useful meaning for action outcomes, feature examples, and the omit-behavior for variation_id, but it does not discuss content_key or user_goal.

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 gives a specific verb and resource - switch a built-in capability on or off - and enumerates concrete features, so an agent can distinguish this feature-toggle tool from page-building or configuration tools. It also excludes announcement bars, popups, and chat buttons, which sharpens the boundary.

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?

It clearly frames activate versus deactivate behavior and gives a scenario-specific rule for variation_id on sites with several designs, including the choose_design fallback. It does not explicitly name when to prefer this over closely adjacent siblings such as configure_payments or manage_site_addon, so it stops short of full alternative-routing guidance.

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