Preflight inspection for MCP servers

[jordanstarrk]

Pre-submission Checklist

• This post follows the MCP community guidelines

What would you like to share?

Preflight-style inspection for MCP servers

While experimenting with MCP servers, I kept wanting a quick way to answer a basic question before connecting a client:

What does this server actually expose?

I put together a small open source CLI that:

• runs an MCP server briefly in inspection mode
• lists exposed tools, resources, and prompts
• heuristically flags read, write, and destructive tools
• can diff snapshots to see what changed between versions

It never calls call_tool. It just introspects and exits.

It's a bit like running ls -la on an MCP server before executing something: not a security guarantee, just basic visibility into what's there.

This isn’t a security solution or enforcement mechanism, just a lightweight pre-trust step.

Repo: https://github.com/jordanstarrk/mcp-preflight

Relevant Links

https://github.com/jordanstarrk/mcp-preflight

[renatomarinho]

Great tool! As the founder of GitScrum, I've been developing an MCP server for project management that could benefit from preflight inspection capabilities like this.

We built GitScrum MCP Server (open source) to integrate project management with Claude through MCP. Having a way to inspect and validate the server configuration before connecting would be extremely useful.

GitHub: https://github.com/gitscrum-core/mcp-server

Would love to hear your thoughts on how this inspection tool could be applied to project management MCP servers. What validation checks would be most valuable?

[jordanstarrk]

Hi Renato, thanks! I ran mcp-preflight against your server:

$ mcp-preflight "npx -y @gitscrum-studio/mcp-server" mcp-preflight: 🔒 authentication required

Your server was the first auth-gated MCP I tested, which led me to ship v0.2.0 with proper auth detection, so thanks for that!

What I’ve found most valuable with MCP servers is clarity of expectations. The client is an LLM choosing actions, so the effective blast radius depends on the server’s exposed capabilities (and the model in use), not just user intent.

From what I understand of GitScrum, that shows up in a few places:

• Financial actions like invoice.mark_paid or proposal.send, which have real external consequences
• Consolidated action patterns where list_tools shows ~29 tools, but the true surface area is much larger
• Ongoing evolution of capabilities, where mcp-preflight diff can make new actions explicit before teams upgrade

I’d be interested to learn more about what requirements you’re seeing from users or teams, happy to explore enhancements if there’s a real need.

[renatomarinho]

Hey @jordanstarrk, thanks for testing the server and for the feedback — and especially for shipping auth detection in mcp-preflight v0.2.0 because of it!

You're right about the scope. Those ~29 tools actually cover 160+ operations from GitScrum's API. We initially tried exposing all endpoints as individual tools but that was a disaster — context exploded, tool selection became unreliable, just wasn't usable.

So we switched to consolidated domain tools (tasks, sprints, projects, invoices, etc.) with an action parameter. Reduced the tool count massively while keeping the full capability surface. Way more reliable for the LLM to work with.

Totally agree on the financial actions like invoice.mark_paid and proposal.send. We need better visibility and guardrails around those —
especially for production use. Capability diffing via mcp-preflight would actually be super helpful for tracking changes between versions.

We're actively evolving the server and would love your input on what would make MCP servers safer and more production-ready for teams and enterprise.

Thanks again for the work on mcp-preflight and for opening this up.