Skip to main content
Glama

Dregs

by com.dregs
OverviewDiscussionsAdmin

List Identities

list_identities
Read-onlyIdempotent

List tracked identities for the current customer, ordered by most recent activity (lastTrackedAt) by default. Filter by free-text term, device fingerprint, group (its members, given its id and type), badge slug, or per-category score ranges; re-sort via sort/direction; and walk the full population with offset (the page cap is 100). Sort a score ascending — or use its Max filter — to surface the worst-scoring identities.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNoSort field: lastTrackedAt (default, recency of activity), firstSeenAt, lastScoredAt, humanityScore, authenticityScore, uniquenessScore, behaviorScore. Unknown values fall back to lastTrackedAt.
termNoFree-text search across identity id, display name, email, and username.
badgeNoBadge slug to filter by.
groupNoGroup id; only identities that belong to this group.
limitNoMaximum identities to return (default 25, max 100).
deviceNoDevice fingerprint to filter by.
offsetNoRows to skip before the page, for sweeping the full population (e.g. 0, then 100, then 200). Use a multiple of limit.
directionNoSort direction: desc (default) or asc.
groupTypeNoType of the group argument. The customer's own name for the kind of group, such as organization, company, team, or workspace (list_groups shows the types in use). Any spelling works: ParentCompany, parent-company, and parent_company are the same type. Defaults to organization.
behaviorMaxNoOnly identities with behaviorScore <= this (0-100).
behaviorMinNoOnly identities with behaviorScore >= this (0-100).
humanityMaxNoOnly identities with humanityScore <= this (0-100).
humanityMinNoOnly identities with humanityScore >= this (0-100).
uniquenessMaxNoOnly identities with uniquenessScore <= this (0-100).
uniquenessMinNoOnly identities with uniquenessScore >= this (0-100).
authenticityMaxNoOnly identities with authenticityScore <= this (0-100).
authenticityMinNoOnly identities with authenticityScore >= this (0-100).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / group
      Added value: +{
+  "description": "Group id; only identities that belong to this group.",
+  "type": "string"
+}
    • addedInput schema / properties / groupType
      Added value: +{
+  "description": "Type of the group argument. The customer's own name for the kind of group, such as organization, company, team, or workspace (list_groups shows the types in use). Any spelling works: ParentCompany, parent-company, and parent_company are the same type. Defaults to organization.",
+  "type": "string"
+}
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already establish readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds behavior beyond that: a 100-item page cap, the fact that unknown sort values fall back to lastTrackedAt, and that offset walks the full population. It doesn't discuss rate limits or result shape, keeping it at a solid 4 rather than 5.

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?

Two dense sentences, front-loaded with the resource and default ordering before filters, sorting, pagination, and the practical tip. No filler, though the second sentence packs several distinct topics (filter, sort, paginate, tip) into one long clause chain.

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?

For a 17-parameter, no-required-arg list tool with rich schema coverage and no output schema, the description covers the filter surface, ordering, and pagination model adequately. It leaves the returned identity shape and the interaction between multiple simultaneous filters unstated, which is a minor gap rather than a blocking one.

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 baseline is 3, but the description adds relational meaning the schema does not state on its own — that the group filter returns members given an id and type, that offset should be a multiple of limit, and that the page cap is 100. That dependency between group and groupType is a genuinely useful clarification beyond the field-level docs.

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 ('List tracked identities'), scopes it ('for the current customer'), and declares the default ordering ('most recent activity (lastTrackedAt)'). An agent can immediately distinguish this bulk-list tool from siblings like get_identity, analyze_identity, or search_events.

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 clear operational context: which filters are available (term, device, group, badge, score ranges), how to re-sort, how to paginate, and even a task-oriented tip (sort a score ascending or use its Max filter to surface the worst identities). It stops short of naming when NOT to use it versus list_devices/list_groups, so it's strong but not exhaustive.

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

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