Skip to main content
Glama
Stankye

AssemblyLine 4 MCP Server

by Stankye

al4_ingest_sha256

Ingest an existing file into AssemblyLine for analysis by providing its SHA256 hash, with optional notification, alert, and service configuration.

Instructions

Asynchronously ingest a file by SHA256 hash into AssemblyLine. The file must already exist in the AL4 file store.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sha256Yes
notification_queueNo
alertNo
descriptionNo
classificationNo
servicesNo
metadataNo

Implementation Reference

  • The ingestSha256 method on AL4Client – validates SHA256 format, builds the request body with optional ingest options (params, metadata, notification_queue, alert), and POSTs to /api/v4/ingest/.
    ingestSha256(
      sha256: string,
      options: IngestOptions = {},
    ): Promise<Record<string, unknown>> {
      if (!SHA256_RE.test(sha256)) throw new Error(`Invalid sha256: ${sha256}`);
      const body: Record<string, unknown> = { sha256 };
      if (options.params) body.params = options.params;
      if (options.metadata) body.metadata = options.metadata;
      if (options.notification_queue)
        body.notification_queue = options.notification_queue;
      if (options.notification_threshold !== undefined)
        body.notification_threshold = options.notification_threshold;
      if (options.alert !== undefined) body.generate_alert = options.alert;
      return this.requestJson("POST", "/api/v4/ingest/", body, options);
    }
  • The switch case in CallToolRequestSchema that dispatches 'al4_ingest_sha256' to client.ingestSha256() with the sha256 argument and ingest options.
    case "al4_ingest_sha256":
      result = await client.ingestSha256(a.sha256 as string, buildIngestOptions(a));
      break;
  • Tool definition with name, description, and inputSchema for al4_ingest_sha256 (requires sha256 string, optional notification_queue, alert, description, classification, services, metadata).
    {
      name: "al4_ingest_sha256",
      description:
        "Asynchronously ingest a file by SHA256 hash into AssemblyLine. The file must already exist in the AL4 file store.",
      inputSchema: {
        type: "object",
        properties: {
          sha256: { type: "string" },
          notification_queue: { type: "string" },
          alert: { type: "boolean" },
          description: { type: "string" },
          classification: { type: "string" },
          services: { type: "array", items: { type: "string" } },
          metadata: { type: "object", additionalProperties: { type: "string" } },
        },
        required: ["sha256"],
      },
    },
  • buildIngestOptions helper function used to construct ingest options (notification_queue, alert, plus base submit options) from the raw arguments.
    function buildIngestOptions(args: Record<string, unknown>) {
      return {
        ...buildSubmitOptions(args),
        notification_queue: args.notification_queue as string | undefined,
        alert: args.alert as boolean | undefined,
      };
    }
  • src/index.ts:126-143 (registration)
    Tool registration within the TOOLS array – the tool object at index [9] is named 'al4_ingest_sha256' and is included in the list returned by ListToolsRequestSchema.
    {
      name: "al4_ingest_sha256",
      description:
        "Asynchronously ingest a file by SHA256 hash into AssemblyLine. The file must already exist in the AL4 file store.",
      inputSchema: {
        type: "object",
        properties: {
          sha256: { type: "string" },
          notification_queue: { type: "string" },
          alert: { type: "boolean" },
          description: { type: "string" },
          classification: { type: "string" },
          services: { type: "array", items: { type: "string" } },
          metadata: { type: "object", additionalProperties: { type: "string" } },
        },
        required: ["sha256"],
      },
    },
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions asynchrony and a prerequisite (file must exist), but does not detail side effects, return values, authentication requirements, or state what happens on failure. This is adequate but not comprehensive.

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 two short sentences that directly state the primary action and a critical prerequisite. There is no extraneous information, and each sentence adds value.

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 the tool's complexity (7 parameters, nested objects, asynchronous behavior) and the absence of an output schema or annotations, the description is severely lacking. It does not cover what happens after ingestion, how to monitor progress, or the meaning of most parameters, making it incomplete for effective use.

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

Parameters1/5

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

Schema description coverage is 0%, and the description does not explain any of the 7 parameters beyond implying sha256 is the file identifier. Parameters like notification_queue, services, and metadata are entirely undocumented, leaving the agent without guidance on their purpose or format.

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 action (asynchronously ingest), the resource (file by SHA256 hash), and the system (AssemblyLine). It also specifies a prerequisite (file must already exist in the file store), which distinguishes it from ingestion tools that might upload files.

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 context on when to use this tool (when you have a SHA256 of an existing file) and implicitly excludes files not in the store. However, it does not explicitly mention alternatives like al4_ingest_file or al4_ingest_url, nor does it state when not to use it.

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/Stankye/vibe-assemblylinev4-mcp'

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