Skip to main content
Glama
Stankye

AssemblyLine 4 MCP Server

by Stankye

al4_submit_file

Submit a local file to AssemblyLine for immediate malware analysis. Returns a submission ID for tracking results.

Instructions

Submit a local file to AssemblyLine for immediate synchronous analysis. Returns a submission ID. Limited to 5 concurrent submissions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
file_pathYesAbsolute path to the file to analyse
nameNoOverride display name for the file
descriptionNoHuman-readable description of the submission
classificationNoClassification label (e.g. TLP:CLEAR)
servicesNoSpecific services to run (empty = all defaults)
metadataNoKey/value metadata attached to the submission

Implementation Reference

  • The `submitFile` method on AL4Client that executes the actual tool logic for al4_submit_file. It validates the file exists, builds the JSON part with name/params/metadata, and calls multipartUpload to POST to /api/v4/submit/.
    async submitFile(
      filePath: string,
      options: SubmitOptions = {},
    ): Promise<Record<string, unknown>> {
      if (!existsSync(filePath)) throw new Error(`File not found: ${filePath}`);
      const jsonPart: Record<string, unknown> = {};
      if (options.name) jsonPart.name = options.name;
      if (options.params) jsonPart.params = options.params;
      if (options.metadata) jsonPart.metadata = options.metadata;
      return this.multipartUpload(
        "/api/v4/submit/",
        filePath,
        jsonPart,
        options.name ?? basename(filePath),
        options,
      );
    }
  • The switch-case handler in the MCP request handler that dispatches al4_submit_file to client.submitFile with args from the request.
    case "al4_submit_file":
      result = await client.submitFile(a.file_path as string, buildSubmitOptions(a));
      break;
  • The tool schema registration for al4_submit_file, defining its name, description, and inputSchema (file_path required, plus optional name, description, classification, services, metadata).
    // ── Submit (synchronous, quota-limited) ────────────────────────────────
    {
      name: "al4_submit_file",
      description:
        "Submit a local file to AssemblyLine for immediate synchronous analysis. Returns a submission ID. Limited to 5 concurrent submissions.",
      inputSchema: {
        type: "object",
        properties: {
          file_path: { type: "string", description: "Absolute path to the file to analyse" },
          name: { type: "string", description: "Override display name for the file" },
          description: { type: "string", description: "Human-readable description of the submission" },
          classification: { type: "string", description: "Classification label (e.g. TLP:CLEAR)" },
          services: {
            type: "array",
            items: { type: "string" },
            description: "Specific services to run (empty = all defaults)",
          },
          metadata: {
            type: "object",
            additionalProperties: { type: "string" },
            description: "Key/value metadata attached to the submission",
          },
        },
        required: ["file_path"],
      },
  • src/index.ts:25-56 (registration)
    The TOOLS array that registers al4_submit_file (and all other tools) on the MCP server, listed via ListToolsRequestSchema.
    const TOOLS = [
      {
        name: "al4_whoami",
        description: "Return details about the currently authenticated AssemblyLine user.",
        inputSchema: { type: "object", properties: {}, required: [] },
      },
      // ── Submit (synchronous, quota-limited) ────────────────────────────────
      {
        name: "al4_submit_file",
        description:
          "Submit a local file to AssemblyLine for immediate synchronous analysis. Returns a submission ID. Limited to 5 concurrent submissions.",
        inputSchema: {
          type: "object",
          properties: {
            file_path: { type: "string", description: "Absolute path to the file to analyse" },
            name: { type: "string", description: "Override display name for the file" },
            description: { type: "string", description: "Human-readable description of the submission" },
            classification: { type: "string", description: "Classification label (e.g. TLP:CLEAR)" },
            services: {
              type: "array",
              items: { type: "string" },
              description: "Specific services to run (empty = all defaults)",
            },
            metadata: {
              type: "object",
              additionalProperties: { type: "string" },
              description: "Key/value metadata attached to the submission",
            },
          },
          required: ["file_path"],
        },
      },
  • The buildSubmitOptions helper function that transforms raw request arguments into the SubmitOptions shape used by client.submitFile.
    function buildSubmitOptions(args: Record<string, unknown>) {
      return {
        name: args.name as string | undefined,
        params: {
          ...(args.description ? { description: args.description as string } : {}),
          ...(args.classification ? { classification: args.classification as string } : {}),
          ...(args.services
            ? { services: { selected: args.services as string[] } }
            : {}),
        },
        metadata: args.metadata as Record<string, string> | undefined,
      };
    }
Behavior3/5

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

No annotations provided, so description carries full burden. It discloses the synchronous nature and the concurrency limit, which are useful behavioral traits. However, it lacks details on what happens when the limit is reached (e.g., queuing or error), error handling, or authentication requirements. Moderate transparency.

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?

Two short, direct sentences with no wasted words. The key information (action, synchronicity, return value, concurrency limit) is front-loaded. Excellent conciseness.

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?

While the description covers the basic purpose and a constraint, it omits details about error handling, how to check submission progress, and the maximum file size. Given the complexity (6 params, no output schema), it could be more complete but is minimally adequate.

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?

Input schema provides full descriptions for all 6 parameters (100% coverage). The description adds no extra semantic value beyond the schema. Baseline score of 3 is appropriate since the schema already documents parameters adequately.

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 submits a local file to AssemblyLine for synchronous analysis and returns a submission ID. The verb 'submit' and resource 'local file' are specific, and it distinguishes from siblings like al4_submit_sha256 or al4_submit_url which handle different input types.

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?

No explicit guidance on when to use this tool versus alternatives. While the name implies local files, the description does not mention when-not to use it, prerequisites, or alternative tools for remote files or hashes. The mention of '5 concurrent submissions' hints at a limit but not a decision rule.

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