AssemblyLine 4 MCP Server
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@AssemblyLine 4 MCP Serversubmit URL http://malware.test.com for analysis"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
AssemblyLine 4 MCP Server
MCP server for the AssemblyLine 4 malware analysis platform.
Setup
npm install
npm run buildCopy .env.example to .env and fill in your credentials:
AL4_URL=https://your-al4-instance:443
AL4_USERNAME=your_username
AL4_APIKEY=keyname:your_api_key_passwordAPI keys are created in AssemblyLine under Account → Security → Manage API Keys.
Running
AL4_URL=... AL4_USERNAME=... AL4_APIKEY=... node dist/src/index.jsClaude Code integration
Add to your ~/.claude/claude_desktop_config.json (or project .claude/settings.json):
{
"mcpServers": {
"assemblyline4": {
"command": "node",
"args": ["/absolute/path/to/vibe-assemblylinev4-mcp/dist/src/index.js"],
"env": {
"AL4_URL": "https://your-al4-instance:443",
"AL4_USERNAME": "your_username",
"AL4_APIKEY": "keyname:password"
}
}
}
}Self-signed / dev certificates
Set AL4_TLS_VERIFY=false in the env block to skip TLS verification.
Available tools
Tool | Description |
| Current authenticated user |
| Sync file submission (path on disk) |
| Sync URL submission |
| Sync submission by hash (file must exist in AL4 store) |
| Async file ingestion with optional notification queue |
| Async URL ingestion |
| Async hash ingestion |
| Poll whether a submission has finished |
| Submission metadata |
| Complete results tree |
| Summarised results |
| Drain a notification queue |
| Lucene search over submissions |
| Lucene search over alerts |
| Lucene search over the file store |
| Lucene search over service results |
| Fetch a single alert by ID |
| File metadata by SHA256 |
| All service results for a file |
| Highest score for a file |
Testing & CI
Two layers of tests live under test/:
test/integration.ts— drivesAL4Clientand the MCP server end-to-end against an in-process mock of the AL4 REST API (test/mock-al4.ts). Fast, hermetic, runs on every push/PR via.github/workflows/ci.yml.npm testtest/e2e.ts— drivesAL4Clientagainst a real Assemblyline 4 appliance. The.github/workflows/e2e.ymlworkflow spins up the upstreamassemblyline-docker-composeappliance (core stack only — Elasticsearch, Redis, MinIO, AL core/UI/nginx; service images are skipped to fit the runner's disk quota), bootstraps the admin user, mints an API key, and runs the suite. Because submissions are not blocked on services, they complete with an empty result tree — enough to validate every API the MCP server exposes.The e2e workflow runs:
nightly (05:27 UTC),
on
workflow_dispatch,on PRs labelled
run-e2e.
To reproduce locally:
bash scripts/ci/start-al4.sh APIKEY=$(AL4_URL=https://localhost AL4_ADMIN_USER=admin AL4_ADMIN_PASSWORD=admin \ bash scripts/ci/create-apikey.sh) AL4_URL=https://localhost AL4_USERNAME=admin AL4_APIKEY=$APIKEY \ AL4_TLS_VERIFY=false node dist/test/e2e.js
Running CI locally
Two equivalent paths, depending on what you want to validate:
The fast workflow, exactly as GitHub Actions runs it — via
act:# one-time: install act (https://nektosact.com/installation/) npm run ci:local # runs .github/workflows/ci.yml in Dockeractreads.actrc, which pins the catthehackerubuntu:act-latestimage (has Node, git, curl, etc.). This is the cleanest way to catch regressions in the workflow YAML itself.The e2e workflow —
actis not recommended here because the job spins up its own docker-compose stack, and docker-in-docker viaactmakes networking and disk usage painful. Use the wrapper script instead, which runs the same steps directly on your host:npm run e2e:local # build → start appliance → mint key → run e2e → teardown KEEP_RUNNING=1 npm run e2e:local # leave appliance up afterwards for poking SKIP_BUILD=1 npm run e2e:local # skip npm ci + tsc, reuse dist/Or break it apart:
npm run e2e:up # just bring up the appliance APIKEY=$(npm run --silent e2e:apikey) AL4_URL=https://localhost AL4_USERNAME=admin AL4_APIKEY=$APIKEY \ AL4_TLS_VERIFY=false npm run test:e2eRequirements: Linux host (or WSL2 / macOS), docker + compose plugin, node 20+, ~15 GB free disk. Windows users: run the scripts from inside WSL — the appliance won't come up under Git Bash because of how docker-compose paths and
opensslinteract on native Windows.
Available Tools
20 toolsal4_alert_getC
Get a specific alert by its alert ID.
| Name | Required | Description | Default |
|---|---|---|---|
| alert_id | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'Get', which implies a read operation, but does not disclose potential errors (e.g., alert not found), permissions, rate limits, or side effects. This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, which aids quick reading, but it sacrifices necessary detail. It is front-loaded with the key action, yet the brevity leaves the user without critical context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema, no annotations), the description should at least hint at the return value or error conditions. It fails to provide a complete picture, leaving the agent to infer behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for its single parameter 'alert_id'. The description adds no meaning beyond 'by its alert ID', failing to specify format, constraints, or examples. It does not compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'alert', and the method 'by its alert ID'. It distinguishes from the sibling 'al4_search_alerts', which searches for alerts, implying this is for retrieving a single known alert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific alert ID, but does not explicitly state when not to use it or mention alternatives. The sibling 'al4_search_alerts' exists but is not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
al4_file_infoB
Get metadata for a file by its SHA256 hash.
| Name | Required | Description | Default |
|---|---|---|---|
| sha256 | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read operation ('Get metadata') but lacks details on permissions, rate limits, or potential errors. Without annotations, the agent has minimal behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that efficiently conveys the tool's purpose with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple metadata retrieval tool with one input and no output schema, the description is adequate but could be improved by mentioning what metadata fields are returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning by specifying the parameter is a 'SHA256 hash', but does not clarify format (e.g., hex, length) or provide further details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves metadata for a file using its SHA256 hash, distinguishing it from sibling tools like al4_file_results or al4_file_score which likely return other data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor on any prerequisites or limitations. The agent must infer its use from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
al4_file_resultsC
Get all service analysis results for a file by SHA256.
| Name | Required | Description | Default |
|---|---|---|---|
| sha256 | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It does not disclose the structure of results (e.g., list of scans), pagination, or whether it is read-only. Only states it returns 'results'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundancy. Efficient for purpose, but lacks structure (e.g., no bullet points or parameter details).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 1 parameter and no output schema, the description is too minimal. It could specify the type of results (e.g., from all engines) and how to interpret them. Sibling tools exist but no differentiation is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description does not add any meaning beyond parameter name 'sha256'. No format (hex, length) or example provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves all service analysis results for a file by SHA256. Verb 'Get' and resource 'service analysis results' are specific, and it distinguishes from siblings like al4_file_info (info) and al4_file_score (score).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as al4_search_results or al4_submission_summary. Agent must infer based on tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
al4_file_scoreB
Get the highest score assigned to a file across all submissions.
| Name | Required | Description | Default |
|---|---|---|---|
| sha256 | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It correctly implies a read-only operation (getting a score) and is not misleading. However, it does not disclose any potential behaviors like caching, authorization requirements, or error conditions, which are minimal but still unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence with no redundancy. Every word contributes to the core purpose, making it highly efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (one parameter, no output schema), the description covers the basic function but omits explanation of the return value format and the parameter's role. It is adequate for a minimal tool but could better complete the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 mention the required 'sha256' parameter or explain what it represents. The phrase 'a file' is vague; the agent must rely on the schema property name, which may not be sufficiently informative.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'highest score assigned to a file', and the scope 'across all submissions'. It accurately distinguishes the tool from siblings like al4_file_info or al4_search_files, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 al4_file_info or al4_file_results. It does not specify contextual triggers or exclusions, leaving the agent to infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
al4_ingest_fileA
Asynchronously ingest a local file into AssemblyLine. Preferred for high-volume workflows. Returns an ingest ID. Results arrive on a notification queue.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the file | |
| notification_queue | No | Queue name for completion notifications | |
| alert | No | Generate an alert if score exceeds threshold | |
| name | No | ||
| description | No | ||
| classification | No | ||
| services | No | ||
| metadata | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses async operation, return of ingest ID, and notification queue, but lacks details on side effects, permissions, or rate limits. No annotations provided, so description carries full burden—adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with key information, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, async behavior, and no output schema, the description omits details about return value format, polling mechanism, and usage of optional parameters. Incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds no extra meaning beyond the input schema's sparse descriptions for file_path and notification_queue. With 38% schema coverage, it fails to compensate for undocumented parameters like name, services, or metadata.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'ingest', resource 'local file', and async behavior. Mentions 'preferred for high-volume workflows' and distinguishes from siblings that ingest by hash or URL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends for high-volume workflows and implies async nature, but does not provide exclusions or compare to synchronous alternatives like al4_submit_file.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
al4_ingest_get_messagesB
Retrieve completion notifications from an ingest notification queue.
| Name | Required | Description | Default |
|---|---|---|---|
| notification_queue | Yes | Queue name passed when ingesting | |
| count | No | Max messages to retrieve (default 100) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only mentions retrieval but omits details like whether messages are deleted after retrieval, polling behavior, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded. It efficiently states the core purpose, but could benefit from a second sentence for context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and simple input, the description should still explain return values or behavior when queue is empty. It is insufficient for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no meaning beyond the schema; it mentions 'notification queue' aligning with the parameter but doesn't explain formats or defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves completion notifications from an ingest notification queue, with a specific verb and resource. It distinguishes itself from sibling tools like al4_ingest_file or al4_search_submissions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No context is provided about when to use this tool versus alternatives such as al4_submission_is_complete or other retrieval tools. The description lacks any guidance on prerequisites or scenario suitability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
al4_ingest_sha256A
Asynchronously ingest a file by SHA256 hash into AssemblyLine. The file must already exist in the AL4 file store.
| Name | Required | Description | Default |
|---|---|---|---|
| sha256 | Yes | ||
| notification_queue | No | ||
| alert | No | ||
| description | No | ||
| classification | No | ||
| services | No | ||
| metadata | No |
TDQS
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.
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.
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.
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.
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.
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.
al4_ingest_urlC
Asynchronously ingest a URL into AssemblyLine.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| notification_queue | No | ||
| alert | No | ||
| description | No | ||
| classification | No | ||
| services | No | ||
| metadata | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only mentions asynchronous behavior. It does not disclose side effects, authentication requirements, rate limits, or what happens to the URL after ingestion. This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) but at the cost of necessary information. For a tool with 7 parameters and no other documentation, it is under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no annotations, no output schema), the description is critically incomplete. It fails to explain ingestion process, result handling, error conditions, or parameter usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the 7 parameters beyond their names. Schema description coverage is 0%, and the description does not explain any parameter like 'notification_queue', 'classification', or 'services'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (asynchronously ingest) and the resource (a URL) and distinguishes from siblings that ingest files or hashes. However, it does not differentiate from similar sibling 'al4_submit_url', which may cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over alternatives like 'al4_submit_url' or 'al4_ingest_file'. The description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
al4_search_alertsC
Search AssemblyLine alerts using Lucene query syntax.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| fields | No | ||
| rows | No | ||
| offset | No | ||
| sort | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only mentions Lucene query syntax but does not disclose pagination, sorting, field selection, or other behavioral traits. With no annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it sacrifices completeness for brevity, omitting critical details about parameters and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, 5 parameters, and no annotations, the description fails to provide sufficient context for correct usage, especially given the complexity of search tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only adds meaning for the 'query' parameter by specifying Lucene syntax. Other parameters (fields, rows, offset, sort) are undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches AssemblyLine alerts using Lucene query syntax, distinguishing it from sibling tools that search other resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like al4_search_files or al4_search_results, nor any prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
al4_search_filesA
Search the AssemblyLine file store using Lucene query syntax (e.g. 'type:executable/windows AND seen.last:[now-7d TO now]').
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| fields | No | ||
| rows | No | ||
| offset | No | ||
| sort | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the use of Lucene query syntax but does not mention behavioral traits like read-only nature, authentication needs, rate limits, or pagination. It 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with an inline example. It is front-loaded and efficient, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and poor parameter documentation, the description is incomplete. It does not explain the return format, how to interpret results, or provide details on most parameters, making it insufficient for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explain parameters. It only describes the 'query' parameter with an example, leaving 'fields', 'rows', 'offset', and 'sort' undocumented. This is insufficient for proper use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (Search), the resource (AssemblyLine file store), and the query syntax (Lucene) with an example. It distinguishes from sibling tools that search other resources (alerts, results, submissions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use this tool (search file store) and provides a usage example with Lucene syntax. However, it does not explicitly mention when not to use or name specific alternatives, though the sibling names imply those.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
al4_search_resultsC
Search AssemblyLine service results using Lucene query syntax.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| fields | No | ||
| rows | No | ||
| offset | No | ||
| sort | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. The only behavioral hint is 'Lucene query syntax', but it does not disclose other aspects like whether the operation is read-only, what happens to the system, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and front-loads the purpose. However, it is overly terse and missing important details, so it does not earn a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description is far too brief. It does not explain what 'results' are, how pagination works, or what the return format is, making it incomplete for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should add meaning to parameters. It only mentions that the 'query' parameter uses Lucene syntax, leaving 'fields', 'rows', 'offset', and 'sort' completely unexplained. This is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search AssemblyLine service results' which identifies a verb and resource, but 'results' is vague and does not distinguish this tool from siblings like al4_search_alerts or al4_search_files. The purpose is somewhat clear but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other search tools in the sibling list. The description does not mention scenarios, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
al4_search_submissionsA
Search AssemblyLine submissions using Lucene query syntax (e.g. 'params.submitter:admin AND al_score:[500 TO *]').
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Lucene query string | |
| fields | No | Comma-separated fields to return | |
| rows | No | Number of results (default 25) | |
| offset | No | Pagination offset | |
| sort | No | Sort field and direction, e.g. 'times.submitted desc' |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention that the operation is read-only (search implies it but not stated), authentication requirements, rate limits, or result format. The description lacks sufficient behavioral context for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with an example, conveying the core functionality without extraneous words. It is efficient and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 5-parameter schema (all described) and no output schema, the description covers core purpose but lacks behavioral details and comprehensive guidance. It is adequate for a straightforward search tool but leaves gaps in transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, setting baseline at 3. The description adds value with a Lucene query example for the 'query' parameter, but does not elaborate on fields, rows, offset, or sort beyond their schema descriptions. Overall, modest addition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches AssemblyLine submissions using Lucene query syntax, with an illustrative example. It distinguishes from sibling tools like al4_search_alerts and al4_search_files by specifying 'submissions' as the target resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching submissions via Lucene syntax, but does not explicitly contrast with alternatives or provide when-not-to-use guidance. However, the distinct resource name ('submissions') among siblings provides implicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
al4_submission_fullC
Get the complete results tree for a finished submission, including all service results and scores.
| Name | Required | Description | Default |
|---|---|---|---|
| sid | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It merely states what the tool does ('get'), but does not mention potential side effects, required permissions, rate limits, or behavior on non-finished submissions. This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the key action and scope. It is concise without being cryptic, though it could be more information-dense without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is too minimal. It does not clarify what the 'complete results tree' entails in terms of structure or content, nor does it differentiate effectively from sibling tools like al4_submission_get or al4_search_results. Significant gaps remain for an agent to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'sid' has no description in the schema (0% coverage), and the tool description adds no explanation about what 'sid' represents (e.g., submission ID). The description fails to provide any additional meaning beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the complete results tree for a finished submission, including service results and scores. It distinguishes from siblings like al4_submission_get (likely simpler) and al4_submission_summary (summary only) by specifying 'complete results tree' and 'finished submission', but does not explicitly differentiate from all similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage only when the submission is finished ('for a finished submission'), which provides context, but it does not explicitly state when not to use it (e.g., for in-progress submissions) or mention alternatives like al4_submission_get or al4_submission_summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
al4_submission_getC
Get metadata and status for a submission.
| Name | Required | Description | Default |
|---|---|---|---|
| sid | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits like read-only nature, authentication needs, or rate limits. It only states the action without context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence, but it lacks structure or front-loading of key information. It is adequately sized but not informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and minimal parameter documentation, the description is incomplete. It does not describe the return format or any constraints, which is insufficient for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds minimal value. It does not explain the 'sid' parameter or its format, leaving the agent reliant on external knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'metadata and status for a submission,' which distinguishes it from sibling tools like al4_submission_full and al4_submission_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as al4_submission_full or al4_submission_summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
al4_submission_is_completeC
Check whether a submission has finished processing.
| Name | Required | Description | Default |
|---|---|---|---|
| sid | Yes | Submission ID |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It only says 'check', but doesn't specify the return format (e.g., boolean) or any side effects. This is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded and efficient, though it could benefit from slightly more detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple check tool among many siblings, the description is too terse. It lacks information about the output or when to use it in a workflow, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'sid' is fully described in the input schema as 'Submission ID'. The description adds no extra meaning, so baseline of 3 applies given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if a submission has finished processing. It distinguishes from siblings like al4_submission_get by focusing on completion status, but could be more explicit about what 'complete' means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For example, it doesn't mention that it's a lightweight check before retrieving full submission details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
al4_submission_summaryC
Get a summarised view of a submission's results.
| Name | Required | Description | Default |
|---|---|---|---|
| sid | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of disclosing behavior. It only states the tool returns a 'summarised view' but does not specify what is included in that summary, the scope of data returned, or any side effects. Since it's a read operation, the description should clarify whether it's safe and non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence), but it sacrifices clarity and completeness for brevity. It lacks detail needed for effective tool invocation. While it is concise, it is under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the domain (submission results with many sibling tools), no output schema, and lack of annotations, the description is incomplete. It does not explain how the summary differs from the full view, nor does it mention return formatting or pagination. For a tool with one parameter, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage for parameter descriptions. The only parameter 'sid' has no description, and the tool description does not clarify that 'sid' is the submission ID. With no parameter documentation, the description adds no meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool provides a summarised view of a submission's results. It identifies the resource (submission) and the action (get a summarised view). However, it does not differentiate from sibling tools like al4_submission_full or al4_submission_get, which could also be described as retrieving results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 its siblings. For example, it does not explain that this tool should be used when only a summary is needed, while al4_submission_full should be used for complete details. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
al4_submit_fileA
Submit a local file to AssemblyLine for immediate synchronous analysis. Returns a submission ID. Limited to 5 concurrent submissions.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the file to analyse | |
| name | No | Override display name for the file | |
| description | No | Human-readable description of the submission | |
| classification | No | Classification label (e.g. TLP:CLEAR) | |
| services | No | Specific services to run (empty = all defaults) | |
| metadata | No | Key/value metadata attached to the submission |
TDQS
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.
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.
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.
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.
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.
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.
al4_submit_sha256B
Submit a file by its SHA256 hash to AssemblyLine for immediate synchronous analysis. The file must already exist in the AL4 file store.
| Name | Required | Description | Default |
|---|---|---|---|
| sha256 | Yes | SHA256 hash of the file | |
| description | No | ||
| classification | No | ||
| services | No | ||
| metadata | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses 'immediate synchronous analysis' and an existence constraint, but does not detail side effects, permissions, or potential latency. For a submission tool, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), front-loading the core purpose. While minimal, every word contributes to understanding the tool's primary function. It could benefit from slightly more detail without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters (including nested objects), no output schema, and no annotations, the description is insufficient. It fails to explain the return value, how to use optional parameters, or post-submission behavior, leaving significant gaps for effective agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema_description_coverage is only 20% (only 'sha256' has a description in the schema). The description does not elaborate on the other 4 parameters (description, classification, services, metadata), which are important for submission. The description adds no semantic value beyond what the schema provides for those parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (submit), the resource (file by SHA256 hash), and the context (immediate synchronous analysis, file must exist in store). It effectively distinguishes from sibling tools like al4_submit_file (which likely handles file uploads) and al4_ingest_sha256 (ingestion).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite (file must already exist in the AL4 file store) but does not explicitly state when to use this tool versus alternatives. It implies usage for synchronous analysis but lacks explicit when-not or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
al4_submit_urlC
Submit a URL to AssemblyLine for immediate synchronous analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to analyse | |
| description | No | ||
| classification | No | ||
| services | No | ||
| metadata | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions 'synchronous analysis' but fails to detail side effects, authentication, rate limits, or response behavior. This is insufficient for a submission tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no unnecessary words. However, it may be too brief given the tool's complexity, but conciseness is still high.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, nested objects, and no output schema, the description is incomplete. It does not explain what the tool returns, how optional parameters affect behavior, or any usage prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only 'url' has a description). The description does not explain the other four parameters ('description', 'classification', 'services', 'metadata'), failing to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Submit a URL' and specifies context 'AssemblyLine' and 'immediate synchronous analysis', effectively distinguishing from siblings like al4_submit_file and al4_ingest_url.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor does it specify prerequisites or exclusions. The phrase 'immediate synchronous analysis' implies use but lacks explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
al4_whoamiA
Return details about the currently authenticated AssemblyLine user.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool returns user details, implying a read-only operation. No contradictions or misleading statements; adequate for a simple query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is clear and front-loaded. Every word serves a purpose; no wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with no output schema. Description conveys the essential purpose. It could hint at return details, but given low complexity, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no parameters, and schema description coverage is 100%. Description adds no parameter information beyond schema, meeting the baseline of 3 as per rubric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns details about the currently authenticated AssemblyLine user. Verb 'Return' and resource 'details about the currently authenticated user' are specific and distinct from sibling tools that deal with files, alerts, or submissions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly provide when or when not to use this tool or mention alternatives. The intended usage is implied by the tool name and purpose, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
20 tool updates
v0.1.0- First observed
al4_alert_get - First observed
al4_file_info - First observed
al4_file_results - First observed
al4_file_score - First observed
al4_ingest_file - First observed
al4_ingest_get_messages - First observed
al4_ingest_sha256 - First observed
al4_ingest_url - First observed
al4_search_alerts - First observed
al4_search_files - First observed
al4_search_results - First observed
al4_search_submissions - First observed
al4_submission_full - First observed
al4_submission_get - First observed
al4_submission_is_complete - First observed
al4_submission_summary - First observed
al4_submit_file - First observed
al4_submit_sha256 - First observed
al4_submit_url - First observed
al4_whoami
TDQS
Scored across 20 tools
Each tool targets a distinct operation: alerts, files, ingest, search, submissions, submit, and user info. Tools within the same group are clearly differentiated (e.g., al4_submission_full vs al4_submission_summary). No ambiguity exists.
All tools use the consistent `al4_verb_noun` pattern with snake_case. Verbs are predictable (get, search, submit, ingest) and nouns match resources. No mixing of styles.
20 tools fully cover the AssemblyLine API without being excessive. Each tool serves a specific need for file analysis, alerting, and submission management, fitting the platform's scope.
The toolset provides comprehensive file operations (info, results, score, ingestion, submission), search, and alert retrieval. Missing update/delete operations for submissions or alerts, but these are minor gaps for an analysis platform.
Related MCP Connectors
Submit files and URLs to a malware sandbox, poll scans, fetch reports, hashes and IOCs.
STIX indicators (single/batch), batch CVE lookups w/ EPSS/CISA KEV, ATT&CK dossiers.
Third-party sandbox verdict on any artifact in one call, no account. Also an agent marketplace.
Enrich, search, assess, and manage threat intelligence through 80+ typed MCP tools.
