Skip to main content
Glama
Sign In
dytredline

VulKill Security

by dytredline
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Check VulKill Scan Credits & Watchdog Policy

vulkill_check_credits
Read-onlyIdempotent

Check remaining file-scan and live-site credits, active billing period, shard capacity, and authorization scopes before planning a scan; optionally estimate quota shortfall for planned files or sites.

Instructions

Query the authenticated workspace's remaining file-scan and live-site credits, active UTC billing period, shard capacity, and legal authorization scopes. Call this tool first before planning or starting a scan. Use vulkill_scan_guided_interactive to compute a shard execution plan, or vulkill_list_reports to inspect past findings. Leaving plannedFiles and plannedSites at 0 inspects current balances only. Positive values convert each file to 1 file credit across ceil(plannedFiles / 5000) shards and each site to 1 site credit against the active credit_periods row, reporting any quota shortfall without throwing an error. Requires VULKILL_API_KEY or OAuth 2.1 Bearer auth and charges zero credits. Enforces a 60 requests/minute rate limit per workspace.

Input Schema

NameRequiredDescriptionDefault
plannedFilesNoOptional prospective repository file count (0 to 100,000,000, default 0).
plannedSitesNoOptional prospective live web/API origin count (0 to 10,000, default 0).

Output Schema

NameRequiredDescriptionDefault
periodYesActive UTC billing period in YYYY-MM format (for example, 2026-11).
shardSizeYesMaximum number of files processed per isolated container shard (fixed at 5000).
remainingFilesYesRemaining file-scan capacity available in the active UTC monthly billing period.
remainingSitesYesRemaining live-site DAST scan credits available in the active UTC monthly billing period.
executionAvailableYesTrue when the workspace has valid credentials and a reachable remote scanner engine.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.10
    • changedInput schema / properties / plannedFiles / description
      Previous value: -"Prospective repository file count (0 to 100,000,000, default 0)."New value: +"Optional prospective repository file count (0 to 100,000,000, default 0)."
    • changedInput schema / properties / plannedSites / description
      Previous value: -"Prospective live web/API origin count (0 to 10,000, default 0)."New value: +"Optional prospective live web/API origin count (0 to 10,000, default 0)."
  2. Changed2 schema fields changedv0.1.9
    • changedInput schema / properties / plannedFiles / description
      Previous value: -"Optional prospective repository file count (0 to 100,000,000, default 0)."New value: +"Prospective repository file count (0 to 100,000,000, default 0)."
    • changedInput schema / properties / plannedSites / description
      Previous value: -"Optional prospective live web/API origin count (0 to 10,000, default 0)."New value: +"Prospective live web/API origin count (0 to 10,000, default 0)."
  3. Changed5 schema fields changedv0.1.5
    • addedInput schema / properties / plannedFiles
      Added value: +{
+  "default": 0,
+  "description": "Optional prospective repository file count (0 to 100,000,000, default 0).",
+  "maximum": 100000000,
+  "minimum": 0,
+  "type": "integer"
+}
    • addedInput schema / properties / plannedSites
      Added value: +{
+  "default": 0,
+  "description": "Optional prospective live web/API origin count (0 to 10,000, default 0).",
+  "maximum": 10000,
+  "minimum": 0,
+  "type": "integer"
+}
    • changedOutput schema / properties / executionAvailable / description
      Previous value: -"True when the workspace has an active API key or OAuth session and reachable scanner engine."New value: +"True when the workspace has valid credentials and a reachable remote scanner engine."
    • changedOutput schema / properties / remainingFiles / description
      Previous value: -"Remaining file-scan credits available in the current UTC monthly billing period."New value: +"Remaining file-scan capacity available in the active UTC monthly billing period."
    • changedOutput schema / properties / remainingSites / description
      Previous value: -"Remaining live-site DAST scan credits available in the current UTC monthly billing period."New value: +"Remaining live-site DAST scan credits available in the active UTC monthly billing period."
  4. Changed1 schema field changedv0.1.1
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "executionAvailable": {
+      "description": "True when the workspace has an active API key or OAuth session and reachable scanner engine.",
+      "type": "boolean"
+    },
+    "period": {
+      "description": "Active UTC billing period in YYYY-MM format (for example, 2026-11).",
+      "type": "string"
+    },
+    "remainingFiles": {
+      "description": "Remaining file-scan credits available in the current UTC monthly billing period.",
+      "type": "integer"
+    },
+    "remainingSites": {
+      "description": "Remaining live-site DAST scan credits available in the current UTC monthly billing period.",
+      "type": "integer"
+    },
+    "shardSize": {
+      "description": "Maximum number of files processed per isolated container shard (fixed at 5000).",
+      "type": "integer"
+    }
+  },
+  "required": [
+    "remainingFiles",
+    "remainingSites",
+    "period",
+    "shardSize",
+    "executionAvailable"
+  ],
+  "type": "object"
+}
  5. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: auth requirements (VULKILL_API_KEY or OAuth 2.1 Bearer), zero credit charge, a 60 req/min per-workspace rate limit, and quota-shortfall reporting without throwing an error. The shard/credit conversion model is disclosed explicitly.

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?

Front-loaded with purpose, then usage, then behavior, with no filler sentences. It is dense and slightly long, but each sentence carries distinct operational information (sequencing, conversion math, auth, rate limit), so the only knock is density rather than waste.

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?

With an output schema present, the description needn't explain return values, and it still covers preconditions, side effects, cost, rate limits, and parameter effects. Nothing an agent needs to invoke this correctly is missing.

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

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, yet the description still adds meaning the schema lacks: leaving both values at 0 means inspect-only, positive plannedFiles converts to 1 credit per file across ceil(plannedFiles/5000) shards, and plannedSites maps 1:1 against the active credit_periods row. This explains the semantic effect of each parameter, not just its type.

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?

States specific verb+resource: query remaining file-scan and live-site credits, active UTC billing period, shard capacity, and legal authorization scopes. It also names sibling tools (vulkill_scan_guided_interactive, vulkill_list_reports) so an agent can separate this pre-flight credit check from plan computation or report inspection.

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?

Explicit sequencing guidance: 'Call this tool first before planning or starting a scan,' plus named alternatives and the condition that selects each (compute a shard plan → vulkill_scan_guided_interactive; past findings → vulkill_list_reports). When-to-use and which-sibling-to-pick are both stated.

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

Deploy Server

Other Tools