Skip to main content
Glama
CorbettCajun

SpiderFoot MCP Server

by CorbettCajun

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
MCP_HTTP_PORTNoPort for HTTP transport (if using index-http.ts)3000
SPIDERFOOT_PASSNoOptional HTTP Digest password if you enable auth in SpiderFoot
SPIDERFOOT_USERNoOptional HTTP Digest username if you enable auth in SpiderFoot
ALLOW_START_SCANNoEnables/disables spiderfoot_start_scan tooltrue
SPIDERFOOT_BASE_URLNoBase URL of your SpiderFoot web UI/APIhttp://127.0.0.1:5001

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Server capabilities have not been inspected yet.

Tools

Functions exposed to the LLM to take actions

NameDescription
spiderfoot_pingA

Ping SpiderFoot server to verify it is responding.

spiderfoot_modulesA

List available SpiderFoot modules.

spiderfoot_event_typesB

List available SpiderFoot event types.

spiderfoot_scansB

List all scans (past and present).

spiderfoot_scan_infoC

Retrieve scan metadata/config for a scan ID.

spiderfoot_start_scanC

Start a new scan against a target.

spiderfoot_scan_dataC

Fetch scan event results for a scan ID.

spiderfoot_scan_data_uniqueC

Fetch unique scan event results.

spiderfoot_scan_logsC

Fetch/poll scan logs for a given scan ID.

spiderfoot_export_jsonC

Export scan results in JSON for CSV of IDs.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.5/5.0

Scored across 10 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: listing event types, exporting results, listing modules, pinging the server, fetching scan data (regular and unique), retrieving scan metadata, fetching logs, listing scans, and starting a scan. The descriptions make it easy to differentiate between them, such as distinguishing scan_data from scan_data_unique or scan_info from scan_logs.

Naming Consistency5/5

All tool names follow a consistent snake_case pattern with a 'spiderfoot_' prefix and descriptive suffixes (e.g., event_types, export_json, start_scan). This uniformity makes the tools predictable and easy to understand, with no deviations in style or structure across the set.

Tool Count5/5

With 10 tools, the server is well-scoped for managing SpiderFoot scans, covering key operations like listing, starting, fetching data, and exporting results. Each tool serves a specific function without redundancy, making the count appropriate for the domain of security scanning and reconnaissance.

Completeness5/5

The tool set provides complete coverage for scan management: listing scans, starting scans, retrieving metadata, data, logs, and exporting results, along with auxiliary functions like pinging and listing modules/event types. There are no obvious gaps, as it supports the full lifecycle from initiation to analysis and export.

Maintenance

ActivityInactive
ResponsivenessNo issues