Skip to main content
Glama

FindLabels

Filter and retrieve record labels from RushDB with customizable conditions, sorting, and pagination options for precise data queries.

Instructions

Find / filter record labels (supports where, limit, skip, orderBy). Superset of GetLabels.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
whereNoFilter conditions for labels (e.g., by activity flags, counts)
limitNoMaximum number of labels to return
skipNoNumber of labels to skip
orderByNoSorting configuration: key = field, value = asc|desc

Implementation Reference

  • The core handler function that executes the tool logic: queries the labels in the database using provided where, limit, skip, orderBy filters and normalizes the response to [{name, count}] array.
    export async function FindLabels(
      params: {
        where?: Record<string, any>
        limit?: number
        skip?: number
        orderBy?: Record<string, 'asc' | 'desc'>
      } = {}
    ) {
      const { where, limit, skip, orderBy } = params
    
      const searchQuery: Record<string, any> = {}
      if (where) searchQuery.where = where
      if (typeof limit === 'number') searchQuery.limit = limit
      if (typeof skip === 'number') searchQuery.skip = skip
      if (orderBy && Object.keys(orderBy).length > 0) searchQuery.orderBy = orderBy
    
      const response = await db.labels.find(searchQuery)
    
      // Existing labels.find returns an object mapping label->count when empty query supplied.
      // When filters applied, SDK still returns .data as mapping; normalize to array.
      if (response?.success && response.data) {
        return Object.entries(response.data).map(([name, count]) => ({ name, count }))
      }
      return []
    }
  • JSON Schema definition for the input parameters of the FindLabels tool.
    inputSchema: {
      type: 'object',
      properties: {
        where: {
          type: 'object',
          description: 'Filter conditions for labels (e.g., by activity flags, counts)'
        },
        limit: { type: 'number', description: 'Maximum number of labels to return' },
        skip: { type: 'number', description: 'Number of labels to skip' },
        orderBy: {
          type: 'object',
          description: 'Sorting configuration: key = field, value = asc|desc',
          additionalProperties: { type: 'string', enum: ['asc', 'desc'] }
        }
      },
      required: []
    }
  • tools.ts:55-75 (registration)
    Registration of the FindLabels tool in the exported tools array used by MCP for listing available tools.
    {
      name: 'FindLabels',
      description: 'Find / filter record labels (supports where, limit, skip, orderBy). Superset of GetLabels.',
      inputSchema: {
        type: 'object',
        properties: {
          where: {
            type: 'object',
            description: 'Filter conditions for labels (e.g., by activity flags, counts)'
          },
          limit: { type: 'number', description: 'Maximum number of labels to return' },
          skip: { type: 'number', description: 'Number of labels to skip' },
          orderBy: {
            type: 'object',
            description: 'Sorting configuration: key = field, value = asc|desc',
            additionalProperties: { type: 'string', enum: ['asc', 'desc'] }
          }
        },
        required: []
      }
    },
  • index.ts:118-135 (registration)
    MCP CallToolRequest handler switch case that dispatches to the FindLabels implementation and formats the textual response.
    case 'FindLabels':
      const foundLabels = await FindLabels({
        where: args.where as Record<string, any> | undefined,
        limit: args.limit as number | undefined,
        skip: args.skip as number | undefined,
        orderBy: args.orderBy as Record<string, 'asc' | 'desc'> | undefined
      })
      return {
        content: [
          {
            type: 'text',
            text:
              foundLabels.length > 0 ?
                foundLabels.map((l: any) => `${l.name}: ${l.count} records`).join('\n')
              : 'No labels found'
          }
        ]
      }
Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions filtering capabilities but doesn't disclose important behavioral traits: whether this is a read-only operation, what permissions are required, if there are rate limits, what the return format looks like, or if it supports pagination beyond limit/skip. For a tool with filtering capabilities and no annotations, this is inadequate.

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 extremely concise (one sentence) and front-loaded with the core purpose. Every word earns its place: 'Find / filter record labels' establishes the action and resource, the parenthetical lists key parameters, and 'Superset of GetLabels' provides important sibling context. No wasted words.

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?

Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'record labels' are in this system's context, what the return values look like, or important behavioral aspects like permissions or limitations. For a filtering tool with four parameters and no structured output documentation, this leaves significant gaps for an agent.

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 100%, so the schema already documents all four parameters thoroughly. The description adds minimal value by listing the parameter names in parentheses but doesn't provide additional semantic context beyond what's in the schema descriptions. This meets the baseline for high schema coverage.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'Find / filter record labels' with specific capabilities (supports where, limit, skip, orderBy). It distinguishes from a sibling tool ('Superset of GetLabels'), which helps differentiate it. However, it doesn't specify what kind of 'record labels' these are or in what context, leaving some ambiguity.

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?

The description provides clear usage context by mentioning it's a 'superset of GetLabels,' implying this tool should be used when more advanced filtering/sorting is needed compared to GetLabels. It doesn't explicitly state when NOT to use it or mention alternatives beyond GetLabels, but the sibling comparison is helpful guidance.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rush-db/RushDB'

If you have feedback or need assistance with the MCP directory API, please join our Discord server