Skip to main content
Glama

Mallory

listFindings

List and filter Mallory findings, returning lean summaries as {items,total,offset,limit}. Each item includes: title, status, severity, confidence, the owning definition's slug/title/category, asset type and identifier, resolution_reason, the thread_uuid of the investigation that produced it, and timestamps; the detail object adds body / summary / remediation / evidence, any linked external tickets, and entities — the threat actors, vulnerabilities and stories this finding resolved to, which is the pivot back into Mallory's intel graph. Returns every status by default — pass status=open (or status__in=open,fixed) to narrow. Sort by created_at, updated_at, status, title, severity, or asset_identifier; severity sorts INFO < LOW < MEDIUM < HIGH < CRITICAL, so desc puts Critical first. Notable fieldFilters: status, severity, definition_slug, definition_category, asset_type, asset_identifier, title, resolution_reason (also resolution_reason__isnull=true for closed findings with no reason recorded), thread_uuid to scope to one investigation. Enum values are case-sensitive and each field has its own set: severity is UPPERCASE (CRITICAL, HIGH, MEDIUM, LOW, INFO); status is lowercase and has exactly three values (open, fixed, dismissed); resolution_reason is lowercase and separate from status (false_positive, accepted_risk, not_applicable, duplicate, fixed_externally, other); definition_category is lowercase-hyphenated (e.g. public-exposure). Send values, not enum member names. definition_category is the exception: equality and membership ONLY (bare, __in, __not_in) — the __contains/__ilike/__neq the other fields accept are dropped on it, and you get the unfiltered list back. asset_type is a free-text column in provider.service.object form (e.g. aws.s3.bucket, not s3), so a partial value matches nothing unless you use asset_type__ilike. Field operators append to a field name with __: a bare field name is exact match, and the string/enum fields (status, severity, title, definition_slug, asset_type, asset_identifier, resolution_reason) also take __neq, __in, __not_in, __contains, __not_contains, __ilike. This endpoint has NO __like. Timestamps are created_at / updated_at with __gte and __lt ONLY, a half-open range — __gt, __lte and a bare created_at are not parameters at all. An operator this endpoint does not define is dropped silently rather than rejected, so guessing one returns a WIDER result set that looks filtered. Pass an item's identifier to getFinding for the full detail object.

Input Schema

NameRequiredDescriptionDefault
sortNoField to sort by (see this tool's sort fields).
limitNoMax items to return (1-100, default 25).
orderNoSort order (default: desc).
filterNoFull-text search over the finding's title, asset identifier, body, summary, remediation and asset details. Supports web-search query syntax, and AND-combines with the other filters.
offsetNoItems to skip, for pagination.
fieldFiltersNoAdvanced structured filters as a map of query-param name -> value. Use a bare field for exact match, or a field__operator key for ranges/sets. Field operators append to a field name with `__`: a bare field name is exact match, and the string/enum fields (status, severity, title, definition_slug, asset_type, asset_identifier, resolution_reason) also take __neq, __in, __not_in, __contains, __not_contains, __ilike. This endpoint has NO __like. Timestamps are created_at / updated_at with __gte and __lt ONLY, a half-open range — __gt, __lte and a bare created_at are not parameters at all. An operator this endpoint does not define is dropped silently rather than rejected, so guessing one returns a WIDER result set that looks filtered.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden — and it discloses the non-obvious behaviors that would otherwise cause silent wrong results: undefined operators are dropped rather than rejected ('guessing one returns a WIDER result set that looks filtered'), definition_category silently ignores __contains/__neq, and timestamps only accept __gte/__lt. Enum case-sensitivity per field and the severity sort ordering are also spelled out. Auth/rate-limit details are absent, but for a read-only listing endpoint the operationally risky behaviors are covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose, return shape and the getFinding pointer are front-loaded, which is good. However, the description is one dense block that restates verbatim what the fieldFilters schema description already covers (operator list, no __like, silent-drop warning, timestamp operator limits), so a meaningful fraction of the text does not earn incremental place.

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?

There is no output schema, so the description must explain return values — and it does, itemizing both the summary fields and the detail object (body/summary/remediation/evidence, linked tickets, and the `entities` pivot into the intel graph). Combined with the pagination envelope and sort semantics, an agent has everything needed to call and interpret this tool.

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

Parameters5/5

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

Schema coverage is 100%, so baseline is 3 — but the description goes well beyond it, enumerating the actual enum value sets (status has exactly three values; severity UPPERCASE values; resolution_reason's six values), the per-field operator availability, the asset_type free-text provider.service.object form, and the notable fieldFilters including thread_uuid. This is precisely the information the opaque `additionalProperties: string` map and the string-typed `sort` cannot convey.

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?

Opens with a specific verb+resource (list and filter Mallory findings) and immediately states the return shape {items,total,offset,limit} plus what each item contains. It also distinguishes itself from getFinding ('Pass an item's identifier to getFinding for the full detail object'), so an agent can separate the lean-list tool from the detail tool 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?

Explicitly states the default behavior ('Returns every status by default — pass status=open ... to narrow') and names the alternative for full detail (getFinding). It does not compare against adjacent list/search siblings such as searchVulnerabilities, but for a filter-heavy list endpoint the usage context is otherwise clear.

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