Skip to main content
Glama

Bernuvia

by com.bernuvia
OverviewDiscussionsAdmin

my_cases

THE LIST of your support cases and disputes, with their state and message thread (no internal team notes): pick it when you do not yet know which case you mean, or when you want to read the conversation. Not for the deadlines and status of ONE dispute whose order id you already have (that is dispute_status), and not for the evidence file (that is my_evidence).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
casesYesYour support cases, by last activity. Without the team's internal notes.
totalYesHow many cases go in `cases`.
moreCasesYesThe cap of 50 was reached: there may be more.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed19 schema fields changed
    • changedOutput schema / properties / cases / description
      Previous value: -"Tus casos de soporte, por última actividad. Sin notas internas del equipo."New value: +"Your support cases, by last activity. Without the team's internal notes."
    • changedOutput schema / properties / cases / items / properties / canReply / description
      Previous value: -"Se puede responder en el hilo."New value: +"You can reply in the thread."
    • changedOutput schema / properties / cases / items / properties / category / description
      Previous value: -"Categoría del caso."New value: +"Category of the case."
    • changedOutput schema / properties / cases / items / properties / closed / description
      Previous value: -"Está cerrado y no admite mensajes."New value: +"It is closed and takes no messages."
    • changedOutput schema / properties / cases / items / properties / createdAt / description
      Previous value: -"Cuándo se abrió (ISO)."New value: +"When it was opened (ISO)."
    • changedOutput schema / properties / cases / items / properties / id / description
      Previous value: -"Identificador del caso (lo pide `reply_to_case`)."New value: +"Identifier of the case (`reply_to_case` asks for it)."
    • changedOutput schema / properties / cases / items / properties / lastActivityAt / description
      Previous value: -"Último movimiento (ISO)."New value: +"Last activity (ISO)."
    • changedOutput schema / properties / cases / items / properties / messages / description
      Previous value: -"Los últimos mensajes del hilo, sin identificar a quién del equipo responde."New value: +"The last messages of the thread, without identifying who on the team replies."
    • changedOutput schema / properties / cases / items / properties / messages / items / properties / attachments / description
      Previous value: -"Cuántos adjuntos lleva."New value: +"How many attachments it carries."
    • changedOutput schema / properties / cases / items / properties / messages / items / properties / date / description
      Previous value: -"Cuándo se escribió (ISO)."New value: +"When it was written (ISO)."
    • changedOutput schema / properties / cases / items / properties / messages / items / properties / from / description
      Previous value: -"Quién escribe: me o team."New value: +"Who writes: me or team."
    • changedOutput schema / properties / cases / items / properties / messages / items / properties / text / description
      Previous value: -"Cuerpo del mensaje."New value: +"Body of the message."
    • changedOutput schema / properties / cases / items / properties / moreMessages / description
      Previous value: -"El hilo tiene más mensajes de los devueltos."New value: +"The thread has more messages than the ones returned."
    • changedOutput schema / properties / cases / items / properties / priority / description
      Previous value: -"Prioridad del ticket."New value: +"Priority of the ticket."
    • changedOutput schema / properties / cases / items / properties / status / description
      Previous value: -"Estado del ticket (OPEN, CLOSED, RESOLVED…)."New value: +"State of the ticket (OPEN, CLOSED, RESOLVED…)."
    • changedOutput schema / properties / cases / items / properties / subject / description
      Previous value: -"Asunto del caso."New value: +"Subject of the case."
    • changedOutput schema / properties / cases / items / properties / template / description
      Previous value: -"Plantilla disputada, si el caso es una disputa."New value: +"Disputed template, if the case is a dispute."
    • changedOutput schema / properties / moreCases / description
      Previous value: -"Se alcanzó el tope de 50: puede haber más."New value: +"The cap of 50 was reached: there may be more."
    • changedOutput schema / properties / total / description
      Previous value: -"Cuántos casos van en `cases`."New value: +"How many cases go in `cases`."
  2. First observed

TDQS

A4.7/5.0
Behavior4/5

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

With no annotations, the description carries the transparency burden. It discloses that this is a list/read operation of the user's own cases, includes message threads, and explicitly excludes internal team notes. It does not discuss pagination or ordering, but for a parameterless list this is adequately transparent.

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?

Every clause earns its place: the resource/content, a use-condition, and two explicit sibling exclusions. It is front-loaded with the core meaning and contains no filler.

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?

For a zero-parameter list tool with an output schema, this description is complete: it states the data returned, scopes it to the user's own cases, and routes to the relevant siblings. No additional invoke-time information is needed.

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?

The input schema has zero parameters, so there is no parameter-specific meaning to document. The description still makes the tool's scope clear, fulfilling the baseline for parameterless tools.

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?

Description names a concrete resource ('your support cases and disputes') and specifies the content delivered ('state and message thread'). The 'THE LIST' phrasing plus exclusions clearly differentiate it from siblings, so an agent knows exactly what operation this is.

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?

Gives explicit trigger conditions ('when you do not yet know which case you mean, or when you want to read the conversation') and names the alternatives it is not for: dispute_status for a known order id and my_evidence for evidence files. This leaves no ambiguity about when to select it.

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

All Bernuvia 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