Cybersec Toolkit

Overview Schema Source Related Servers Discussions Admin

guided_assessment

Plan, guide, or solve a security task on any target. Auto-detects the workflow and tools, then returns classification, triage, next actions, and install status before executing approved steps.

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.6/5.0

Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so well. It discloses the governed execute_tool() path, safety checks, default no-autorun behavior, autonomous auto-execution, and the possibility of creating, saving, and running helper scripts persisted under manual_scripts/. This is outstanding transparency for a mutable, potentially side-effect-heavy tool.

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 longer than average but dense and informative; it earns its length given the tool's complexity. It front-loads the core purpose and then layers mode behavior, safety, and side effects. Minor redundancy around 'MCP toolchain' and 'agent' prevents a 5.

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 complex orchestrator with 8 parameters and no annotations, the description is remarkably complete. It covers default and heavy modes, the step-by-step companion workflow, execution policy safeguards, script persistence, and the boundary between run_tool and helper scripts. Since an output schema exists, return-value detail is not required here.

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

Parameters4/5

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 adds meaningful context beyond the schema by explaining that workflow/target_type default to 'auto' and are auto-detected, that mode controls whether the initial call runs commands, and that max_steps bounds autonomous execution. This enriches several parameters without needing to restate all of them.

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 clearly identifies an orchestrator that plans, guides, or autonomously solves security tasks over the MCP toolchain. It distinguishes itself from executable siblings by positioning itself as the planning/triage layer on top of run_tool, run_pipeline, run_script, and the registry/advisors.

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?

The description gives strong usage context: default companion mode returns a plan without executing, while autonomous mode bootstraps and continues into the toolchain. It also notes that simple recon/HTTP commands like curl remain run_tool calls. It stops short of explicitly naming conditions for every sibling alternative, but the guidance is clear enough.

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

Deploy Server