intruder-mcp

Official

Overview Schema Source Related Servers Discussions Admin

create_scan_schedule

Create recurring scan schedules to automate security assessments. Set frequency, target groups, and first scan time to run scans on schedule.

Instructions

    Create a recurring scan schedule.

    Args:
        name: Name of the schedule
        first_scan_time: ISO 8601 timestamp of the first scan. Must be in the future and on the hour
            (e.g. '2026-05-01T03:00:00Z', not '2026-05-01T03:12:34Z')
        scan_frequency: One of 'daily', 'weekly', 'monthly', 'quarterly'
        target_ids: List of target IDs to include in the schedule
        tag_names: List of target tag names to include in the schedule
        throttled: Whether to throttle the scan
        web_ports_only: Only scan standard web ports
        upload_to_drata: Upload scan results to Drata
        upload_to_vanta: Upload scan results to Vanta

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes
`tag_names`	No
`throttled`	No
`target_ids`	No
`scan_frequency`	Yes
`web_ports_only`	No
`first_scan_time`	Yes
`upload_to_drata`	No
`upload_to_vanta`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.2May 3, 2026

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavior. It describes one constraint (first_scan_time must be on the hour and in the future) but omits other critical traits: whether it creates a new resource each call, side effects, permissions needed, or error scenarios (e.g., duplicate schedule).

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 efficient with a clear opening sentence followed by parameter explanations in a list format. It uses minimal words per parameter, avoiding verbosity. The pseudo-docstring style is acceptable for an LLM.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers all parameters briefly, but given 9 parameters (6 optional) and no explanation of expected behavior for combined target_ids/tag_names, validation details, or error conditions, it leaves gaps. An output schema may compensate, but the description alone feels incomplete for a creation tool.

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?

Despite 0% schema coverage, the description adds meaning for all 9 parameters, such as 'ISO 8601 timestamp of the first scan' and listing valid frequencies. However, it doesn't clarify how target_ids and tag_names interact (e.g., OR logic) nor define terms like 'throttled'. It is helpful but not fully comprehensive.

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 opens with 'Create a recurring scan schedule,' clearly stating the verb and resource. 'Recurring' distinguishes it from create_scan (presumably one-time) and update_scan_schedule. The tool's purpose is unmistakable.

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?

No guidance is given on when to use this tool versus alternatives like create_scan for one-time scans. There is no explicit 'when to use/when not to use' instruction, leaving the agent to infer from the word 'recurring' alone.

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