What MCP Bastion Found When I Changed One Tool Description

I changed one sentence in the description of an MCP tool called get_uptime. Scanned on its own, the edited definition produced zero findings. Scanned against the copy I had approved, the same file produced a HIGH finding and an exit code of 1. The edit was ordinary English. The tool used to promise uptime in seconds. Now it promised uptime and the deployment region. A reviewer could reasonably approve either version. The question was whether anyone had approved the second one. That’s the problem I wanted to demonstrate with MCP Bastion, an open-source scanner for Model Context Protocol servers and AI-agent tools. I ran two small experiments against version 0.4.0 using saved tool definitions. You can repeat the first in a few minutes without a model, an API key, or a running MCP server. Project on GitHub What a code review can miss An MCP client uses tools/list to discover what a server offers. The response includes each tool’s name, description and input schema. The client can make that information available to the model as it selects tools and prepares arguments. Execution happens through a separate tools/call request. MCP tools specification Suppose a pull request pins the package version that launches a local server. That gives me something concrete to review about the executable. A remote server can also change what it advertises while the URL in my client configuration stays exactly the same. And even when the tool name is familiar, a new description on an optional parameter can change what an agent is asked to supply. What I inspect What I want to know Client configuration What command or endpoint will the client use? Which filesystem paths, credentials or container privileges does that configuration expose? Tool metadata What instructions will the model see, including text nested inside the input schema? Which definitions changed since review? Repository instructions What else can steer the coding agent when it opens this checkout? That includes AGENTS.md, Cursor rules, Claude skills and configured hooks. I can scan a checkout statically before opening it in an agent. For metadata, I can supply a saved catalog with --tools-file. For live inspection, --live can launch the configured local server command. I use that mode only after reviewing the command or moving the scan into an isolated environment. Scan implementation The project's example dashboard groups findings by server and file. The experiments below use smaller catalogs so each finding has a single explanation. Experiment 1. Change one sentence and keep the tool name To reproduce this on macOS or Linux, start in an empty directory with a Python 3.10+ virtual environment active. I pinned the scanner revision so the rule behavior is reproducible. python -m pip install "mcp-bastion @ git+https://github.com/lindseynguyen/mcp-bastion.git@4163ba54944a6e8a9e69a8623461d3424f54ee06" Create an empty client configuration to keep local MCP settings out of the experiment. The following commands save one definition under the server name ops and create the initial lock file. printf '%s\n' '{"mcpServers": {}}' > mcp.json cat > tools.json