Every static check the scanner runs.

Google ADK toolset cannot be statically enumerated.

Why: Release review needs an explicit tool inventory; ADK MCP/OpenAPI toolsets may resolve tools dynamically at runtime.

Google ADK eval coverage is not declared.

Why: ADK releases should include response and tool-trajectory eval evidence before promotion.

Google ADK function tool lacks static metadata.

Why: Static review depends on descriptions and parameter schemas because user ADK code is not imported.

High-risk Google ADK tools lack static guardrail evidence.

Why: Callbacks and plugins are the static ADK surface where release reviewers can see guardrail intent.

Google ADK long-running tool lacks an operation contract.

Why: Long-running tools need explicit status and operation-id semantics for safe continuation.

Google ADK McpToolset lacks a static tool filter.

Why: Unfiltered MCP toolsets can expose more tools than reviewers expect.

OpenAI API function schema is not strict enough for reliable tool calls.

Why: Strict schemas reduce ambiguous tool arguments and downstream side-effect risk.

Prompt scope contradicts enabled OpenAI API tools.

Why: Prompt instructions should match the actual write/high-risk tool surface.

OpenAI API high-risk flow lacks retry policy metadata.

Why: Retries need explicit policy metadata so reviewers can reason about duplicate side effects.

OpenAI API write tool may be retried without idempotency evidence.

Why: Retries against non-idempotent writes can duplicate financial, destructive, or external side effects.

OpenAI API structured output schema is missing or under-specified.

Why: Downstream release decisions need explicit, structured success/refusal/review modeling.

OpenAI API high-risk flow lacks test case metadata.

Why: High-risk tool-call flows should have release evidence before promotion.

OpenAI API high-risk flow lacks timeout metadata.

Why: Timeouts define failure behavior and reduce ambiguous tool-call continuation.

OpenAI API high-risk tool lacks success/failure output modeling.

Why: Tool output schemas help release reviewers reason about downstream failure handling.

OpenAI API trace sample shows a policy-controlled tool without approval.

Why: Trace samples should demonstrate approval behavior for tools that require approval.

OpenAI API trace sample shows a policy-controlled tool without confirmation.

Why: Trace samples should demonstrate explicit confirmation for tools that require confirmation.

Manifest declares broad permission scopes.

Why: Broad manifest scopes weaken least-privilege review.

Scope-requiring tool lacks declared auth scopes.

Why: Reviewers cannot assess least privilege without scope metadata.

Tool-required scopes are not covered by manifest permissions.scopes.

Why: The manifest should describe the actual permissions needed by the release.

Tool declares broad auth scopes.

Why: Tool-level broad scopes may grant more power than the operation needs.

Tool description is missing or too short.

Why: Poor tool descriptions increase wrong-tool and reviewer misunderstanding risk.

Production target includes low-confidence tool extraction.

Why: Production promotion should not depend primarily on best-effort SDK inference.

Tool surface cannot be enumerated from declared inputs.

Why: A release gate must fail closed when it cannot see the agent's tools.

Tool surface exceeds the MVP review threshold.

Why: Large tool surfaces are harder to reason about during promotion.

Wildcard or all-tools exposure is declared.

Why: Wildcard tools make review and least-privilege reasoning impossible.

Production high-risk tool has no declared owner.

Why: High-risk production tools need an accountable owning team for review and remediation.

A policy references a missing tool.

Why: Approval, confirmation, and idempotency policies should map to the actual release surface.

A risk override references a missing tool.

Why: Risk overrides should not outlive the tool they describe.

A suppression references a missing check or tool.

Why: Stale suppressions hide intent and make release review harder to audit.

Manifest declares permission scopes unused by loaded tools.

Why: Unused permissions weaken least-privilege review and often indicate stale config.

High-risk tool lacks a declared approval policy.

Why: High-risk actions need explicit approval before promotion.

Destructive/external/customer-communication tool lacks a confirmation policy.

Why: Destructive and external actions should require explicit confirmation.

Action-like tool accepts broad free-form input.

Why: Broad action/body/update fields increase blast radius for write tools.

Tool returns free-form string output.

Why: Free-form tool output may carry prompt injection into later model context.

Risky numeric parameter lacks a maximum bound.

Why: Unbounded counts or financial amounts weaken blast-radius control.

Tool appears to overlap with a manifest prohibited action.

Why: Prohibited actions should not be contradicted by attached tool capabilities.

Write-capable tool contradicts a read-only declared purpose.

Why: Declared purpose should constrain the attached tool surface.

Tool description contains instruction-override-like language.

Why: Tool metadata can be placed into model context and should not contain prompt-like directives.

Tool description contains a secret-like value.

Why: Credentials in tool metadata can leak into reports, prompts, or logs.

Risky write tool lacks idempotency evidence; critical when retry is known.

Why: Retries against non-idempotent writes can duplicate financial or external side effects.