Generates Splunk detection queries, artefacts, and integration hooks for Splunk ES.
Click on "Install 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., "@CyberSim Pro MCP Server Create a ransomware simulation for a healthcare organization."
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.
CyberSim Pro is a professional-grade Model Context Protocol (MCP) server purpose-built for cybersecurity training, purple-team collaboration, and executive readiness. It equips AI assistants and automation pipelines with structured tools to generate scenarios, simulate adversaries, analyse telemetry, investigate incidents, perform forensics, and publish board-ready reports—all while recording an immutable audit trail.
Related MCP server: Elastic Security MCP App
Adaptive adversary scenarios tied to real-world APT/FIN actor playbooks, sector-aware CVEs, and plugin-provided intel.
Command-chain drill-down: pseudo CLI steps (guardrailed) for every attack phase to map outputs to analyst tooling.
Detection engineering bundles: Sigma, Splunk, and KQL artefacts, MITRE ATT&CK heatmaps, gap analysis, and SOAR integration hooks.
Incident response suite: deep investigations, forensic artefacts, purple-team scorecards, facilitation kits, executive dashboards, maturity roadmaps, and procurement briefs.
Operational guardrails: append-only audit logs, approval-gated RBAC, stop_simulation kill switch, role-based prompt templates, and formal policy & ethics guide.
Telemetry replay & metrics: overlay real PCAP/EDR/SIEM events on simulations, auto-capture readiness metrics, and expose historical trends.
Risk & control automation: export compensating controls, sync with GRC platforms, and produce auditor-ready validation digests.
# Clone the repository (or copy into your workspace)
cd cybersim-pro-mcp
# Install dependencies
npm install
# Build TypeScript sources
npm run build
# Start the MCP server over stdio
node build/index.js# Build the image (from the repo root)
docker build -t cybersim-pro-mcp .
# Launch in stdio mode (for Claude, Cline, etc.)
docker run --rm -i cybersim-pro-mcpExpose tools to REST clients or GPT Actions.
npm run serve:http # defaults to http://localhost:8787Secure with environment variables:
CYBERSIM_API_KEY – require Authorization: Bearer <key> header
CYBERSIM_IP_ALLOW – comma-separated list (127.0.0.1,::1,local,203.0.113.10)
CYBERSIM_APPROVAL_TOKEN – shared secret required for restricted tools (simulate_attack, stop_simulation, replay_telemetry)
CYBERSIM_RBAC_CONFIG – optional path to a JSON role policy (see Role-Based Access & Approvals)
Metrics, control feeds, and audit digests are persisted to ./metrics/, ./controls/, and ./logs/ respectively.
Enable hash-chained logging by setting CYBERSIM_AUDIT_HMAC_KEY (optionally supply CYBERSIM_AUDIT_CHAIN_ID for multi-tenant tracking).
Use CYBERSIM_AUDIT_SEAL_KEY (or reuse the HMAC key) to sign exported seals; set _ENCODING=base64 when providing base64 secrets.
Generate an immutable seal + regulator bundle at any time:
npm run audit:seal -- --log ./logs/audit.log --format json.gzOutputs are written to ./logs/seals/ (JSON seal plus optional compressed bundle) and include chainHash, chainVerified, signature metadata, and the last approval token event.
Schedule npm run audit:seal via CI/cron to push weekly bundles into your immutable evidence locker (see .github/workflows/audit-seal.yml for a GitHub Actions example).
Summarise governance progress for Legal/Risk with npm run compliance:report (see docs/COMPLIANCE_ROADMAP.md).
Sample health & scenario creation:
curl -s http://localhost:8787/health
curl -s -X POST http://localhost:8787/tool/create_scenario \
-H 'Content-Type: application/json' \
-d '{
"type": "ransomware",
"difficulty": "advanced",
"environment": "corporate",
"sector": "finance",
"adversary_profile": "fin7",
"focus_cves": ["CVE-2024-21410"],
"operator": {"id": "alice", "role": "controller"},
"approval_token": "${CYBERSIM_APPROVAL_TOKEN}"
}' | jqmacOS path: ~/Library/Application Support/Claude/claude_desktop_config.json
{
"mcpServers": {
"cybersim-pro": {
"command": "node",
"args": ["/absolute/path/to/cybersim-pro-mcp/build/index.js"]
}
}
}For Docker-backed execution:
{
"mcpServers": {
"cybersim-pro-docker": {
"command": "docker",
"args": ["run", "--rm", "-i", "cybersim-pro-mcp"]
}
}
}Open Command Palette → “Cline: Open MCP Settings” and add:
{
"mcpServers": {
"cybersim-pro": {
"command": "node",
"args": ["/absolute/path/to/cybersim-pro-mcp/build/index.js"]
}
}
}Wrapper scripts in ./scripts/ support runtime switching via CYBERSIM_RUNTIME.
Each tool can be invoked through MCP clients or directly via the HTTP bridge. Examples below use jq for clarity.
create_scenarioGenerate a tailored scenario with adaptive adversary content.
HTTP Request
curl -s -X POST http://localhost:8787/tool/create_scenario \
-H 'Content-Type: application/json' \
-d '{
"type": "apt",
"difficulty": "expert",
"environment": "cloud",
"sector": "government",
"adversary_profile": "apt29",
"focus_cves": ["CVE-2023-23397"]
}' | jq '.id, .description, .threatIntel'What you get
Scenario ID (e.g., SCN-...)
Sector-aligned objectives and timelines
Adversary profile with CVEs, detection opportunities, plugin insight list
Use the returned scenarioId to reference the scenario in follow-up drills, reports, or evidence.
simulate_attackSimulate a multi-phase attack and inspect the command-chain drill-down.
HTTP Request
curl -s -X POST http://localhost:8787/tool/simulate_attack \
-H 'Content-Type: application/json' \
-d '{
"attack_type": "ransomware",
"target": "FILESERVER-001",
"intensity": "high"
}' | jq '{simulationId, commandChain: .commandChain[0:5], phases: [.phases[0].artifacts[0]]}'Highlights
commandChain array details redacted pseudo commands, safeguards, and MITRE references for each phase.
phases include techniques, detection methods, and evidence artefacts.
simulationId feeds into stop_simulation or reporting workflows.
analyze_networkAnalyse network segments and receive detection artefacts plus coverage insights.
HTTP Request
curl -s -X POST http://localhost:8787/tool/analyze_network \
-H 'Content-Type: application/json' \
-d '{
"network_segment": "DMZ",
"duration": 30,
"focus": ["anomalies", "threats", "vulnerabilities"]
}' | jq '{
statistics: .statistics.bandwidthUtilization,
sigma: .detectionArtifacts.sigma[0],
splunk: .detectionArtifacts.splunk[0].query,
heatmap: .mitreHeatmap[0:3],
integration: .integrationHooks
}'Output
Auto-generated Sigma/Splunk/KQL detections with descriptions & tags
MITRE ATT&CK + D3FEND heatmap coverage with gap analysis
Integration hooks for Splunk ES, Sentinel, and Cortex XSOAR
Recommendations aligned with anomalies/vulnerabilities/threats
investigate_incidentRun a timeline-driven investigation with evidence, root cause, containment, and remediation details.
HTTP Request
curl -s -X POST http://localhost:8787/tool/investigate_incident \
-H 'Content-Type: application/json' \
-d '{
"incident_id": "INC-2024-001",
"scope": "deep_dive"
}' | jq '{severity, timeline: .timeline.events[0:3], rootCause, containmentActions[0]}'Deliverables
Attack path reconstruction with dwell time
Findings and supporting evidence (with chain-of-custody records)
Containment actions, remediation steps, and lessons learned
forensics_analysisProduce digital forensic artefacts for memory, disk, network, logs, or registry sources.
HTTP Request
curl -s -X POST http://localhost:8787/tool/forensics_analysis \
-H 'Content-Type: application/json' \
-d '{
"artifact_type": "disk",
"system_id": "WORKSTATION-001",
"analysis_depth": "comprehensive"
}' | jq '{artifactSummary: .findings[0], chainOfCustody: .chainOfCustody[0]}'Expect curated findings, hash validation, custody records, and preservation guidance.
generate_reportGenerate executive, incident, vulnerability, or compliance reports with optional facilitation mode.
HTTP Request
curl -s -X POST http://localhost:8787/tool/generate_report \
-H 'Content-Type: application/json' \
-d '{
"report_type": "executive",
"incident_ids": ["INC-2024-001", "INC-2024-002"],
"include_recommendations": true,
"mode": "facilitation"
}' | jq '{
executiveSummary,
scorecard: .scorecard.metrics,
facilitationKit: .facilitationKit.agenda,
dashboard: .executiveDashboard.heatmap,
roadmap: .maturityRoadmap.milestones,
procurement: .procurementBrief.faqs
}'Key sections:
Executive summary & risk posture
Purple-team scorecard metrics and lessons
Facilitation kit (kickoff prompt, teleprompter notes, agenda)
Executive dashboard (risk, downtime, financial exposure)
Maturity roadmap (NIST CSF, CMMC, ISO 27001 alignment)
Procurement brief (FAQs, legal considerations, risk controls)
stop_simulationKill a single simulation or all active runs with audit logging.
# Stop a specific simulation ID
target="SIM-1759281782112"
curl -s -X POST http://localhost:8787/tool/stop_simulation \
-H 'Content-Type: application/json' \
-d "{\"simulation_id\": \"$target\", \"reason\": \"Executive requested early termination\", \"operator\": {\"id\": \"alice\", \"role\": \"controller\"}, \"approval_token\": \"${CYBERSIM_APPROVAL_TOKEN}\"}"
# Stop everything (returns list of terminated runs)
curl -s -X POST http://localhost:8787/tool/stop_simulation \
-H 'Content-Type: application/json' \
-d '{"operator":{"id":"alice","role":"controller"},"approval_token":"'"${CYBERSIM_APPROVAL_TOKEN}"'"}'The audit logger records the termination reason, counts, and timestamps for compliance evidence.
replay_telemetryOverlay raw telemetry (PCAP/EDR/SIEM exports) against a live simulation to validate coverage.
HTTP Request
curl -s -X POST http://localhost:8787/tool/replay_telemetry \
-H 'Content-Type: application/json' \
-d '{
"simulation_id": "SIM-1759281782112",
"telemetry": [
{"timestamp":"2024-05-01T10:00:00Z","indicator":"powershell.exe","description":"Beacon to rare domain","techniqueId":"t1059.001"}
],
"operator": {"id": "alice", "role": "controller"},
"approval_token": "'"${CYBERSIM_APPROVAL_TOKEN}"'"
}' | jq '{matchedTechniques, detectionGaps, observations}'Matched techniques confirm detections fired; detectionGaps highlight phases lacking telemetry coverage. Recommended controls are appended automatically to the compensating-control feed.
list_metricsSummarise readiness metrics across all exercises.
curl -s -X POST http://localhost:8787/tool/list_metrics -H 'Content-Type: application/json' -d '{}' | jqOutputs include total exercises, reports generated, and average detection/containment times alongside the latest trend entries.
export_controlsExport the consolidated compensating-control feed (detections, automations, gap closures).
curl -s -X POST http://localhost:8787/tool/export_controls -H 'Content-Type: application/json' -d '{}' | jq '.[0:5]'Each entry includes category, source, priority, and payload ready for SIEM/SOAR ingestion.
sync_risk_registerGenerate REST payloads for governance platforms such as ServiceNow GRC, Archer, or OneTrust.
curl -s -X POST http://localhost:8787/tool/sync_risk_register \
-H 'Content-Type: application/json' \
-d '{
"system": "servicenow",
"incident_id": "INC-2024-001",
"priority": "Critical",
"owner": "risk.governance@example.com"
}' | jqThe response provides the endpoint, HTTP method, payload, and checklist for operators to update the risk register.
generate_validation_reportProduce an auditor-facing summary with hashed proof of recent CyberSim activity.
curl -s -X POST http://localhost:8787/tool/generate_validation_report -H 'Content-Type: application/json' -d '{}' | jqThe digest contains the SHA-256 hash, total entries, and redacted samples suitable for regulator briefings.
Profiles (e.g., APT29, FIN7) embed motivations, campaigns, preferred tactics, CVEs, and countermeasures.
PluginRegistry (src/utils/pluginRegistry.ts) lets you register sector or vendor-specific intel providers. Each plugin can inject CVEs, notes, and detection enhancements.
Scenario outputs surface threatIntel.pluginInsights referencing contributing providers.
Simulations include commandChain entries describing pseudo commands, safeguards, and technique references. Use these to:
Map red-team actions to your tooling (e.g., WMI logs, PowerShell policy)
Provide narrations during live tabletop facilitation
Export to internal red-team wikis without exposing live payloads
Network analysis responses include:
Sigma rules (YAML-string), Splunk searches, Sentinel KQL queries
Playbooks for triage/containment
MITRE ATT&CK + D3FEND mappings and coverage heatmaps
Integration hooks for Splunk ES saved searches, Sentinel analytics rules, and Cortex XSOAR playbooks
generate_report outputs provide everything needed for leadership alignment:
Executive dashboard, downtime estimates, financial impact
Purple-team metrics & lessons learned
Facilitation kit for hybrid workshops
Maturity roadmap with quarterly milestones and framework alignment
Procurement brief with FAQ, legal, and risk-control summaries
Every tool invocation is appended to logs/audit.log (configurable via CYBERSIM_AUDIT_LOG_DIR) and chained with SHA-256 hashes plus optional HMAC signatures (CYBERSIM_AUDIT_HMAC_KEY, CYBERSIM_AUDIT_CHAIN_ID).
Entries capture timestamp, tool, sanitized arguments, metadata, and error messages; validation exposes chainVerified, lastChainHash, and signature provenance.
npm run audit:seal produces a signed seal and regulator bundle under logs/seals/, ready for object-lock storage or shareable attestations.
npm run compliance:report surfaces control maturity, framework mappings, and roadmap freshness for monthly stakeholder updates.
The stop_simulation tool halts activity immediately and records the termination reason for traceability.
generate_validation_report produces hashed digests and anomaly flags that auditors can cross-check against sealed exports.
Identity Roadmap
Enterprise SSO/SCIM integration is tracked in docs/SSO_SCIM_DESIGN.md; prepare server.json with an identity block and customise config/role-mappings.example.json when enabling the gateway.
OIDC callbacks: POST /api/auth/oidc/callback (JSON body with id_token); SAML assertions: POST /api/sso/assert (form-encoded SAMLResponse supported). Fetch SAML metadata via GET /api/sso/metadata.
SCIM v2 endpoints (/api/scim/v2/Users, /api/scim/v2/Groups) require identity.scim.bearerToken or CYBERSIM_SCIM_TOKEN; weekly audit seal workflow captures provisioning evidence.
Provide IdP MFA context to bypass restricted-tool MFA holds via identity.sso.oidc.mfaSatisfiedAmrValues / mfaSatisfiedAcrValues (defaults recognise common AMR/ACR values); sessions persist until sessionTtlMinutes expires or X-Cybersim-Session token is rotated.
Resolved IdP sessions now flow into every simulator/manager pipeline; returned JSON payloads include a provenance block so scenarios, simulations, investigations, forensics, metrics, and control feeds all reference the initiating identity or operator.
MCP stdio clients inherit the same provenance envelope when operator metadata is supplied, allowing downstream tools to align artefacts with human or automated actors even without an active IdP session.
After upgrading, run npm run migrate:provenance to backfill legacy metrics/control logs with the new provenance fields before exporting historical evidence.
High-impact tools (simulate_attack, stop_simulation, replay_telemetry) respect role policies defined via CYBERSIM_RBAC_CONFIG.
Restricted tools require a shared approval token (CYBERSIM_APPROVAL_TOKEN), enabling dual-control or change-ticket workflows.
Operator metadata is captured in the audit log, supporting segregation-of-duties reviews.
Default policy grants analysts access to low-risk tooling while controllers/CISOs can execute adversary simulations.
sync_risk_register generates ready-to-post payloads for ServiceNow GRC, Archer, OneTrust, or custom systems.
export_controls provides the compensating-control feed derived from detection packs, telemetry gaps, and automation hooks.
Telemetry replay and network analysis automatically feed the control register so lessons learned become enforceable controls.
Learning Path – follow beginner → intermediate → advanced exercises (see Learning Path section below) to ramp analysts.
Role-Based Prompt Templates – prebuilt red/blue/purple/executive prompts in docs/ROLE_BASED_PROMPTS.md.
Policy & Ethics Guide – acceptable use, regulatory alignment, and safety checklist in docs/POLICY_AND_ETHICS.md.
Benchmark Library – curated scenarios per industry with KPIs in docs/BENCHMARK_LIBRARY.md.
Community Sharing Program – contribute sanitized scenarios/detections using the workflow in docs/COMMUNITY_PROGRAM.md.
Beginner: phishing or simple malware, focus on indicators and detection basics.
Intermediate: ransomware/APT scenarios, run investigations and network analysis.
Advanced: full kill-chain drills, deep forensics, executive reporting, automation via HTTP bridge.
Fork the repository and branch from main (or community/main when contributing to shared content).
Add code or documentation, ensuring TypeScript builds succeed (npm run build).
For community packs, follow sanitisation and metadata guidelines in docs/COMMUNITY_PROGRAM.md.
Submit a pull request; audit logs and documentation updates are encouraged alongside new features.
Role-based prompts: docs/ROLE_BASED_PROMPTS.md
Policy & ethics: docs/POLICY_AND_ETHICS.md
Plugin guide: docs/PLUGIN_ARCHITECTURE.md
Benchmark scenarios: docs/BENCHMARK_LIBRARY.md
Community sharing workflow: docs/COMMUNITY_PROGRAM.md
For assistance:
Review the documentation above.
Inspect source code comments and example responses.
Reproduce minimal scenarios (create_scenario → simulate_attack) to isolate issues.
File issues or discussions on the GitHub repository.
Released under the MIT License. Use, modify, and adapt CyberSim Pro MCP Server for authorised defensive purposes.
Analyze network traffic and identify potential security issues
| Name | Required | Description | Default |
|---|---|---|---|
| focus | No | Specific areas to focus on (anomalies, vulnerabilities, threats) | |
| duration | No | Analysis duration in minutes | |
| network_segment | Yes | Network segment to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It fails to mention whether the analysis is read-only, long-running, requires special permissions, or produces any output — leaving the agent uninformed about side effects or execution expectations.
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 with no redundancy or filler. It is front-loaded with the main action, but its brevity limits structural organization; despite this, it earns its place by conveying the core purpose efficiently.
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?
The description is severely under-specified for a tool with no output schema and no annotations. It does not explain what the analysis returns, how results are presented, any time/scope implications, or how it fits into the broader workflow, making it inadequate for confident 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 100%, with all three parameters (focus, duration, network_segment) having meaningful descriptions. The tool description adds no extra information about the parameters, but the schema already provides clear semantics, so the baseline of 3 applies.
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's primary action ('Analyze network traffic') and its goal ('identify potential security issues'), using a specific verb and resource. However, it does not explicitly differentiate it from sibling tools like forensics_analysis or investigate_incident, which could also analyze network-related 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?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of appropriate scenarios, prerequisites, or exclusions, leaving the agent without clear decision-making support for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a cybersecurity training scenario with customizable parameters
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Type of security scenario | |
| sector | No | Business sector or mission domain to tailor adversary selection | |
| difficulty | Yes | Difficulty level | |
| focus_cves | No | List of CVE identifiers to emphasize in the scenario | |
| environment | No | Target environment (e.g., corporate, cloud, IoT) | |
| adversary_profile | No | Explicit adversary profile key (e.g., apt29, fin7) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since annotations are absent, the description must carry the full burden of behavioral disclosure. It only says 'Create' without detailing side effects, persistence, permissions, or what happens to existing scenarios. No additional behavioral traits are revealed.
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 with no fluff. However, it lacks any structural elements like bullets or sections that could make the information more scannable. For the bare purpose, it is efficient but not richly structured.
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 6 parameters, no output schema, and no annotations, the description is grossly insufficient. It does not explain what the tool returns, how it manages state, or any operational context. A user/agent needs far more detail to use this 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 description coverage is 100%, so the baseline is 3. The description's 'customizable parameters' adds no semantic value beyond what the schema already provides. It does not clarify parameter relationships or usage patterns.
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 'Create a cybersecurity training scenario' with a specific verb and resource. It is unambiguous about the tool's core function, though it does not explicitly differentiate from sibling tools like simulate_attack. The name itself strongly implies its unique role.
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?
There is no guidance on when to use this tool versus alternatives. No mention of prerequisites, typical use cases, or exclusions. Sibling tools like simulate_attack or investigate_incident are not referenced, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export recommended compensating controls derived from CyberSim analyses
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the action and source but does not explicitly disclose that the operation is read-only or whether it has side effects. 'Export' implies a non-mutating operation, but this is not stated, and the output format is not mentioned.
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, front-loaded sentence that is free of unnecessary words or technical jargon. It efficiently communicates the tool's purpose without any waste.
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 parameterless export tool, the description is nearly complete. It explains what is exported and the source, which is sufficient for an agent to decide when to call it. However, it does not specify the output format or whether a prior analysis is required, leaving a slight gap in expected 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 tool has zero parameters, and the baseline for this case is 4. The description adds meaning by clarifying what is exported (compensating controls) and from where (CyberSim analyses), which is useful context beyond the empty 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 uses a specific verb 'Export' and specifies the resource 'recommended compensating controls' along with their source 'derived from CyberSim analyses'. This clearly distinguishes it from siblings like generate_report or sync_risk_register, which have 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 implies usage in the context of CyberSim analyses but does not explicitly state when to use this tool versus alternatives. It lacks a clear when-to-use or when-not-to-use statement, leaving the agent to infer based on the name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform digital forensics analysis on system artifacts
| Name | Required | Description | Default |
|---|---|---|---|
| system_id | Yes | System identifier | |
| artifact_type | Yes | Type of artifact to analyze | |
| analysis_depth | No | Depth of forensics analysis |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behaviors. It only says 'perform... analysis' with no indication of side effects, read-only nature, data access, or potential impact on the system. This is insufficient for a tool that could be intrusive or require permissions.
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 that brevity comes at the cost of substance. It is under-specified rather than appropriately concise, providing no additional context beyond the tool name.
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?
Without an output schema, annotations, or any behavioral details, the description is incomplete for a complex task like digital forensics. It doesn't explain what results are returned, whether it's a one-time analysis or ongoing, or any operational nuances.
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 describes all three parameters with clear meaning (e.g., artifact_type enum, system_id type), and schema coverage is 100%. The description adds nothing beyond that, but the schema itself is sufficient for parameter understanding.
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 gives a clear verb ('perform') and resource ('digital forensics analysis on system artifacts'), but it's vague and doesn't distinguish from sibling tools like 'investigate_incident' or 'analyze_network'. It conveys the general function but lacks specificity about scope.
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 about when to use this tool vs alternatives. There is no mention of prerequisites, typical scenarios, or exclusions, so an agent would not know how to choose it over the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate comprehensive security assessment or incident reports
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Optional rendering mode (standard, facilitation, executive) | |
| report_type | Yes | Type of report to generate | |
| incident_ids | No | Related incident IDs | |
| include_recommendations | No | Include remediation recommendations |
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 only says 'generate', without explaining whether it writes data, requires specific input data, has side effects, or what the output format is. This is insufficient for an agent to understand the tool's impact.
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 with no unnecessary words. It is front-loaded with the core action, but its brevity comes at the cost of missing useful context. Still, it is efficiently written.
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 four parameters, no annotations, and no output schema, the description leaves significant gaps. It does not explain the report types, expected inputs, output structure, or when this tool is appropriate, making it incomplete for an agent to use confidently.
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 schema descriptions cover 100% of parameters, so the baseline is 3. The tool description adds no parameter-specific information beyond what the schema already provides, which is acceptable given the high 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 generates security assessment or incident reports, with a specific verb and resource. However, it does not explicitly distinguish itself from the sibling tool 'generate_validation_report', and the term 'comprehensive' is vague, leaving some ambiguity about the exact scope.
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. It does not mention any prerequisites, exclusions, or scenarios where this tool is preferred, such as when to pick generate_report over generate_validation_report or investigate_incident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Produce an auditor-facing validation digest of recent CyberSim activity
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states the action (produce) but does not disclose side effects, output format or contents, permissions, or any limitations. For a tool with no annotation safety hints, this leaves significant gaps in what the agent can expect.
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, front-loaded sentence with no wasted words. It efficiently conveys the purpose, audience, and scope, making it easy for an agent to parse and act on.
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 and no annotations, the description is the only source of context. It is minimal and does not explain what a 'validation digest' contains, how it is delivered, or how recent the activity is. While the low complexity (no parameters) helps, the vagueness of the output leaves the description only 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?
The tool has zero parameters, so the input schema already fully covers the interface. According to the rubric, 0 parameters yields a baseline score of 4. The description adds no parameter details, but none are needed.
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 uses the specific verb 'Produce' with a clear resource, 'auditor-facing validation digest', and scopes it to 'recent CyberSim activity'. This clearly distinguishes it from the sibling 'generate_report' and other tools, which are more generic or focus on different aspects.
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 phrase 'auditor-facing' provides a clear context for when to use this tool (for audit validation), but it does not explicitly compare to alternatives or state when not to use it. This is more than implied usage but lacks explicit exclusions, aligning with a clear context without delimiting guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Conduct incident response investigation with timeline reconstruction
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Investigation scope | |
| incident_id | Yes | Unique incident identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only mentions 'timeline reconstruction' without explaining side effects, data access, security requirements, or output format. This leaves substantial ambiguity for an 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, front-loaded sentence that conveys the core action and outcome with no unnecessary words. It is concise and well-structured.
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 and absence of annotations or output schema, the description is too sparse. It does not explain what 'investigation' entails, what the response will contain, or how 'timeline reconstruction' is delivered, leaving critical gaps for an agent.
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 100%, so a baseline of 3 applies. The description itself adds no extra meaning beyond the schema, and the enum values (initial/full/deep_dive) are not elaborated.
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 identifies the tool's purpose with a specific verb ('conduct') and resource ('incident response investigation'), and adds a distinctive feature ('timeline reconstruction') that helps distinguish it from siblings like forensics_analysis.
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 indication of when to use this tool versus alternatives such as forensics_analysis or analyze_network. It lacks any contextual cues about scenarios that warrant investigation or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarise historical exercise metrics and readiness trends
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only operation ('Summarise') and limits scope to 'historical' data, but it does not disclose return format, pagination, potential rate limits, or any other behavioral traits. The description is too minimal to provide meaningful 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?
The description is a single, concise sentence that states the purpose without any filler words. Every word contributes to understanding the tool's function, making it appropriately sized and front-loaded.
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 that the tool has no parameters and no output schema, the description is reasonably complete for a simple list/summary tool. It conveys the core function and scope (historical exercise metrics and readiness trends). However, it could be improved by mentioning what the output looks like or any limitations, but for its simplicity, it covers the essentials.
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 tool has zero parameters, so the schema already covers everything. The description does not need to add parameter details, and the baseline for no parameters is 4. The description's mention of 'historical' and 'readiness trends' gives some context but does not conflict with the empty 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 uses a specific verb ('Summarise') and identifies clear resources ('historical exercise metrics and readiness trends'). It distinguishes itself from sibling tools like analyze_network or simulate_attack by focusing on metrics summarization rather than analysis or simulation. However, it lacks the precision of examples like 'List ALL calls in date range' because it does not specify the exact scope or output format.
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. The description merely states what it does, without any 'when to use' or 'when not to use' instructions, nor does it mention alternative tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replay lab telemetry (PCAP/EDR/SIEM exports) against a simulation to identify coverage gaps
| Name | Required | Description | Default |
|---|---|---|---|
| operator | No | Operator context required for restricted playback | |
| telemetry | No | Array of telemetry events (e.g., SIEM or EDR events) | |
| scenario_id | No | Optional scenario identifier to contextualise telemetry | |
| simulation_id | Yes | Simulation identifier returned by simulate_attack | |
| approval_token | No | ||
| telemetry_base64 | No | Base64-encoded JSON array of telemetry events (alternative to telemetry array) |
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 does not explain side effects, permission requirements, whether replay mutates the simulation, or what output is produced. The word 'replay' hints at a non-destructive activity, but this is not explicit.
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 no wasted words. It front-loads the action and data type while also conveying the purpose, making it appropriately concise.
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?
The tool has six parameters, nested objects, no output schema, and no annotations, so a one-sentence description is insufficient for operational context. It does not explain how the approval_token/operator fields are used or what the replay result looks like, leaving significant gaps for an agent invoking this tool.
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 high (83%), and the schema already describes telemetry, simulation_id, scenario_id, and telemetry_base64. The description adds no parameter-level meaning, but given the high schema coverage, the baseline of 3 is appropriate.
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 uses a specific verb ('replay') and resource ('lab telemetry') and clearly states the goal ('identify coverage gaps'). It implies the tool operates on an existing simulation, which distinguishes it from creation/simulation tools, though it does not explicitly name a sibling alternative.
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 siblings like simulate_attack or generate_validation_report, nor does it mention prerequisites or exclusions. The purpose implies a use case, but there is no actionable selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Simulate a cyberattack with realistic attack vectors and TTPs
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target system or network segment | |
| operator | No | Operator metadata enforcing RBAC policies | |
| intensity | No | Attack intensity level | |
| attack_type | Yes | Type of attack to simulate | |
| approval_token | No | Approval token required for high-impact simulations |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries full responsibility for disclosing behavior. It mentions "simulate" which hints at non-real effects, but it fails to clarify side effects, safety, or the explicit approval requirement hinted by the approval_token parameter. The phrase "realistic attack vectors" makes the level of danger ambiguous.
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, focused sentence that immediately communicates the core purpose without any wasted words. It is concise and easy 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?
Despite having moderate complexity (5 params, nested objects, no output schema), the description lacks operational context. It does not explain the simulation's execution model, potential side effects, approval requirements, or expected output. The parameter schema covers fields, but the overall tool behavior is under-specified for a potentially high-impact simulation tool.
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%, meaning all 5 parameters have descriptions in the schema. The tool description adds no additional parameter semantics—it doesn't explain how parameters interact or provide extra context beyond the schema. The baseline of 3 is appropriate.
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's function with a specific verb-resource pair: "Simulate a cyberattack" and adds meaningful qualifiers ("realistic attack vectors and TTPs"). However, it does not explicitly differentiate this tool from siblings like create_scenario, so it falls short of the top 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 is provided about when to use this tool vs. alternatives. The description doesn't mention use cases, prerequisites, or conditions that would favor simulate_attack over create_scenario or analyze_network.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manually stop one or more active simulations for safety or compliance
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | Reason for terminating the simulation (for audit logging). | |
| operator | No | Operator context (id, role, approvals) | |
| simulation_id | No | Identifier returned by simulate_attack. If omitted, all active simulations are stopped. | |
| approval_token | No | Approval token required by governance policy (if configured). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for disclosing behavioral traits. It only states the action (stop) without explaining consequences such as irreversibility, state changes, permission requirements, or audit implications. The schema hints at governance (approval_token, reason) but the description does not surface these.
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, front-loaded sentence with no filler. Every word contributes to conveying the core purpose and context, making it highly concise.
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?
The description is too sparse for a tool with four parameters, a nested object, no annotations, and no output schema. It fails to explain key context such as the default behavior when simulation_id is omitted, governance requirements, or what happens to the simulation's state after stopping.
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 100% and includes detailed descriptions for all four parameters. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
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's function: 'Manually stop one or more active simulations.' It uses a specific verb (stop) and resource (simulations), and differentiates itself from siblings like simulate_attack by indicating the inverse action.
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 phrase 'for safety or compliance' provides contextual guidance on when to use the tool. It does not explicitly mention alternatives or exclusions, but the context is clear enough that an agent can infer this is the appropriate tool for halting simulations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate payloads for updating enterprise risk registers (ServiceNow, Archer, OneTrust)
| Name | Required | Description | Default |
|---|---|---|---|
| owner | No | ||
| system | Yes | Target risk/governance system | |
| due_date | No | Optional due date for remediation | |
| priority | No | ||
| incident_id | Yes | Incident identifier to synchronise |
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 only says 'generate payloads', which hints at a non-destructive preparation step, but it does not clarify whether the tool actually updates external systems, requires authentication, or has side effects. This is a significant gap for a sync/update 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, focused sentence with no redundant information. It efficiently communicates the core purpose and target systems, making it appropriately concise.
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 annotations, no output schema, and a moderate schema, the description must provide more context than it does. It fails to explain the payload structure, return values, side effects, or prerequisites, which is insufficient for an agent to correctly invoke a multi-system synchronization tool.
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 schema documents 60% of parameters (system and incident_id), but the description adds no parameter-level meaning beyond that. The remaining parameters (owner, due_date, priority) are only typed as strings with no description in either the schema or the tool description, leaving their purpose and format ambiguous.
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 identifies a specific action (generating payloads) and a clear resource (enterprise risk registers) with named target systems (ServiceNow, Archer, OneTrust), distinguishing it from sibling security tools. However, the verb 'generate payloads' is indirect compared to the tool name 'sync', leaving slight ambiguity about whether it directly updates or prepares 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 explicit when-to-use guidance is provided, but the purpose is reasonably clear from context: it is for updating risk registers after incidents. There are no exclusions or alternatives mentioned, so the usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes (e.g., analyze_network vs forensics_analysis vs investigate_incident), but generate_report and generate_validation_report could be confused at a glance, as could forensics_analysis and investigate_incident. Descriptions clarify boundaries, but a couple tools overlap in scope.
The vast majority follow a verb_noun snake_case pattern (analyze_network, create_scenario, simulate_attack), but forensics_analysis deviates by placing the noun first and using 'analysis' instead of a verb. This is a minor inconsistency in an otherwise predictable convention.
With 12 tools, the server is well-scoped for a cybersecurity simulation platform. Each tool serves a distinct function in the workflow, and the count is within the ideal 3-15 range, making the surface manageable without being sparse.
The tool set covers the core lifecycle: scenario creation, attack simulation, incident investigation, forensics, reporting, and integration with risk registers. Minor gaps exist, such as lacking a tool to list or update scenarios, but the available tools are sufficient for typical training and analysis workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Enrich, search, assess, and manage threat intelligence through 80+ typed MCP tools.
TLPTOracle — 17-tool TIBER-EU TLPT framework: scope, threat intel, scenarios, reports.
List, schedule, and retrieve evidence for ControlDrill incident-response tabletop exercises.
AI-powered threat intelligence, smart contract auditing, and cybersecurity OSINT.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kayembahamid/cybersim-pro'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
