Skip to main content
Glama

Ask Rupert (product support)

ask_support

Ask Rupert, Entity Enricher's product-support assistant, a question about the application itself: how a feature, a tool or a setting works, what an error_code, a limit, a status or a warning means, why a result or a schema looks the way it does, which plan a feature needs. Use it when the guides (enricher://docs) do not answer, before guessing or telling the user something is impossible. Put the context Rupert needs in the message: the tool called, the error_code or message returned, the schema, job or record concerned (ids are fine, never secrets). Pass conversation_id to continue the thread you opened; omit it for a new topic. Blocks until the answer is complete (up to about two minutes) and returns the full reply. Each question counts against the organization's daily support quota: the result says questions_remaining (null = unlimited) and the call fails with support_question_limit_reached once it is spent, so ask one well-stated question rather than many. A support team member may later post a follow-up in the thread: when the thread you continue holds one you have not read, the result carries the team's follow-ups since your last question as new_admin_messages — relay them to the user, and quote them to Rupert yourself if they matter, since Rupert never reads admin follow-ups; threads_with_unread_admin_reply lists your other threads with one waiting (read them with get_support_conversation). Needs a signed-in user (OAuth or a personal API key): an organization access key gets support_requires_user. attachment_ids are ordinary uploads (upload_attachment): images up to 2 MB and text documents only. Guide: enricher://docs/support

Input Schema

NameRequiredDescriptionDefault
localeNoUI locale tag the answer should be written in (en, fr, de, es, pt, it, nl, ja, zh-CN, ko, ar, hi, ru). Defaults to English.
messageYesThe question, with its context, in the user's language (up to 4000 characters). May be empty when an attachment carries the question.
attachment_idsNoUp to 5 uploaded attachments to show Rupert (at most 3 images, 2 MB each; documents go as their extracted text).
conversation_idNoThe thread to continue — the conversation_id a previous ask_support returned — so Rupert keeps the context of the exchange. Omit it to open a new thread on a new topic.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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 (readOnlyHint=false, openWorldHint=true) by disclosing blocking latency (~2 minutes), quota consumption with the concrete questions_remaining field and support_question_limit_reached failure, auth requirements with the support_requires_user error, and the asynchronous new_admin_messages follow-up protocol. This is unusually rich operational context for a tool whose annotations say little.

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?

Front-loaded with purpose, then prerequisites, then quota and follow-up mechanics — the ordering matches how an agent needs it. It is a single dense paragraph of roughly 180 words, and the attachment sizes/limits partly restate the schema, so it is close to the upper bound of acceptable length rather than wasteful.

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?

An output schema exists, yet the description still flags the two return fields an agent must act on (questions_remaining, new_admin_messages/threads_with_unread_admin_reply). Combined with auth, quota, latency and attachment constraints, nothing needed to call this 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 100%, so the schema already documents all four parameters and the baseline would be 3. The description still adds workflow semantics the schema does not: which context to pack into message (tool called, error_code, schema/job ids, never secrets) and the continue-vs-new-topic rule for conversation_id.

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?

Names a specific agent and resource: 'Ask Rupert, Entity Enricher's product-support assistant, a question about the application itself', then enumerates the question classes (feature behavior, error_code meaning, plan requirements). This is clearly separable from siblings like get_support_conversation, list_support_conversations and answer_job_question.

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?

Explicit trigger and fallback chain: use it when enricher://docs does not answer, 'before guessing or telling the user something is impossible'. It also routes the continuation case to conversation_id and the reading case to get_support_conversation, so alternatives are named with their selecting conditions.

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.