Skip to content

Argus API MCP STDIO server

Table of Contents

Setup

The user or operator of this MCP server is responsible for selecting and configuring a legitimate and trusted LLM or agent. This includes ensuring that the chosen LLM or agent is appropriate for handling Argus data and complies with the organization’s security, privacy, and access-control requirements.

Steps for setup

  1. Pull Argus API MCP STDIO server docker image from GHCR.

    Docker image located at mnemonic-no Github packages

    Example for pulling the latest image:

    1
    docker pull ghcr.io/mnemonic-no/argus-api-mcp-server-stdio:latest

  2. Configure ARGUS_API_KEY with Argus-API-Key as environment variable.

    To request an Argus-API-key, create an Argus case with the following details: 

    1
2
3
    Case type: Other
Service: Administrative
Priority: Low
    Use the following text in the case description: 
    1
    “Hi, on behalf of my organization, we accept the terms of service for the APIs and the MCP server. We would like to request an API service account for use with the Argus MCP instance.

    More details for obtaining Argus-API-Key can be found here.

  3. Configure agent e.g. Codex with docker image of MCP server. Refer to chapter below.

Codex MCP setup example

Requires Argus API key specified as environment variable ARGUS_API_KEY for the docker runtime.

Note: Because agent like Codex and Claude Code etc. are updating frequently, it's difficult to keep example of MCP configuration always up-to-date. Please refer to agent vendor's official documentation (e.g. OpenAI for Codex) when you set up MCP STDIO server.

Example: Codex setup with Docker remote daemon

  • Setup environment variable for ARGUS_API_KEY if not already setup 
    1
2
3
4
    # Export Argus API Key
export ARGUS_API_KEY=....
# Optional: export DOCKER_HOST pointing to remote docker host
export DOCKER_HOST=...
  • Configure .codex/config.toml with Docker running the MCP STDIO server image and optionally with remote docker host (configured by DOCKER_HOST environment variable): 
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
    [mcp_servers.argus-api-mcp-server-stdio]
command = "docker"
args = [
  "run",
  "--name", "argus-api-mcp-server-stdio", # container name needs to be unique for the daemon run
  "--rm",
  "-i",
  "-e", "ARGUS_API_KEY",
  "ghcr.io/mnemonic-no/argus-api-mcp-server-stdio:latest"
]
env_vars = ["DOCKER_HOST", "ARGUS_API_KEY"]

Note: - Must provide unique container name for the docker daemon, otherwise codex will fail to start the MCP server.

Example: Codex setup with Podman local daemon

  • Setup environment variable for ARGUS_API_KEY if not already setup 
    1
2
    # Export Argus API Key
export ARGUS_API_KEY=....
  • Configure .codex/config.toml with Podman running the MCP STDIO server image 
     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
    [mcp_servers.argus-api-mcp-server-stdio]
command = "podman"
args = [
  "run",
  "--name", "argus-api-mcp-server-stdio", # container name needs to be unique for the daemon run
  "--replace",
  "-i",
  "-e", "ARGUS_API_KEY",
  "ghcr.io/mnemonic-no/argus-api-mcp-server-stdio:latest"
]
env_vars = ["ARGUS_API_KEY"]
    Note:
  • Must provide unique container name for the docker daemon, otherwise codex will fail to start the MCP server.

MCP STDIO server startup validation

During startup of MCP STDIO server, it will attempt to fetch session info on the supplied API key by 

1
2
GET /authentication/v1/session
-H 'Argus-API-Key: $ARGUS_API_KEY'
It will throw out and fail the startup of MCP STDIO server when ARGUS_API_KEY is not found or failed to fetch session info using the ARGUS_API_KEY.

MCP tool invokes Argus REST API

When MCP Tools defined in the MCP STDIO server gets invoked that leads to call Argus REST API call, the API key will be supplied to each request's header as Argus-API-Key: $ARGUS_API_KEY.

MCP Tool Documentation

Alarm

Asset

Case

  • Argus Case Search Translator MCP Tools: Documentation for tools that help build and validate Argus case search queries before execution.
  • Argus Case REST MCP Tools: Documentation for tools that invoke REST calls towards Argus APIs to search for cases, fetch case details, fetch case comments and tags, and list allowed case metadata values.

Customer

  • Argus Customer REST MCP Tools: Documentation for tools that invoke REST calls towards Argus APIs for customer information and customer properties.

Data Store

  • Argus Data Store REST MCP Tools: Documentation for tools that invoke REST calls towards Argus APIs for datastore descriptors and centrally managed datastore entries.

Event

  • Argus Event Search Translator MCP Tools: Documentation for tools that help build and validate Argus event search and statistics queries before execution.
  • Argus Event REST MCP Tools: Documentation for tools that invoke REST calls towards Argus APIs to search for events, calculate event statistics, list events associated with a case, fetch event details, and fetch event lineage.

Metric

Event Filter

Analysis Filter

Annotation Filter

Match Filter

PassiveDNS

Reputation

Lessons Learned

Building an Internal Chat Agent with MCP Servers

When implementing an internal chat portal or agent with Argus MCP servers and an open-source LLM, such as Qwen 3.6, do not rely on the model alone to decide whether live Argus data is needed.

In testing, we observed two important failure modes:

  • The LLM could hallucinate Argus results.
  • The LLM could answer as if it had called an MCP server, while actually fabricating Argus data from model knowledge, assumptions, or conversation history.

For operational data, this is risky. Argus data is customer-specific, freshness-sensitive, and often security-relevant. The agent harness around the model should therefore enforce tool usage, freshness rules, and result validation.

The Argus MCP tools include source-of-truth rules in their tool descriptions to guide the LLM toward using tool results instead of guesses. This helps, but it is not enough on its own. Tool descriptions, system prompts, routing logic, validation, testing, and model behavior need to work together to get reliable results.

Recommended controls:

  • Use a restricted system prompt that clearly forbids fabricated live Argus results.
  • Require MCP tool calls for Argus data questions, especially alerts, incidents, cases, entities, investigation details, search results, statistics, status, and other customer-specific operational data.
  • Treat follow-up questions that ask for freshness, status, updates, or changes as requiring a new MCP tool call.
  • Mark previous MCP results as stale after the next user message, unless the user is only asking to explain, summarize, format, or reason about already shown results.
  • Make the answer state when it is based on the latest MCP tool call.
  • If a required MCP tool is unavailable, ambiguous, or fails, return that fact instead of fabricating an answer.
  • If an MCP tool returns no matching data, say that the latest tool call returned no matching data.

Example system prompt rules:

1
2
3
4
5
6
7
8
9
[
  "Never invent, infer, or guess live Argus results. Do not answer live Argus questions from model knowledge, assumptions, or previous conversation history.",
  "Use the relevant MCP tool whenever the user asks for Argus data, including alerts, incidents, cases, entities, investigation details, search results, statistics, status, or other customer-specific operational data.",
  "If the user asks for an update, refresh, latest, current, now, status, check again, new alerts, whether something changed, or any other freshness-sensitive Argus result, you must call the relevant MCP tool before answering.",
  "Previous MCP results become stale after the next user message unless that message only asks you to explain, summarize, format, or reason about already shown results without requiring new data.",
  "When answering from MCP data, explicitly say that the answer is based on the latest tool call.",
  "If a required MCP tool is unavailable, ambiguous, or fails, say that the tool call failed or cannot be made and do not fabricate a result. Ask for clarification if needed to choose the right tool.",
  "If a tool returns no matching data, report that the latest tool call returned no matching data instead of filling gaps with assumptions."
]

For higher assurance, add a validation step before showing the final answer to the user. A second LLM pass can compare the draft answer against the MCP tool result and check whether:

  • every factual claim is supported by the tool output
  • the answer clearly says it is based on the latest tool call
  • no Argus result was invented or filled in from assumptions
  • tool errors and empty results are reported plainly

This validation step costs extra model calls and increases response time, but it can reduce hallucination risk for internal operational workflows.

Also build test scenarios from common user requests in your environment. Include direct searches, follow-up questions, freshness-sensitive requests, empty result cases, ambiguous requests, and tool failure cases. These scenarios help identify where the agent harness needs stricter routing, validation, clarification, or refusal behavior.

The controls listed here are not the full set of possible improvements. Agent reliability can also depend on model parameters, tool-calling settings, context-window limits, retrieval behavior, prompt templates, and the quality of the underlying LLM. Using a stronger or better-aligned model may reduce risk, but it should still be paired with explicit tool-use and validation controls for live Argus data.

If your organization has the capability, consider training or distilling a dedicated model on top of a base model using Q&A examples from real Argus MCP workflows. The training data should focus on the identified use cases, correct tool-selection behavior, grounded answers from MCP results, and safe handling of missing or failed tool calls.