Skip to main content
Glama
rad-security

RAD Security

Official
by rad-security

list_identities

Retrieve Kubernetes cluster identities including service accounts, users, and groups to manage access control and security policies.

Instructions

Get list of identities for a specific Kubernetes cluster

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
identity_typesNoIdentity types to get
cluster_idsNoCluster IDs to get identities for
pageNoPage number to get. Default: 1
page_sizeNoPage size to get. Default: 10
qNoQuery to filter identities

Implementation Reference

  • The handler function that executes the core logic for the 'list_identities' tool. It makes an API request to the RAD Security backend to fetch identities based on provided filters like identity_types, cluster_ids, pagination, and query.
    export async function listIdentities(
      client: RadSecurityClient,
      identityTypes: IdentityType[] = [],
      clusterIds: string[] = [],
      page: number = 1,
      page_size: number = 10,
      q: string = "",
    ): Promise<any> {
      const identities = await client.makeRequest(
        `/accounts/${client.getAccountId()}/identities`,
        {
          identity_types: identityTypes.join(","),
          identity_sources: clusterIds.join(","),
          page,
          page_size,
          q,
        }
      );
    
      return identities;
    }
  • Zod schema defining the input parameters and validation for the 'list_identities' tool.
    export const ListIdentitiesSchema = z.object({
      identity_types: z.array(IdentityTypeEnum).optional().describe("Identity types to get"),
      cluster_ids: z.array(z.string()).optional().describe("Cluster IDs to get identities for"),
      page: z.number().optional().describe("Page number to get. Default: 1"),
      page_size: z.number().optional().describe("Page size to get. Default: 10"),
      q: z.string().optional().describe("Query to filter identities"),
    });
  • src/index.ts:163-178 (registration)
    Registration of the 'list_identities' tool in the ListToolsRequest handler, including name, description, and input schema for tool discovery.
    ...(isToolkitEnabled("identities", toolkitFilters)
      ? [
          {
            name: "list_identities",
            description:
              "Get list of identities for a specific Kubernetes cluster",
            inputSchema: zodToJsonSchema(identities.ListIdentitiesSchema),
          },
          {
            name: "get_identity_details",
            description:
              "Get detailed information about a specific identity in a Kubernetes cluster",
            inputSchema: zodToJsonSchema(identities.GetIdentityDetailsSchema),
          },
        ]
      : []),
  • src/index.ts:784-801 (registration)
    Dispatch handler in the CallToolRequest switch statement that validates input with ListIdentitiesSchema, calls the listIdentities function, and formats the response for MCP.
    case "list_identities": {
      const args = identities.ListIdentitiesSchema.parse(
        request.params.arguments
      );
      const response = await identities.listIdentities(
        client,
        args.identity_types,
        args.cluster_ids,
        args.page,
        args.page_size,
        args.q
      );
      return {
        content: [
          { type: "text", text: JSON.stringify(response, null, 2) },
        ],
      };
    }
  • src/index.ts:23-23 (registration)
    Import of the identities module containing the handler and schema for list_identities.
    import * as identities from "./operations/identities.js";
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'Get list' which implies a read operation, but doesn't specify whether this requires authentication, has rate limits, returns paginated results (though schema hints at pagination), or what the output format looks like. Significant behavioral details are missing.

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 a single, clear sentence with no wasted words. It's appropriately sized and front-loaded with the core purpose.

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

Completeness3/5

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

For a list operation with 5 parameters and no output schema, the description is minimally adequate. It states what the tool does but doesn't provide enough context about output format, authentication requirements, or how it differs from sibling tools. The high schema coverage helps, but more behavioral context would be beneficial.

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 parameters are well-documented in the schema itself. The description doesn't add any meaningful parameter semantics beyond what's already in the schema descriptions, which is acceptable given the 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 action ('Get list') and resource ('identities for a specific Kubernetes cluster'), making the purpose understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'list_clusters' or 'get_identity_details', which would be needed for a score of 5.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'get_identity_details' or 'list_clusters', nor does it mention any prerequisites or contextual constraints for usage.

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/rad-security/mcp-server'

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