Skip to main content
Glama
lyonzin

Cymulate MCP Tools

by lyonzin

TTP Designer — compose a realistic Cymulate scenario for one MITRE technique

cymulate_ttp_designer
Read-onlyIdempotent

Design attack and evasion scenarios for Cymulate security validation, producing realistic commands that trigger EDR/SIEM alerts, with IOCs and detection rules.

Instructions

LOCAL composition tool. Does NOT call the Cymulate API. Returns a structured directive the assistant uses to: (1) query the operator knowledge-rag for real tradecraft (LOLBAS, hacktricks, RTFM, Falcon detection queries), (2) fill a Cymulate scenario/template payload with commands that ACTUALLY trigger EDR/SIEM (not synthetic defaults), (3) produce Mermaid diagram + expected IOCs + detection rules. HARD BLOCK: this tool produces NEW scenarios/templates only. NEVER use this output to modify or delete Cymulate default templates. Always POST to /v2/scenario/create or /v1/purple-team/templates.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
intentYesNatural-language description of what to simulate, e.g. "credential dumping via LSASS abuse using LOLBAS, evasion medium, target Windows 11 with Defender + Falcon"
evasion_levelNonone = raw payload (baseline); basic = renamed binaries + encoded args; advanced = DLL sideloading + AMSI/ETW patching hints; apt = full tradecraft (staged C2, jitter, LotL)basic
output_formatNoev_scenario = simple EV scenario (POST /v2/scenario/create); advanced_template = Purple Team template with executions (POST /v1/purple-team/templates)advanced_template
stack_contextNoDefender stack in target env, e.g. "CrowdStrike Falcon + Splunk ES + Zscaler + Defender for Endpoint"
detection_focusNoWhich detection layers to target — used to enrich sigma/KQL rules for validation
mitre_techniqueNoMITRE ATT&CK technique ID, e.g. T1003.001. If omitted the assistant infers from intent.
target_platformNowindows
cleanup_requiredNoMUST be true for shared/production tenants to keep dashboards clean. Includes rollback command and artifact removal
execution_contextNouser
Behavior5/5

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

Beyond the readOnlyHint and idempotentHint annotations, the description reveals key behavioral traits: it does NOT call the API, it returns a directive for subsequent steps, and it includes a HARD BLOCK against modification. This adds significant context that annotations alone don't convey, with no contradictions.

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?

The description is compact yet information-dense, front-loaded with the crucial 'LOCAL composition tool' and structured with numbered steps. It could be slightly shortened, but every sentence adds necessary context, making it well-organized and readable.

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 tool with 9 parameters and no output schema, the description provides a thorough overview: local nature, workflow steps, return type (structured directive), hard constraints, and destination endpoints. It gives the agent enough context to invoke the tool appropriately and understand follow-up actions.

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 78% (close to high threshold). The description does not add parameter-specific explanations beyond the schema, but the schema itself has solid descriptions for all params. The description's step-by-step workflow gives general context but doesn't clarify individual parameters further. Baseline of 3 is appropriate.

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 explicitly states the tool is a LOCAL composition tool that returns a structured directive, distinguishing it from API-calling siblings. It names the specific resource (Cymulate scenario/template for one MITRE technique) and provides a clear verb ('compose'), making its purpose unambiguous.

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?

The description gives explicit when-to-use context: producing NEW scenarios/templates. It also provides hard exclusions: NEVER modify/delete Cymulate default templates, and explicitly names the API endpoints to use afterward. This clearly differentiates from sibling tools that modify or delete.

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/lyonzin/cymulate-mcp-tools'

If you have feedback or need assistance with the MCP directory API, please join our Discord server