Skip to main content
Glama

Mallory

listSoftwarePackages

List and filter Mallory software packages, returning lean summaries as {items,total,offset,limit}. Each item includes: package name, ecosystem, description, known configurations, and supply-chain compromise evidence. Filter prefixes: name:, uuid:. Sort by created_at, updated_at, last_compromised_at, or compromise_evidence_count. Field operators append to a field name with __: strings support __neq, __in, __not_in, __like, __ilike; numbers support __gt, __gte, __lt, __lte. Timestamps (created_at, updated_at) support __gte and __lt ONLY — there is no __gt, __lte, or bare equality on them, so express a range as the half-open created_at__gte=&created_at__lt=. Pass an item's identifier to getSoftwarePackage 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).
filterNoPrefix filter string (see this tool's filter prefixes). No prefix = default name/text search.
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 `__`: strings support __neq, __in, __not_in, __like, __ilike; numbers support __gt, __gte, __lt, __lte. Timestamps (created_at, updated_at) support __gte and __lt ONLY — there is no __gt, __lte, or bare equality on them, so express a range as the half-open created_at__gte=<start>&created_at__lt=<end>.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden. It discloses the return envelope, item fields, filtering constraints, and the important timestamp-operator limitation, but does not discuss permissions, rate limits, or explicit read-only safety, which are minor gaps for a list operation.

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?

The description is dense but front-loaded and every sentence adds operational value. Given the complexity of the filtering syntax, the length is appropriate and there is 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?

There is no output schema, but the description defines the return shape as {items,total,offset,limit} and lists what each item includes. Combined with the filtering and sorting rules, it is complete enough for an agent to call the tool correctly.

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 the baseline would be 3, but the description adds substantial semantic detail beyond the schema: filter prefixes name: and uuid:, allowed sort fields, field operator behavior, and the restricted timestamp operators with a half-open range example.

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 description states a specific verb and resource: list and filter Mallory software packages. It clearly distinguishes the lean list output from the full detail object returned by getSoftwarePackage, so an agent can distinguish it from siblings without opening schemas.

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?

It explicitly routes the agent to getSoftwarePackage when an item identifier is available and the full detail object is needed. It also explains filter prefixes, sort fields, and operator behavior, leaving little ambiguity about how to use the tool versus alternatives.

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