--- since: 1.1.3 --- # gitaiflow MCP — MCP Inspector Verification MCP Inspector is the protocol-level verification layer. It should be used **after** the native or Docker server has already passed its runtime checks. --- ## 1. What Inspector proves ```mermaid flowchart LR Inspector["MCP Inspector"] Init["initialize"] Session["MCP session"] Tools["tools/list"] Schema["tool schemas"] Call["tools/call"] Result["MCP result"] Inspector --> Init --> Session --> Tools --> Schema --> Call --> Result ``` Inspector verifies the MCP contract. It does not replace direct gitaiflow testing. --- ## 2. Choose the server ### Native Start: ```bash python -m mcp_server.server ``` Connect: ```text http://localhost:8080/mcp ``` ### Docker Start the Docker server using: ```text MCP-DOCKER-VERIFICATION.md ``` Connect: ```text http://localhost:8080/mcp ``` The endpoint is the same; the runtime boundary is different. --- ## 3. Start Inspector ```bash npx -y @modelcontextprotocol/inspector@latest ``` Connect to: ```text http://localhost:8080/mcp ``` Provide: ```text Authorization: Bearer ``` --- ## 4. Connection verification Verify: ```text server name: gitaiflow server version: 1.1.3 transport: STREAMABLE-HTTP session: established protocol: negotiated ``` --- ## 5. Tool discovery Run `tools/list`. All six tools must be present: ```text gitaiflow_change_summary gitaiflow_last_summary gitaiflow_changelog gitaiflow_release_notes gitaiflow_usage gitaiflow_list_models ``` --- ## 6. Schema verification Verify required arguments: ```text gitaiflow_change_summary.remote gitaiflow_changelog.remote ``` Verify optional arguments: ```text gitaiflow_change_summary.base_branch gitaiflow_change_summary.path gitaiflow_changelog.since gitaiflow_changelog.until gitaiflow_usage.scope gitaiflow_usage.since gitaiflow_usage.until gitaiflow_list_models.free_only gitaiflow_list_models.as_json ``` --- ## 7. Tool-call order A useful first sequence is: ```text gitaiflow_list_models ↓ gitaiflow_usage ↓ gitaiflow_last_summary ``` Then test the tools requiring repository context: ```text gitaiflow_change_summary gitaiflow_changelog gitaiflow_release_notes ``` Use the actual repository remote. Do not assume `origin`, `gitlab`, or another remote name. --- ## 8. Workspace rule for Docker For the recommended multi-repository Docker layout, `/workspace` is the allowed **parent workspace**, not necessarily a Git repository itself. For example: ```text /workspace/ ├── gitaiflow/.git ├── djangoplay-cli/.git └── issuetracker/.git ``` If the tool accepts a repository path, select the repository by name: ```text path="gitaiflow" ``` which resolves to: ```text /workspace/gitaiflow ``` Git must report that directory as its repository root. You can verify it with: ```bash docker exec gitaiflow-mcp sh -c \ 'git -C /workspace/gitaiflow rev-parse --show-toplevel' ``` Expected: ```text /workspace/gitaiflow ``` Do not change the Docker mount to an individual repository merely to make this call work. The parent workspace is what allows Inspector and Claude to select sibling repositories as well. --- ## 9. Rate limiting The application default is: ```text MCP_RATE_LIMIT=5 MCP_RATE_WINDOW_SECONDS=60 ``` Repeated manual Inspector requests can consume this window quickly. For local development use: ```text MCP_RATE_LIMIT=100 MCP_RATE_WINDOW_SECONDS=60 ``` After changing `.mcp.env`, restart the MCP server/container. A restart invalidates old MCP sessions, so reconnect Inspector. --- ## 10. Successful Inspector gate Inspector is complete when: ```text [ ] connection established [ ] authentication accepted [ ] initialize succeeds [ ] session established [ ] tools/list succeeds [ ] all six tools visible [ ] schemas are correct [ ] required arguments are enforced [ ] optional arguments are available [ ] valid tool calls succeed [ ] MCP results are returned ``` At this point the MCP protocol boundary is proven. Next: ```text MCP-CLAUDE-DESKTOP.md ```