Skip to main content
Glama

contact_supermetrics

Send feedback, create a support ticket (only when the user authorizes it), submit a sales enquiry, or reply to an existing ticket. For a common problem, first call supermetrics_guide and try the relevant steps before opening a ticket. Only ticket if that does not resolve it or it needs staff action (non-self-serve plan changes or a genuine bug). Cancelling a trial or an online subscription is not a ticket: use the cancel_trial guide. If you ticket, note which guide was tried and what still failed. When you create a support ticket, always set "category" to the option that matches the user's issue (authentication, billing, subscription, data discrepancy, or query help). For product feature requests, you can also point users to the public wishlist at https://wishlist.supermetrics.com, where they can submit and vote on ideas. Before a ticket or sales enquiry about buying or pricing, call supermetrics_guide(mode="pricing_and_purchasing"); standard plans are bought online at https://supermetrics.com/pricing. Only submit a sales enquiry for special needs: many data sources, data source accounts, users, Supermetrics API access (custom connector or API key), or other custom requirements. Only the user's own tickets are accessible, and only post a reply when the user explicitly asks. Before creating a support ticket, first call get_support_tickets to list the user's existing tickets and check whether an open one already covers the same issue. If it does, add to that ticket with type "ticket_reply" instead of creating a duplicate; only create a new ticket when none of the open tickets match.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "type": "<type>"
    },
    "name": "contact_supermetrics"
  }
}

Input Schema

NameRequiredDescriptionDefault
typeYesfeedback, support, sales, or ticket_reply (post a follow-up to an existing ticket)
ds_idNoRelated data source ID (e.g. 'FA', 'AW')
companyNoCompany (required for sales)
countryNoCountry (required for sales)
messageNoDetailed description with span IDs (feedback/support/sales), or the reply body (ticket_reply)
subjectNoBrief summary (required for feedback/support/sales)
categoryNoSupport ticket category (support only). Pick the one that matches the user's issue: category_authentication_issue (login, token or permission errors, reconnecting a data source); category_help_with_the_queries (query or transfer errors; the fallback when nothing else fits); category_data_discrepancy (missing or mismatching data); category_manage_subscription (data sources, destinations, users, trials, plan changes); category_manage_billing (invoices, payments, VAT)
industryNoContact's industry. Used when type is 'sales'
lastnameNoLast name (required for sales)
firstnameNoFirst name (required for sales)
ticket_idNoZendesk ticket ID to reply to (ticket_reply)

Output Schema

NameRequiredDescriptionDefault
dataNo
errorNo
notesNo
successYes
business_contextNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations declare a non-read-only, open-world, non-idempotent write, and the description adds material context beyond them: only the user's own tickets are visible, replies should only be posted when the user explicitly asks, ticket creation requires user authorization, and duplicates must be avoided by inspecting open tickets first. It also specifies what to include in a ticket (which guide was tried, what failed). No contradiction with the annotations.

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 most decision-critical instruction (check get_support_tickets, avoid duplicates) appears last rather than first, and the trial-cancellation and wishlist asides interrupt the main flow. The prose is dense and largely earning its place, but reordering would improve front-loading.

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 an 11-parameter, multi-mode write tool with an output schema, the description covers routing, prerequisites, deduplication, and category selection thoroughly. Minor gaps remain around non-ticket modes (feedback and sales field requirements) and what a successful submission returns, though the output schema mitigates the latter.

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 baseline is 3, and the description earns above that by mapping user-facing issue types to the category enum values (authentication, billing, subscription, data discrepancy, query help) and by framing when sales-specific fields matter. Still, several parameters (ds_id, industry, company/country, ticket_id) are left entirely to the schema, so it does not fully exploit the space.

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 opening sentence names four concrete actions (feedback, support ticket, sales enquiry, ticket reply) and ties them to the single tool, so an agent knows exactly what it does. It also distinguishes this tool from supermetrics_guide, get_support_tickets and the cancel_trial guide by name, making sibling selection unambiguous.

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?

Guidance is unusually explicit: try supermetrics_guide first for common problems, only ticket if unresolved or requiring staff action, route trial/subscription cancellation to cancel_trial, and route pricing questions to supermetrics_guide(mode="pricing_and_purchasing"). It also states when a sales enquiry is warranted (special needs only) versus buying online, and mandates checking get_support_tickets before opening a new ticket.

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