Cybersec Toolkit

Overview Schema Source Related Servers Discussions Admin

guided_assessment

Destructive

Plan and guide security assessments by auto-detecting workflows, tools, and triage steps; optionally execute governed MCP commands step by step.

Instructions

Plan, guide, or autonomously solve a security task over the MCP toolchain.

An orchestrator on top of the registry, advisors, install checks, audit logging, and execution policy. Bootstrap commands use the governed execute_tool() path, so target scope, external-network, shell-injection, and blocked-flag checks apply.

By DEFAULT it auto-detects the right workflow + tools for the problem (workflow/ target_type="auto") and acts as a companion: it returns classification, triage gates, recommended skills, reporting next steps, a plan, tool install status, next actions, and the full MCP toolchain surface WITHOUT auto-running commands in this initial call. The agent can then run tools step by step as the user approves. The heaviest mode (autonomous) starts the auto-solver contract: it bootstraps triage, then the client agent continues with the full MCP toolchain (registry/advisors/install checks/run_tool/run_pipeline and separately gated run_script). When registry tools and pipelines are not enough, autonomous mode may create, save, and run scoped helper scripts for the user, persisting reusable ones under manual_scripts/. Simple recon/HTTP commands such as curl remain run_tool calls.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`mode`	No	"companion" (default) or "autonomous" (opt-in).	companion
`target`	Yes	URL, hostname/IP, or local file path to assess.
`finding`	No	Optional short finding summary to classify for triage/report routing. Raw finding text is used locally but not echoed in the result.
`workflow`	No	"auto" (default — inferred), "bounty", "ctf", or "generic".	auto
`intensity`	No	"low" (default) or "medium". Medium may include low-volume nmap.	low
`max_steps`	No	Maximum number of bootstrap steps autonomous mode auto-executes.
`target_type`	No	"auto" (default — inferred from the target) or an explicit type: bounty type (web_app/api/cloud/network/iot/mobile_app) or CTF category.	auto
`authorization_confirmed`	No	Required before any network step executes.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.2.0Sep 9, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond annotations (destructiveHint=true, openWorldHint=true), the description discloses governed execution checks ('target scope, external-network, shell-injection, and blocked-flag checks'), confirms no auto-run in the default call, and explains that autonomous mode may create, save, and run scoped helper scripts, persisting reusable ones under manual_scripts/. It also states that authorization_confirmed is required before any network step executes.

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 front-loaded with the core purpose and is dense with useful operational detail. It is a bit paragraph-heavy and could be more scannable, but given the complexity of the orchestration behavior, most sentences earn their place.

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?

An output schema exists, so return values need not be fully explained, yet the description still summarizes what companion mode returns and what autonomous mode bootstraps. Combined with the annotations and 100% schema coverage, the definition gives an agent enough context to choose and invoke the tool correctly.

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%, so the parameter semantics already live in the input schema. The description largely repeats default values and enum-like options (mode companion/autonomous, workflow auto, target_type auto) without adding substantial syntax or format guidance beyond what the schema already provides.

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 states a specific compound verb+resource: 'Plan, guide, or autonomously solve a security task over the MCP toolchain.' It immediately positions the tool as an 'orchestrator on top of the registry, advisors, install checks, audit logging, and execution policy,' which cleanly distinguishes it from sibling tools like run_tool, run_pipeline, and suggest_for_*.

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

Usage Guidelines4/5

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

It clearly explains the default companion mode versus opt-in autonomous mode, and explicitly routes simple recon/HTTP commands to run_tool instead. It does not, however, give a full when-not-to-use rule or spell out the exact conditions under which autonomous mode should be preferred over companion mode, leaving some inference to the agent.

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

Deploy Server