[scrut-nick]

Problem

The MCP finding tools forwarded repository, severity and status to the API as raw query parameters. No endpoint accepts a repository name, and severity/status are only honoured by some endpoints. The API ignores parameters it does not recognise rather than rejecting them, so each of those filters came back as a full, unfiltered page that reads as a filtered one.

Concretely, get_findings_for_repo("scrut-helpdesk-bot") returned findings from scrut-organizationService, scrut-trust-center, scrut-datasync-gcp and others — a global page presented under a per-repository tool name. There is no error and nothing in the response distinguishes it from a real result.

Filter support as it actually stands, read off the query parameters each generated client method in internal/api forwards:

filter	endpoints honouring it
repository	0 of 7
severity	4 of 7 (not sca_dependencies, not secrets)
status	2 of 7

Fix

Filters are translated rather than forwarded, in a new internal/mcp/filters.go used by makeGetHandler, nullify_search_findings and get_findings_for_repo.

• repository resolves to the numeric repository id the endpoints filter on — githubRepositoryId, or the Azure/Bitbucket equivalent selected from the configured VCS owner. GitLab has no repository-id parameter, so it returns a clear error instead.
• The id comes from /sca/repositories and /sast/repositories, which are keyed by that numeric id. /context/repositories is deliberately not used: its id is a Nullify ULID, and passing one is rejected with invalid integer value '01HK…' type 'int64'. Non-numeric keys are skipped for the same reason.
• Filters an endpoint cannot apply are never sent. Single-endpoint tools fail with a message naming the filter and endpoint; the fan-out tools report them per finding type as unapplied_filters, so a caller can tell which results are narrowed and which are not.

Resolved names are cached per API host. Those listings cap limit at 10, so a cache miss costs one request per ten repositories; every name seen on the way is cached, so the cost is paid at most once per process for any repository appearing before the target.

Verification

go build ./..., go test ./... and golangci-lint run ./... (0 issues) all pass.

Unit tests cover provider selection, paging until a match, the cache suppressing repeat requests, fall-through from the SCA listing to the SAST one, ULID keys being skipped, per-endpoint severity/status support, and a guard that every finding type has a support entry.

Checked against a live instance:

• scrut-trust-center → githubRepositoryId=480701645; the filtered request returns 25/25 findings from that repository alone.
• scrut-datasync-kolide → 1003604517. This one is ULID-keyed in /context/repositories, so the obvious implementation would have returned HTTP 400 here.
• severity on /sca/dependencies/findings is reported as unapplied rather than silently dropped.

Notes

The same defect exists upstream in Nullify-Platform/cli — tools_composite.go and tools_unified.go are unmodified from there, so this is worth sending upstream too.

Unrelated and not addressed here: scripts/generate/main.go:generateCobraUse() names commands from HTTP method plus the last non-parameter path segment, so /sca/containers/findings and /sca/dependencies/findings both become list-findings under the same sca parent and one shadows the other. That makes /sca/dependencies/findings unreachable from the CLI. Fixing it means regenerating from the OpenAPI spec, which is not in this repo.

🤖 Generated with Claude Code

https://claude.ai/code/session_01R27reGQuYtybuiX9RScNUG

---

Generated by Claude Code