Skip to main content
Glama
Sign In

Mondovo

by com.mondovo.app
OverviewDiscussionsAdmin

File a support ticket

create_support_ticket

File a ticket with the platform's support team in the signed-in person's name — for a bug, a billing question, a feature request, or anything the user wants a human to look at. Write a one-line subject and a description with the relevant detail from the conversation (what they tried, what happened, which page); put anything else useful in context. Use "urgent" only for a site that is down or data that is lost. Pass site_id when it is about one site. The team replies in Settings → Support.

Input Schema

NameRequiredDescriptionDefault
contextNoExtra context for the support team, e.g. a summary of the conversation
site_idNoThe site it is about, if any
subjectYesOne-line summary
categoryNoDefault "general"
priorityNoDefault "medium"; "urgent" only for site-down or data-loss
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.
descriptionYesWhat happened, in detail

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. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare this is a non-readonly, open-world, non-idempotent but non-destructive write; the description adds context annotations cannot: the ticket is filed in the signed-in person's name, the escalation threshold for 'urgent', and where the team replies (Settings → Support). It does not mention rate limits or whether a ticket ID is returned.

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?

Three dense sentences, front-loaded with the action and resource, then usage conditions, then a useful closing detail about where replies arrive. No filler or restatement of the title.

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

Completeness4/5

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

For a 7-parameter write tool with no output schema and annotations covering the safety profile, the description gives enough to call it correctly (what to write, when to escalate, where the reply lands). The missing piece is what the agent gets back after filing (ticket id or confirmation).

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds only modest guidance beyond the schema — what to put in subject/description/context and when to pass site_id — and its priority caution for 'urgent' largely repeats the priority field's own description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('File a ticket with the platform's support team') and enumerates the situations it covers (bug, billing, feature request, human review). It does not name its sibling list_support_tickets, but the write-vs-read distinction is evident from the phrasing.

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?

Clear context for use ('for a bug, a billing question, a feature request, or anything the user wants a human to look at') and conditional rules for priority ('use "urgent" only for a site that is down or data that is lost') and site_id. It stops short of naming alternatives or stating when-not to use it, e.g. checking status via list_support_tickets.

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