Submit a diff for OhMyBug cloud review
submit_reviewSend the diff plus selected context files for orchestrated bug-hunting review on OhMyBug cloud. Returns review_id immediately; poll get_findings. Reviews are free – billing is one flat price per review that ends with confirmed real bugs, regardless of how many: $4 fast, $12 deep, $24 deep on a wide change (11+ folder chunks) (a key on CI billing pays the same when the result holds a medium+ finding, with no confirm step; get_findings says so in billing). A hunt whose get_findings carries silent_bill bills on its own at silent_bill.at unless every medium+ finding is rejected (NOT_REAL) first; once it has, silent_bill.billed is true and at is when. Every submit runs the FAST hunt (diff + files the reviewers ask for) unless the user asked for the deep hunt outright (deep: true) or this API key runs only deep hunts (its setting on the key page /me/keys: then every submit is the deep hunt, or a refusal); the response carries recent_median_minutes – how long recent hunts of this kind took across the service, measured, when there is enough history – and the poll instructions. The deep full-repository hunt is otherwise a second stage you reach through deep: <review_id> after a fast review came back clean or all its findings were dismissed as NOT_REAL, and the user said yes.
Tool call template
This tool declares no required parameters. Add optional parameters from the input schema as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {},
"name": "submit_review"
}
}Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| deep | No | Stage two, the full-repository hunt: the repo is pulled in on the server side and the change is reviewed against the whole codebase (up to 2 hours). Two ways in. A review_id of a finished fast review on this account ESCALATES it – send that only after get_findings returned a `deep_offer` AND the user agreed. `true` runs the deep hunt as the FIRST review of the diff, skipping the fast stage – ONLY when the user explicitly asked for the deep hunt; never on your own initiative, and never because a fast review looks like it would not be enough. It needs meta.repo + meta.ref (pushed head sha) + meta.base_branch. `false` is the same as absent. | |
| diff | No | Unified diff. May be empty with upload=true, or with meta.repo+ref+base_branch when the GitHub App is installed OR the repo is public – then the server fetches the merge-base diff from GitHub itself (preferred: zero payload leaves the machine). That mode reviews the COMMIT, not your working tree: it fetches at `ref`, so anything uncommitted – in particular fixes you just wrote for earlier findings – is neither reviewed nor recorded as hunted. With uncommitted changes in the tree, commit them and send the new sha, or send the diff as payload; re-sending the same ref hunts the same commit again and changes nothing. | |
| meta | No | ||
| files | No | ||
| upload | No | Out-of-band payload mode for big diffs: returns upload_url; POST {diff, files} there from a script (bytes never enter the model context), review starts on upload. Ignored when meta.repo+ref+base_branch let the server fetch the diff itself – that path is strictly better and cannot be blocked by a sandbox. It overrides only the DIFF half: an upload also carries context files, and those have no substitute, so pass them in the inline `files` array on the same call or they are simply not sent. If an upload IS the only path and your environment refuses it (permission prompt, auto-mode, no python3), treat that as final: send repo+ref+base_branch with no payload, and if the repo is not readable offer the user the one-click GitHub App install instead of asking for a permission rule. |