Skip to main content
Glama
Use-Tusk
by Use-Tusk

list_distinct_values

Identify unique values in a field to discover available endpoints, instrumentation packages, environments, or JSONB data before building specific queries.

Instructions

List unique values for a field, ordered by frequency.

Use this tool to:

  • Discover available endpoints (field: "name")

  • See all instrumentation packages in use (field: "packageName")

  • Find unique environments (field: "environment")

  • Explore JSONB values like status codes (field: "outputValue.statusCode")

This helps you understand what values exist before building specific queries.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
observableServiceIdNoService ID to query (required if multiple services available)
fieldYesField to get distinct values for (e.g., 'name', 'packageName', 'outputValue.statusCode')
whereNoFilter conditions
jsonbFiltersNoJSONB path filters
limitNoMax distinct values to return

Implementation Reference

  • The core handler function for the list_distinct_values tool. Parses input using the schema, calls the API client to fetch distinct values, formats them by frequency with counts, and returns formatted text response.
    export async function handleListDistinctValues(
      client: TuskDriftApiClient,
      args: Record<string, unknown>
    ): Promise<{ content: Array<{ type: "text"; text: string }> }> {
      const input = listDistinctValuesInputSchema.parse(args) as ListDistinctValuesInput;
      const result = await client.listDistinctValues(input);
    
      const header = `Distinct values for "${result.field}" (${result.values.length} unique values):\n`;
    
      const valuesList = result.values
        .map((v, i) => {
          const valueStr = typeof v.value === "string" ? v.value : JSON.stringify(v.value);
          return `${i + 1}. ${valueStr} (${v.count} occurrences)`;
        })
        .join("\n");
    
      return {
        content: [
          {
            type: "text",
            text: header + valuesList,
          },
        ],
      };
    }
  • MCP Tool object definition with name, description, and input schema for list_distinct_values. Exported and collected into tools array.
    export const listDistinctValuesTool: Tool = {
      name: "list_distinct_values",
      description: `List unique values for a field, ordered by frequency.
    
    Use this tool to:
    - Discover available endpoints (field: "name")
    - See all instrumentation packages in use (field: "packageName")
    - Find unique environments (field: "environment")
    - Explore JSONB values like status codes (field: "outputValue.statusCode")
    
    This helps you understand what values exist before building specific queries.`,
      inputSchema: {
        type: "object",
        properties: {
          observableServiceId: {
            type: "string",
            description: "Service ID to query. Required if multiple services are available.",
          },
          field: {
            type: "string",
            description:
              "Field to get distinct values for. Can be a column name or JSONB path (e.g., 'name', 'packageName', 'outputValue.statusCode')",
          },
          where: {
            type: "object",
            description: "Optional filter to scope the distinct values",
          },
          jsonbFilters: {
            type: "array",
            description: "Optional JSONB filters to scope the distinct values",
          },
          limit: {
            type: "number",
            description: "Maximum distinct values to return (default 50)",
            default: 50,
          },
        },
        required: ["field"],
      },
    };
  • Zod input schema used for validation in the handler and registered for MCP tool input validation.
    export const listDistinctValuesInputSchema = z.object({
      observableServiceId: z.string().optional().describe("Service ID to query (required if multiple services available)"),
      field: z.string().describe("Field to get distinct values for (e.g., 'name', 'packageName', 'outputValue.statusCode')"),
      where: spanWhereClauseSchema.optional().describe("Filter conditions"),
      jsonbFilters: z.array(jsonbFilterSchema).optional().describe("JSONB path filters"),
      limit: z.number().min(1).max(100).default(50).describe("Max distinct values to return"),
    });
  • Central registration: adds listDistinctValuesTool to tools array and maps 'list_distinct_values' to its handler function. Used by main server to register all tools.
    export const tools: Tool[] = [
      querySpansTool,
      getSchemaTool,
      listDistinctValuesTool,
      aggregateSpansTool,
      getTraceTool,
      getSpansByIdsTool,
    ];
    
    export type ToolHandler = (
      client: TuskDriftApiClient,
      args: Record<string, unknown>
    ) => Promise<{ content: Array<{ type: "text"; text: string }> }>;
    
    export const toolHandlers: Record<string, ToolHandler> = {
      query_spans: handleQuerySpans,
      get_schema: handleGetSchema,
      list_distinct_values: handleListDistinctValues,
      aggregate_spans: handleAggregateSpans,
      get_trace: handleGetTrace,
      get_spans_by_ids: handleGetSpansByIds,
    };
Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: the tool returns unique values ordered by frequency, helps understand existing values before querying, and implies it's a read-only exploration tool (no mention of mutation). However, it doesn't mention rate limits, pagination, or error handling, leaving some gaps.

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 well-structured and front-loaded with the core purpose. The 'Use this tool to:' section efficiently lists scenarios without redundancy. Every sentence adds value, and the final sentence reinforces the tool's role in the workflow. No wasted words.

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?

Given the tool's moderate complexity (5 parameters with nested objects) and no output schema, the description does well by explaining the tool's exploratory purpose and providing usage examples. However, it doesn't describe the return format (e.g., list of value-frequency pairs) or address all behavioral aspects like error cases, leaving room for improvement.

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 description coverage is 100%, so the baseline is 3. The description adds significant value by providing concrete examples of field parameter usage (e.g., 'name', 'packageName', 'outputValue.statusCode') and contextualizing the tool's purpose, which helps interpret the complex where and jsonbFilters parameters beyond their schema descriptions.

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 clearly states the tool's purpose: 'List unique values for a field, ordered by frequency.' It specifies the verb ('List'), resource ('unique values for a field'), and key behavior ('ordered by frequency'). It distinguishes from siblings by focusing on distinct value exploration rather than aggregation, tracing, or querying spans.

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?

The description provides explicit usage guidance with a 'Use this tool to:' section listing four specific scenarios (e.g., 'Discover available endpoints', 'See all instrumentation packages in use'). It also states the tool's purpose 'before building specific queries,' indicating when to use it versus more targeted query tools like query_spans.

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/Use-Tusk/drift-mcp'

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