--syntactic.
What static analysis catches
Every static scan checks for:- duplicate tool names
- naming convention drift
- parameter conflicts
- shadow patterns in tool descriptions
- excessive tool counts
Use it in local development
The fastest local workflow is to point Watchtower at the command that starts your MCP server.Use it with a remote MCP endpoint
If your server is already deployed behind HTTP, scan it with--remote. Add --auth-token only when the endpoint requires bearer authentication.
Use it from a manifest in your workspace
If your build already exports a tools JSON file, scan that directly with--manifest.
- raw tool array
{ "tools": [...] }{ "result": { "tools": [...] } }
- your CI environment cannot start a live server
- you want a stable snapshot of the toolset
- you want to reuse one exported manifest across multiple validation steps
Use it in CI
Watchtower exits with code1 on critical static findings, so you can use it as a blocking quality gate without extra wrappers.
.github/workflows/mcp-lint.yml
--json when you want machine-readable output for artifacts or downstream tooling.
Use it for multi-server platforms
If you are validating a registry, orchestrator, or any environment where multiple MCP servers share one tool namespace, add--platform.
--platform elevates duplicate tool names to critical, which is what you usually want when a collision can break routing across servers.
Use --platform when:
- multiple servers are loaded into the same agent context
- you maintain an MCP registry
- your desktop config or orchestrator combines more than one MCP server
Useful static-analysis flags
Exit code behavior
Warnings and info findings do not change the exit code.
Related pages
CLI reference
See all static-analysis flags, input modes, and JSON output fields in one place.
Checks reference
Understand each static check and the finding codes it produces.
Semantic analysis
Add corpus-based overlap detection when you want to compare your tools against existing MCP tools.