Skip to main content
Glama
DeepAgentLabs

deep-agentic-core-mcp

Official

Export Chaos Report as AIOS Run

chaos.export_aios_run
Read-only

Convert chaos reports into AI Operations v0.4-draft run artifacts and validate rule-cited conformance. Reuse the session's last experiment if no report is provided.

Instructions

Convert a chaos report into an AI Operations v0.4-draft run artifact (via agentic-chaos>=0.5.1) and validate it with rule-cited conformance. 'report' may be omitted to reuse the session's last experiment.

Input Schema

NameRequiredDescriptionDefault
reportNo
statusNoObserved run status; derived from crashed/timed_out when omitted.
session_idNoSession to read/write shared state under. Defaults to 'default'.
workflow_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.5

TDQS

B3.4/5.0
Behavior3/5

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

With readOnlyHint=true already declaring the safety profile, the annotations carry the main burden, and the description adds useful extras: the agentic-chaos>=0.5.1 dependency, the fact that validation is rule-cited conformance, and the session-fallback default. It does not, however, disclose whether an artifact is persisted or returned, nor what the conformance output looks like, leaving a gap on a tool whose session parameter explicitly mentions read/write shared state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with the primary action front-loaded and the report-omission default placed second. No filler, though the stacked jargon ('AI Operations v0.4-draft run artifact', 'rule-cited conformance') costs some immediate readability.

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?

For a no-required-parameter tool with a nested free-form 'report' object and no output schema, the description supplies the essentials an agent needs: the conversion target, the validation behavior, and the fallback when the report is absent. Remaining ambiguity, chiefly the workflow_id semantics, is minor and does not block 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 coverage is 50%: 'status' and 'session_id' are already documented in the schema, while 'report' and 'workflow_id' are bare. The description rescues 'report' by explaining it may be omitted in favor of the session's last experiment, but it says nothing about 'workflow_id' or the shape of the nested report object, so coverage is only partially compensated.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and output ('Convert a chaos report into an AI Operations v0.4-draft run artifact') plus a secondary action ('validate it with rule-cited conformance'). An agent can distinguish it from list/run tools, but it never names or differentiates from siblings like spec.validate_artifact or chaos.run_experiment, which handle adjacent validation/run concerns.

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?

The only conditional given is that 'report' may be omitted to reuse the session's last experiment, which is really parameter behavior rather than tool-selection guidance. There is no statement of when to prefer this over spec.validate_artifact or chaos.run_experiment, nor any prerequisite or ordering advice for a multi-step export-then-validate flow.

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