Skip to main content
Glama

cortex_list_analyzer_definitions

List installed analyzer definitions in Cortex. Filter by data type, find analyzers requiring no API keys, or search by name or description.

Instructions

List all available analyzer definitions (installed but not necessarily enabled). Filter by data type or find analyzers that require no API keys.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataTypeNoFilter by supported data type (ip, domain, hash, url, file, mail, fqdn, etc.)
freeOnlyNoIf true, only return analyzers that require no configuration/API keys
searchNoSearch analyzer names and descriptions (case-insensitive)
limitNoMaximum results to return (default: 50)

Implementation Reference

  • The handler function for the cortex_list_analyzer_definitions tool. It calls client.listAnalyzerDefinitions(), then filters by dataType, freeOnly, and search, applies a limit, maps results to a summary format, and returns JSON.
      async ({ dataType, freeOnly, search, limit }) => {
        try {
          let defs = await client.listAnalyzerDefinitions();
    
          if (dataType) {
            defs = defs.filter((d) => d.dataTypeList.includes(dataType));
          }
    
          if (freeOnly) {
            defs = defs.filter(
              (d) => !d.configurationItems.some((c) => c.required),
            );
          }
    
          if (search) {
            const q = search.toLowerCase();
            defs = defs.filter(
              (d) =>
                d.name.toLowerCase().includes(q) ||
                d.description.toLowerCase().includes(q),
            );
          }
    
          const total = defs.length;
          defs = defs.slice(0, limit);
    
          const summary = defs.map((d) => ({
            id: d.id,
            name: d.name,
            version: d.version,
            description: d.description,
            dataTypes: d.dataTypeList,
            author: d.author,
            requiresConfig: d.configurationItems.some((c) => c.required),
            configFields: d.configurationItems.map((c) => ({
              name: c.name,
              required: c.required,
              type: c.type,
              description: c.description,
            })),
            dockerImage: d.dockerImage,
          }));
    
          return {
            content: [
              {
                type: "text" as const,
                text: JSON.stringify(
                  {
                    total,
                    returned: summary.length,
                    definitions: summary,
                  },
                  null,
                  2,
                ),
              },
            ],
          };
        } catch (error) {
          return {
            content: [
              {
                type: "text" as const,
                text: `Error listing analyzer definitions: ${error instanceof Error ? error.message : String(error)}`,
              },
            ],
            isError: true,
          };
        }
      },
    );
  • Zod schema for the cortex_list_analyzer_definitions tool inputs: dataType (optional string), freeOnly (optional boolean), search (optional string), limit (optional int, default 50, max 500).
    {
      dataType: z
        .string()
        .optional()
        .describe("Filter by supported data type (ip, domain, hash, url, file, mail, fqdn, etc.)"),
      freeOnly: z
        .boolean()
        .optional()
        .describe("If true, only return analyzers that require no configuration/API keys"),
      search: z
        .string()
        .optional()
        .describe("Search analyzer names and descriptions (case-insensitive)"),
      limit: z
        .number()
        .int()
        .min(1)
        .max(500)
        .default(50)
        .describe("Maximum results to return (default: 50)"),
    },
  • The registerAnalyzerDefinitionTools function is where the tool 'cortex_list_analyzer_definitions' is registered on the MCP server via server.tool(). Called from src/index.ts:40.
    export function registerAnalyzerDefinitionTools(
      server: McpServer,
      client: CortexClient,
    ): void {
      server.tool(
        "cortex_list_analyzer_definitions",
  • The client.listAnalyzerDefinitions() method that makes the GET request to /api/analyzerdefinition (with superadmin auth). This is the helper that fetches the raw data from the Cortex API.
    async listAnalyzerDefinitions(): Promise<AnalyzerDefinition[]> {
      return this.request<AnalyzerDefinition[]>("/analyzerdefinition", {}, true);
    }
  • The AnalyzerDefinition and ConfigurationItem TypeScript interfaces defining the shape of data returned from the API and used by the handler.
    export interface AnalyzerDefinition {
      id: string;
      name: string;
      version: string;
      description: string;
      dataTypeList: string[];
      author: string;
      url: string;
      license: string;
      baseConfig: string;
      configurationItems: ConfigurationItem[];
      dockerImage: string | null;
      command: string | null;
    }
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It describes the operation as listing definitions, which is expected to be read-only. However, it does not explicitly confirm zero side effects or mention any permissions or rate limits. The description is adequate but could be more transparent.

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 sentence that is front-loaded and contains no extraneous information. Every word serves a purpose, making it highly efficient.

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 simplicity (4 parameters with full schema descriptions, no output schema), the description is complete enough. It covers the main functionality and filtering options. It could optionally mention return structure, but that is not essential for a list tool.

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% and the input schema provides clear descriptions for each parameter. The description adds no additional meaning beyond summarizing the filter options. Baseline score of 3 is appropriate since the schema already covers parameter semantics.

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 lists analyzer definitions and specifies they are 'installed but not necessarily enabled,' which differentiates it from the sibling 'cortex_list_analyzers' that likely lists only enabled analyzers. The verb 'list' and resource 'analyzer definitions' are specific and unambiguous.

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

Usage Guidelines3/5

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

The description implies when to use (view all definitions, filter by data type or free analyzers) but does not explicitly state when not to use or mention alternative tools. The sibling list provides context but the description itself lacks explicit usage 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/solomonneas/cortex-mcp'

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