Skip to main content
Glama

List agent profiles

profiles_list
Read-onlyIdempotent

List profiles for an Omnara org and project, with name filtering, sorting, pagination, and optional usage stats to inspect instances in one call.

Instructions

Items are ordered by created_at descending, then id descending.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoCase-insensitive glob over the list's logical name. `*` matches zero or more characters, `?` matches one character, and `\` escapes a wildcard.
sortNoSort order for named resources that expose created and modified timestamps.
limitNoMaximum number of items to return in one page.
orgIDYes
cursorNoOpaque pagination cursor from a previous response's next_cursor. Omit for the first page.
projectIDYes
stats_sinceNoStart of the window `stats.usage` tallies, with `include_stats`. Omit to tally from the earliest recorded call.
include_statsNoInclude each profile's `stats`, so a list can show instance counts and usage without a request per profile.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.2/5.0
Behavior2/5

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

Annotations already declare this as a read-only, idempotent, non-destructive, closed-world operation. The description adds only the default sort order (created_at descending, then id descending), which is marginally useful but omits richer behavioral details such as pagination behavior, filtering interplay, or the effect of include_stats. The ordering note is the sole addition beyond structured fields.

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?

The description is a single, efficient sentence with no waste. However, it is not front-loaded with the tool's purpose, which is absent entirely.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter list tool with no output schema and annotations covering safety, the description is incomplete: it omits what the tool returns, how pagination works, the role of required orgID/projectID, and when to use it. It addresses only default ordering.

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

Parameters3/5

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

Schema description coverage is 75%, so most parameters are documented in the schema. The description adds the default ordering (created_at desc, id desc), which is not explicit in the schema, but it doesn't explain the sort parameter's override behavior or how it interacts with the default. Baseline 3 is appropriate given the schema already covers most semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description never states that this tool lists agent profiles; it only describes the ordering of items. The tool's actual purpose must be inferred from the name and title, which the description merely restates in behavioral terms. It is a tautological restatement rather than a clear verb+resource statement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives like agents_list or profiles_get. No context, prerequisites, or exclusions are provided.

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