Your MCP Config Can Be Risky Before Any Tool Runs

An MCP server does not need to execute a tool to create an operational problem. A local config can already expose a listener, carry a plaintext token, grant *-shaped tool scope, or pull an unpinned package.

ai-agentic-mcpscan turns that pre-runtime surface into a report. Its mcpscan CLI discovers local MCP servers, audits several agent-host config formats, scores exposure, credential hygiene, tool-scope breadth, and version pinning, and can emit JSON, HTML, or SARIF 2.1.0.

The useful first command is deliberately boring:

mcpscan inventory
mcpscan scan --root ~/project --json report.json --sarif results.sarif

Inventory tells you what the host appears to contain. Scan tells you which config facts deserve attention. Start in a disposable checkout and read the report before changing the host. The default static path is offline and read-only; --online is an explicit OSV/PyPI enrichment decision, not a harmless flag.

The mutation boundary is also explicit. mcpscan --fix is limited to selected over-broad tool-scope grants and backs up each file. It does not invent a secret manager or choose a safe package version for you. That is the right asymmetry: scope can be narrowed mechanically, while credential rotation and pin selection require context.

My acceptance rule is three artifacts, not one green command: the exact commit and Python version, the redacted report, and a before/after comparison showing the backup and the scope change. A clean static report still says nothing about runtime behavior, prompt injection, or whether the upstream project fits production.

This is an independent Doramagic reading of IRsoctierDT/ai-agentic-mcpscan, not a security certification. Source and manual: https://doramagic.ai/en/projects/ai-agentic-mcpscan/manual/

Tags: ai, security, mcp, devtools, python, opensource, codequality, devops