Skip to main content
Glama

Search Cases

searchCases

Search cases in a queue with rich filters (multi-status, date ranges, label-based filters, and field-value filters over a typed queue's json_data). Use this when the simple query-string filters on GET /v2/queues/:queue_id/cases aren't enough. Each json_data entry is {path, operator, value} where path is a declared scalar in JSONPath dotted form ($.invoice.amount); entries are ANDed, so two comparisons on one path express a range. A path the queue's Case schema does not declare is rejected rather than ignored, as is a value that does not match the field's declared type. The contains operator is case-sensitive (unlike the free-text search parameter). Set count_only=true to skip Case row selection, enrichment, and transformation. The normal response shape is returned with cases: [] and the matching total.

Input Schema

NameRequiredDescriptionDefault
limitNo
offsetNo
searchNo
filtersNo
sort_byNocreated_at
queue_idYesThe queue's unique identifier
count_onlyNoSkip Case row selection, enrichment, and transformation. The normal response shape contains an empty cases array and the matching total.
sort_orderNodesc

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / filters / properties / completed_at_from
      Added value: +{
      +  "description": "Keep Cases that reached an outcome at or after this time (inclusive). An ISO timestamp or a lookback such as `7d` or `12h`.",
      +  "type": "string"
      +}
    • addedInput schema / properties / filters / properties / completed_at_to
      Added value: +{
      +  "description": "Keep Cases that reached an outcome before this time (exclusive). An ISO timestamp or a lookback such as `7d` or `12h`.",
      +  "type": "string"
      +}
    • addedInput schema / properties / filters / properties / failure_source
      Added value: +{
      +  "description": "Keep only failed Cases, by who failed them: `system` when Duvo could not finish the Case, `manual` when a person marked it failed.",
      +  "items": {
      +    "enum": [
      +      "system",
      +      "manual"
      +    ],
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  2. Changed1 schema field changed
    • addedInput schema / properties / filters / properties / awaiting_my_approval
      Added value: +{
      +  "type": "boolean"
      +}
  3. Changed3 schema fields changed
    • addedInput schema / properties / filters / properties / created_at_to
      Added value: +{
      +  "type": "string"
      +}
    • addedInput schema / properties / filters / properties / json_data
      Added value: +{
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "operator": {
      +        "enum": [
      +          "equals",
      +          "notEquals",
      +          "in",
      +          "notIn",
      +          "gt",
      +          "gte",
      +          "lt",
      +          "lte",
      +          "contains",
      +          "isSet",
      +          "isNotSet"
      +        ],
      +        "type": "string"
      +      },
      +      "path": {
      +        "pattern": "^\\$(\\.[A-Za-z_][A-Za-z0-9_]{0,63})+$",
      +        "type": "string"
      +      },
      +      "value": {
      +        "anyOf": [
      +          {
      +            "anyOf": [
      +              {
      +                "type": "string"
      +              },
      +              {
      +                "type": "number"
      +              },
      +              {
      +                "type": "boolean"
      +              }
      +            ]
      +          },
      +          {
      +            "items": {
      +              "anyOf": [
      +                {
      +                  "type": "string"
      +                },
      +                {
      +                  "type": "number"
      +                },
      +                {
      +                  "type": "boolean"
      +                }
      +              ]
      +            },
      +            "maxItems": 100,
      +            "minItems": 1,
      +            "type": "array"
      +          }
      +        ]
      +      }
      +    },
      +    "required": [
      +      "path",
      +      "operator"
      +    ],
      +    "type": "object"
      +  },
      +  "maxItems": 12,
      +  "type": "array"
      +}
    • addedInput schema / properties / filters / properties / updated_at_to
      Added value: +{
      +  "type": "string"
      +}
  4. Changed1 schema field changed
    • addedInput schema / properties / filters / properties / issue_severity
      Added value: +{
      +  "items": {
      +    "enum": [
      +      "critical",
      +      "medium"
      +    ],
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  5. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Goes well beyond the annotations by disclosing validation behavior (undeclared paths and type-mismatched values are rejected, not ignored), AND semantics across json_data entries, case-sensitivity of `contains`, and the side effects of count_only on selection/enrichment/transformation. It omits pagination limits and auth requirements, and there is mild tension between 'search' and readOnlyHint=false, though this is a POST-style search endpoint rather than an actual write.

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?

Purpose and the routing condition are front-loaded, and each subsequent sentence carries distinct information (json_data shape, validation, contains semantics, count_only). It is dense but not padded, though it runs long enough that a reader must hold several rules at once.

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?

No output schema exists, and the description partially compensates by stating that count_only returns the normal shape with cases: [] and the matching total. The content of a normal (non-count) response is left implicit, and limit/offset pagination is left entirely to the schema, leaving a modest gap for a search tool.

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?

With only 25% schema description coverage, the description carries real weight: it explains the {path, operator, value} shape of json_data, the JSONPath dotted path format, ANDing across entries, and the count_only flag's effect on the response. It adds little about labels, status, priority, the date-range filters, or sort_by/sort_order beyond what the schema already implies.

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?

States a specific verb and resource with scope ('Search cases in a queue with rich filters') and immediately contrasts it with the simpler query-string filter endpoint, so an agent can tell it apart from listCases without opening either schema.

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?

Gives a clear selection condition: 'Use this when the simple query-string filters ... aren't enough,' which routes the agent away from the basic list endpoint. It does not name the sibling tool explicitly or state when-not to use this tool (e.g. bulk export), so it stops short of full routing guidance.

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