Skip to main content
Glama

Argus Console — AI Agent Test Lab

argus_run_simulation

Run a FREE deterministic MOCK battery against a registered agent: the full Argus pipeline (money-guard gate + fault probes) simulated from the endpoint's seed — no request ever reaches the agent endpoint. Use this BEFORE any real engine run to preview verdicts, demo the flow, or sanity-check registration. Does not consume paid quota; rolling cap 25 runs / 24h. Waits for completion and returns the report.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "agent": "<agent>"
    },
    "name": "argus_run_simulation"
  }
}

Input Schema

NameRequiredDescriptionDefault
agentYesAgent name or id (see argus_list_agents)
batteryNoOptional battery id; defaults to the role's starter battery

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

No annotations are supplied, so the description bears the full burden, and it delivers: no request reaches the agent endpoint (so there are no side effects on the target), no paid quota is consumed, there is a rolling cap of 25 runs per 24h, and the call blocks until completion and returns the report. These are exactly the behavioral facts an agent needs before invoking a simulation tool.

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?

Three dense sentences and no waste: the mock and no-side-effects constraint leads, then the when-to-use guidance, then cost and latency caveats. Every sentence adds information that is not repeated anywhere else in the definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is a two-parameter simulator with no output schema, and the description covers safety profile, cost, rate limit, blocking behavior, and the return value ('returns the report'). Details of the report itself are handled by the sibling argus_get_run_report, so nothing critical is missing before a correct call.

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

Parameters3/5

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

Schema description coverage is 100%, and the two parameters are already documented in the schema, including the starter-battery default. The description adds only the implicit prerequisite that the agent must be registered, so the schema does most of the work and the baseline of 3 applies.

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 pairs a specific verb with a specific resource ('Run a FREE deterministic MOCK battery') and immediately distinguishes the tool from the real pipeline by stating that the full Argus pipeline is simulated from the endpoint's seed. An agent can tell this apart from argus_run_engine without opening either schema.

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

Usage Guidelines5/5

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

'Use this BEFORE any real engine run to preview verdicts, demo the flow, or sanity-check registration' states both the timing and the use cases explicitly, and implicitly names the alternative (a real engine run) as the thing to do later. This leaves nothing important to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.