OhMyBug

Get review status and findings

get_findings

Poll the review. status=running|done|failed. When done, verify each finding against the codebase and report verdicts via confirm_findings BEFORE fixing. If the response carries next_step, that is an instruction to you: perform it in your very next message to the user. A deep_offer is INFORMATION FOR THE USER, not a note for you and not a condition on merging – show deep_offer.pitch; whether to take the deep hunt is their call, never yours to make or to skip. A coverage_note is for the user too: show it with the result. A finished fast hunt with no deep_offer carries deep_offer_withheld: reason, one word for why, and retry – true when a later get_findings can answer differently with no setting changed (after confirm_findings, for unjudged; the answer may then be another reason), false when it cannot. retry is not an order to poll. declined: the deep hunt was offered on an earlier hunt of this change and not taken, so it is not offered here. repeats_unknown: this review judged or charges findings on a diff the server cannot tie to one commit of one repository, so a deep hunt could not tell their repeats apart: none runs off it.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "review_id": "<review_id>"
    },
    "name": "get_findings"
  }
}

Input Schema

Name	Required	Description	Default
`review_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A3.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full load and discloses substantial response semantics: next_step, deep_offer/deep_offer.pitch, coverage_note, deep_offer_withheld with reason and retry, declined, and repeats_unknown. That is unusually rich behavioral detail. It omits auth needs, rate/polling limits, and error behavior for status=failed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the body sprawls into a dense block of nested edge-case jargon (deep_offer_withheld, repeats_unknown) with heavy hedging. Much of it is genuinely useful, but it reads as an undifferentiated wall rather than layered signal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description does much of the work by naming several response fields. But it never describes the primary return, the findings themselves (identifiers, file/location, severity), so the agent cannot anticipate the payload it must act on. The status=failed path is unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% for the single review_id parameter, and the description never explains it, not even that it comes from submit_review. The only implicit hint is that the tool polls an existing review. With one undocumented parameter, the description should have compensated and does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening 'Poll the review. status=running|done|failed.' states a concrete verb (poll) and resource (review) plus the status domain. It never distinguishes this from the sibling wait_review, which an agent would plausibly confuse it with, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear sequencing rule: poll until done, then verify each finding against the codebase and report verdicts via confirm_findings BEFORE fixing. That is explicit when-and-how guidance tied to a named sibling. It gives no guidance on when to use this versus wait_review, nor any polling cadence.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All OhMyBug tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.